This change fixes an issue when scene has a shadow catcher and film is
configured to be transparent. Starting viewport render and making the
background non-transparent will cause bad memory access (wrong render
and possibly crash).
Film passes depends on transparency of background, so check for this.
Demo file: F10650585
Differential Revision: https://developer.blender.org/D12666
Only do denoising on the full-frame result. Saves render time.
Can re-consider in the future when/if we'll want to support
denoising during rendering (similar to viewport) to allow artists
to stop rendering when they see image to be good enough. Until
there is a design for that workflow stick to a more time efficient
rendering.
Differential Revision: https://developer.blender.org/D12662
Part of the fix is by Jacques. This fixes the most obvious case, but it's
still not clear how to deal with non-mesh geometry instances or how to handle
motion blur for such instances.
Before the visibility test against the visibility flags was performed in an any-hit program in OptiX
(called `__anyhit__kernel_optix_visibility_test`), which was using the `__prim_visibility` array.
This is not entirely correct however, since `__prim_visibility` is filled with the merged visibility
flags of all objects that reference that primitive, so if one object uses different visibility flags
than another object, but they both are instances of the same geometry, they would appear the same
way. The reason that the any-hit program was used rather than the OptiX instance visibility mask is
that the latter is currently limited to 8 bits only, which is not sufficient to contain all Cycles
visibility flags (12 bits).
To mostly fix the problem with multiple instances and different visibility flags, I changed things to
use the OptiX instance visibility mask for a subset of the Cycles visibility flags (`PATH_RAY_CAMERA`
to `PATH_RAY_VOLUME_SCATTER`, which fit into 8 bits) and only fall back to the visibility test any-hit
program if that isn't enough (e.g. the ray visibility mask exceeds 8 bits or when using the built-in
curves from OptiX, since the any-hit program is then also used to skip the curve endcaps).
This may also improve performance in some cases, since by default OptiX can now perform the normal
scene intersection trace calls entirely on RT cores without having to jump back to the SM on every
hit to execute the any-hit program.
Fixes T89801
Differential Revision: https://developer.blender.org/D12604
Fix T91632: Stops the sample correlation between dimensions which was causing rendering artefacts on simple scenes.
This is done by increasing the amount of jitter the Cranley Patterson Rotation is allowed to add. Also, it uses the y dimension of the of the sample table for 1D sampling which causes further decorrelation between dimensions. As an additional measure the x and y dimensions are swapped randomly to provide further decorrelation.
Maniphest Tasks: T91632
Differential Revision: https://developer.blender.org/D12610
We were writing large 2048x2048 tiles into EXR files, which appears to cause
integer overflow inside the OpenEXR library when there are multiple passes. Now
use smaller tiles in the image file, while still rendering large tiles.
This adds the requirement that the render tile size must be a multiple of 128
or be smaller than 128, this is adjusted automatically.
Goal is to add the length attribute to the Hair Info node, for better control over color gradients or similar along the hair.
Reviewed By: #eevee_viewport, brecht
Differential Revision: https://developer.blender.org/D10481
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
