This will make further changes for light linking easier, where we want to
build multiple trees specialized for each light linking set.
It's also easier to understand than the stack used previously.
Pull Request: https://projects.blender.org/blender/blender/pulls/107560
In some cases comments at the end of control statements were wrapped
onto new lines which made it read as if they applied to the next line
instead of the (now) previous line.
Relocate comments to the previous line or in some cases the end of the
line (before the brace) to avoid confusion.
Note that in quite a few cases these blocks didn't read well
even before MultiLine was used as comments after the brace caused
wrapping across multiple lines in a way that didn't follow
formatting used everywhere else.
There were two issues here preventing the proper display of the IES
files in question.
The primary one was that these lights are actually vertical. Their
profiles actually point upwards from 90deg to 180deg but our parser was
trying hard to adjust it to start at 0deg incorrectly.
Lastly, the files in question ended with the parser in the `eof`
state - they are "missing" the final carriage return that other IES
files tend to have but other viewers don't seem to mind. Change the
`eof` check instead for a better one that will indicate if any parsing
errors occurred along the way.
Pull Request: https://projects.blender.org/blender/blender/pulls/107320
The intersection distance offset in Cycles could have returned
a denormal floating point value for the input values of 0 (and
for the denormal input value).
This could lead to a situation when ray is unable to be advanced
when it hits an edge between two triangles: the intersection will
keep bouncing between two adjacent triangles. This is because the
ray->tmin is compared inclusively, and 0 >= <denormal zero>.
The solution is to return the smallest possible normalized floating
point value from the intersection_t_offset if the input is zero
or a denormal value (which is covered by the same t == 0 check).
This fix is hard to measure on the user level. The old code did
not cause any infinite traversal loop because of the way how the
integration is organized (some kernels offset ray.P, others check
for the number of bounces). It is possible that this fixes some
corner cases of noise: i.e. if some shadow rays falsefully were
considered occluded due to reached maximum number of bounces.
The actual problematic case was discovered during working on a
prototype which had an in-lined intersection loop with the ray
tmin offset.
Pull Request: https://projects.blender.org/blender/blender/pulls/107364
HIP RT enables AMD hardware ray tracing on RDNA2 and above, and falls back to a
to shader implementation for older graphics cards. It offers an average 25%
sample rendering rate improvement in Cycles benchmarks, on a W6800 card.
The ray tracing feature functions are accessed through HIP RT SDK, available on
GPUOpen. HIP RT traversal functionality is pre-compiled in bitcode format and
shipped with the SDK.
This is not yet enabled as there are issues to be resolved, but landing the
code now makes testing and further changes easier.
Known limitations:
* Not working yet with current public AMD drivers.
* Visual artifact in motion blur.
* One of the buffers allocated for traversal has a static size. Allocating it
dynamically would reduce memory usage.
* This is for Windows only currently, no Linux support.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Ref #105538
This patch fixes the failing shader/bevel unit test when MetalRT is enabled. The ray was being transformed into local object space even when the SD_OBJECT_TRANSFORM_APPLIED flag was set.
Pull Request: https://projects.blender.org/blender/blender/pulls/107292
When running oneAPI with AoT binaries, on hardware that's not compatible with
these, recompilation could have been missing from the kernels loading phase and
happen during execution instead.
These changes fixes it, any kernel compilation will now happen during the
kernels loading phase.
Using the new HIP SDK 5.5 that includes a fix for the compiler bug.
This also enables the light tree.
For Linux the binaries are still disabled. ROCm 5.5 is planned to
include the same fix but not released yet. When that happens we
should be able to enable Linux as well.
Ref #104786Fix#104085
Pull Request: https://projects.blender.org/blender/blender/pulls/107098
Updated Embree 4 library with GPU support is required for it to be
compiled - compatiblity with Embree 3 and Embree 4 without GPU support
is maintained.
Enabling hardware raytracing is an opt-in user setting for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/106266
This reverts commit df096eab77.
There is a corner case for when WITH_CYCLES_ONEAPI_BINARIES is set to on
and later turned off during config, in case there is no ocloc.
Due to floating point differences between importance sampling and
texture evaluation, disagreeing on whether or not a ray lies within
the sun disc.
* Use the same input values for geographical_to_direction() in
sky_radiance_nishita() and kernel_data.background.sun.
* The mathematical operations in pdf_uniform_cone() were adjusted to
match sky_radiance_nishita().
Pull Request: https://projects.blender.org/blender/blender/pulls/106764
The OSL GPU services implementation of noise intrinsics was missing the
overloads for derivatives and therefore OptiX pipeline creation would fail if
those were referenced.
Barycentric coordinate convention was changed at some point, which is
reflected in `motion_triangle_shader.h` (1c2c468abc) but not in
`motion_triangle.h`, this is also fixed by sharing functions between the
two header files.
Pull Request: https://projects.blender.org/blender/blender/pulls/106629
This patch replaces `dispatchThreadgroups` with `dispatchThreads` which takes care of non-uniform threadgroup bounds. This allows us to remove the bounds guards in the integrator kernel entry points.
Pull Request: https://projects.blender.org/blender/blender/pulls/106217
This patch fixes a MetalRT issue where viable shadow hits are discounted based on the false assumption that hits are ordered by distance. With this patch, the following unit tests now pass:
- openvdb smoke
- shadow catcher pt transparent lamp only 0.8
- shadow catcher pt transparent lamp only 1.0
Pull Request: https://projects.blender.org/blender/blender/pulls/106276
For example
```
OIIOOutputDriver::~OIIOOutputDriver()
{
}
```
becomes
```
OIIOOutputDriver::~OIIOOutputDriver() {}
```
Saves quite some vertical space, which is especially handy for
constructors.
Pull Request: https://projects.blender.org/blender/blender/pulls/105594
This is a workaround fix for Open PGL 0.4.1 when the first volume
samples are collected in a later training iteration.
The problem is fixed in Open PGL > 0.5.0 and the workaround
can be removed after upgrading Open PGL.
The name #ensure_valid_reflection seems to indicate that the resulted
reflection must be valid, whereas in the reality it only ensure validity
for specular reflections. The new name matches the behavior better.
This function checks if the shading normal would result in an invalid reflection into the lower hemisphere; if it is the case, the function raises the shading normal just enough so that the specular reflection lies above the surface. This is a trick to prevent dark regions at grazing angles caused by normal/bump maps. However, the specular direction is not a good representation for a diffuse material, applying this function sometimes brightens the result too much and causes unexpected results. This patch applies the function to only glossy materials instead.
Pull Request: #105776
Actually both potential roots lie in the interval [0, 1], so the
function ended up checking both roots all the time.
The new implementation explains why only one of the roots is valid; it
saves two square roots and a bunch of other computations.
