Making object which uses volume shader invisible will mark the shader
as not having a volume, forcing re-compilation of the shader to bring
it back to a consistent state.
The compilation is happening as part of scene update, which needs to
know kernel features. So there is a feedback loop.
Use more relaxed way of knowing whether there is a volume in the
shader for the kernel features, which doesn't require shader to be
compiled first.
Solves issues from the report, but potentially causes extra memory
allocated if the volume part of graph is fully optimized out. This
downside is solvable, but would need to split scene update into two
steps (the one which requires on kernel, and the one which does not).
It will be an interesting project to tackle, but for a bug fix is
better to use simpler solution.
There was an optimization to remove duplicate storage of normals as attributes
when using normal maps. However for named attributes like this we still need to
store the attribute.
Don't request normal attribute from the normal map node now, instead of skipping it
in the geometry code.
Samples count pass is normalized to the overall number of samples.
This means that we need to store actual value of the samples in the
tile buffer file.
A bit annoying to pull all those settings to BufferParams and need
to find a more generic solution, but for now this is easiest and a
quickest solution.
Differential Revision: https://developer.blender.org/D12597
Reported by Thomas DInges: the default cube render in Cycles has jagged
edges during rendering. Happens on AMD Radeon RX 5500 XT.
Force linear interpolation at zoom level 1 and less.
Reviewed by @fclem
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycleshttps://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
Previously fluid simulation and Alembic modifiers had a dedicated function
to query the velocity for motion blur. Now use a more generic system where
those modifiers output a velocity attribute.
Advantages:
* Geometry and particle nodes can output velocity through the same mechanism,
or read the attribute coming from earlier modifiers.
* The velocity can be preserved through modifiers like subdivision surface or
auto smooth.
* USD and Alembic previously only output velocity from fluid simulation, now
they work with velocity from other sources too.
* Simplifies the code for renderers like Cycles and exporters like
Alembic and USD.
This breaks compatibility:
* External renderers and exporters accessing these velocities through the
Python API now need to use the attribute instead.
* Existing modifier node setups that create an attribute named "velocity"
will render differently with motion blur.
Differential Revision: https://developer.blender.org/D12305
Addresses T76082.
Since the DirectX backend does not work for AMD gpus
(wglDXRegisterObjectNV() fails to register the shared OpenGL-DirectX
render buffer, displaying a pink screen to the user), the original
solution was to use SteamVR's OpenGL backend, which, as tested
recently, seems to work without any issues on AMD hardware.
However, the SteamVR OpenGL backend (on Windows) was disabled in
fe492d922d6d since it resulted in crashes with NVIDIA gpus (and still
crashes, as tested recently), so SteamVR would always use the
AMD-incompatible DirectX backend (on Windows).
This patch restores use of the SteamVR OpenGL backend for non-NVIDIA
(AMD, etc.) gpus while maintaining the DirectX workaround for NVIDIA
gpus. In this way, issues are still resolved on the NVIDIA side but
AMD users can once again use the SteamVR runtime, which may be their
only viable option of using Blender in VR.
Reviewed By: Julian Eisel
Differential Revision: https://developer.blender.org/D12409
This adds support for two Varjo specific OpenXR vendor extensions:
1) XR_VARJO_QUAD_VIEWS
2) XR_VARJO_FOVEATED_RENDERING
Together these enable human eye resolution rendering on supported
devices (currently mainly Varjo XR-3 and VR-3).
In addition, there's a detection for Varjo OpenXR runtime.
This has been tested on real Varjo XR-3 hardware and Varjo Simulator
and confirmed to function correctly. Foveation works, and the views are
rendered correctly for all the four views.
Reviewed By: Peter Kim, Julian Eisel
Differential Revision: https://developer.blender.org/D12229
Previously, the Point Instance node in geometry nodes could only instance
existing objects or collections. The reason was that large parts of Blender
worked under the assumption that objects are the main unit of instancing.
Now we also want to instance geometry within an object, so a slightly larger
refactor was necessary.
This should not affect files that do not use the new kind of instances.
The main change is a redefinition of what "instanced data" is. Now, an
instances is a cow-object + object-data (the geometry). This can be nicely
seen in `struct DupliObject`. This allows the same object to generate
multiple geometries of different types which can be instanced individually.
A nice side effect of this refactor is that having multiple geometry components
is not a special case in the depsgraph object iterator anymore, because those
components are integrated with the `DupliObject` system.
Unfortunately, different systems that work with instances in Blender (e.g.
render engines and exporters) often work under the assumption that objects are
the main unit of instancing. So those have to be updated as well to be able to
handle the new instances. This patch updates Cycles, EEVEE and other viewport
engines. Exporters have not been updated yet. Some minimal (not master-ready)
changes to update the obj and alembic exporters can be found in P2336 and P2335.
Different file formats may want to handle these new instances in different ways.
For users, the only thing that changed is that the Point Instance node now
has a geometry mode.
This also fixes T88454.
Differential Revision: https://developer.blender.org/D11841
When rendering the test scene in T79190 which has only emissive surfaces a division by zero occurs. This is a simple patch to remove this.
Reviewed By: brecht
Maniphest Tasks: T79190
Differential Revision: https://developer.blender.org/D11682
Is used for platforms for which we do not have native implementation,
such as MIPS, for example.
It is possible to test locking implementation on local computer by
defining `ATOMIC_FORCE_USE_FALLBACK` in the atomic_ops_unix.h file.
Run full regression suit with the locking implementation on amd64
Linux platform and all tests passed.
Having non-optimal but working implementation for odd-ball platforms
seems to be a better choice than failing the build entirely.
Differential Revision: https://developer.blender.org/D12313
Enables all currently documented OpenXR controller profile
extensions (Reverb G2, Vive Cosmos, Huawei Controller) in order to
support bindings for more VR hardware.
This is necessary because, if these extensions are not enabled, the
OpenXR runtime will return an error when creating a binding with one
of these profiles.
Does not bring about any changes for users at the moment, since
default controller actions have not yet been exposed to users (will
be addressed with D10944, D10948, and D11271).
Originally mentioned that absolute tracking was disabled, which is
wrong because absolute tracking (skipping application of eye offsets)
is always available, although it may not give the expected result of
persistent tracking origins across sessions if the stage space is
unavailable (hence the need for a warning).
Now, the warning makes no mention of absolute tracking, instead
informing the user that the local space fallback will be used and
that they should define tracking bounds via the XR runtime if they
wish to use the stage space.
Prior to rBb8ecdbcd964a normals were stored both in
DeviceScene.tri_vnormal and the float3 attributes buffer. However, the
normals in `DeviceScene.tri_vnormal` might have be transformed to world
space if the object's transformation was applied, while the data in the
float3 attributes buffer were not. This caused shading issues in cases
where the objects did have transformation applied, as the math expects
the normals to be in object space.
To fix this, convert the normals to object space if necessary before
applying the normal map.
Reviewed By: brecht
Maniphest Tasks: T90854
Differential Revision: https://developer.blender.org/D12294
Solves an error in the principled diffuse BSDF, where it was not correctly
rejecting directions outside the hemisphere.
Differential Revision: https://developer.blender.org/D12283
This adds a setting to enable data caching, and another one to set the
maximum cache size in megabytes.
When caching is enabled we load the data for the entire animation in
memory, as we already do, however, if the data exceeds the memory limit,
render is aborted.
When caching is disabled, we simply load the data for the current frame
in memory.
Ref D10197
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D11163
As subdivision objects are first class citizens in Alembic, to
differentiate them with non-subdivided polygon meshes, the Alembic
Procedural automatically sets up subdivision properties on the generated
Cycles Mesh.
However, for real-time playback subdivision is far too slow, so this
modifies the detection of a MeshSeqCache modifier used to activate the
procedural to allow for a Subsurf modifier right after the cache one. If
present, the procedural will tag the object for subdivision, if absent, the
object will be treated as a regular mesh.
This is a temporary measure for until subdivision surface settings are part
of the Mesh datablock (see T68891).
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D11162
This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache
modifier in order to use and test it from Blender.
To enable it, one has to switch the render feature set to experimental and
activate the Procedural in the modifier. An Alembic Procedural is then
created for each CacheFile from Blender set to use the Procedural, and each
Blender object having a MeshSequenceCache modifier is added to list of objects
of the right procedural.
The procedural's parameters derive from the CacheFile's properties which are
already exposed in the UI through the modifier, although more Cycles specific
options might be added in the future.
As there is currently no cache controls and since we load all the data at the
beginning of the render session, the procedural is only available during
viewport renders at the moment. When an Alembic procedural is rendered, data
from the archive are not read on the Blender side.
If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural,
bounding boxes are used to display the objects in the scene as a signal that the
objects are not processed by Blender anymore. This is standard in other DCCs.
However this does not reduce the memory usage from Blender as the Alembic data
was already loaded either during an import or during a .blend file read.
This is mostly a hack to test the Cycles Alembic procedural until we have a
better Blender side mechanism for letting renderers load their own geometry,
which will be based on import and export settings on Collections (T68933).
Ref T79174, D3089
Reviewed By: brecht, sybren
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D10197
The main reason for this is to speed up updates by avoid unnecessary
copies as the Generated coordinates are a copy of the vertices.
Creating this attribute may become optional in the future, with UI
parameters to select which attribute to use from the Alembic archive as
reference.
This modifies the attribute lookup to use object coordinates if no
generated coordinates are found on the geometry.
This is useful to avoid creating and copying this attribute, thus saving
a bit of time and memory.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D12238
Vertex normals are needed for normals maps and therefore are packed and send
to the device alongside the other float3 attributes. However, we already pack
and send vertex normals through `DeviceScene.tri_vnormal`.
This removes the packing of vertex normals from the attributes buffer, and
reuses `tri_vnormal` in the kernel for normals lookup for normal maps, which
reduces memory usage a bit, and speeds up device updates.
This also fixes potential missing normals updates following rB12a06292af86,
since the need for vertex normals for normals maps was overlooked.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D12237
