fdc2962beb indirectly introduced a change
in inlining (light_tree_pdf started getting inlined) that led to a 5-10%
drop in performance for most scenes.
Dropping the noinline keyword for oneAPI device recovers it.
It however brings another performance regression to MNEE and Raytrace
kernels, that we'll look into separately.
The Perlin noise algorithms suffer from precision issues when a coordinate
is greater than about 250000.
To fix this the Perlin noise texture is repeated every 100000 on each axis.
This causes discontinuities every 100000, however at such scales this
usually shouldn't be noticeable.
Pull Request: https://projects.blender.org/blender/blender/pulls/119884
it is not clear from which point the `cos_theta_u` should be computed in
volume segment, so the original implementation was mixing the closest point
and the point where the minimal angle is formed.
Use the closest point on segment as a conservative measure.
Pull Request: https://projects.blender.org/blender/blender/pulls/119965
in the test scene `all_light_types_in_volume.blend`, `theta - theta_o -
theta_u` is slightly above the threshold. Even if we do a strict check
with `acos` on the failing cases, it will go to the other branch and
deliver a result which is also 1.0f. Better to relax the threshold.
Cycles samples environment map with a PDF proportional to the luminance.
This computation was assuming positive values, but generated texture
coordinates from world could have negative values, so the resulted CDF
was almost zero in the bug report scene.
Fixed by taking the absolute value when computing luminance in CDF.
Pull Request: https://projects.blender.org/blender/blender/pulls/119896
During the some of the shading for volumetrics, Cycles would try to
write to a variable that does not exist if the device has the
light tree disabled.
At the moment this only impacts AMD GPUs with the Metal backend.
Pull Request: https://projects.blender.org/blender/blender/pulls/119906
The same random number was used when sampling from the volume segment
and from the direct scattering position, causing correlation issues with
light tree.
To solve this problem, we ensure the same light is picked for
volume segment/direct scattering, equiangular/distance sampling by
sampling the light tree only once in volume segment. From the direct
scattering position in volume, we sample a position on the picked light
as usual. If sampling from the light tree fails, we continue with
indirect scattering.
For unbiased MIS weight for forward sampling, we retrieve the `P`, `D`
and `t` used in volume segment for traversing the light tree.
The main changes are:
1. `light_tree_sample()` and `light_distribution_sample()` now only pick
lights. Sampling a position on light is done separately via
`light_sample()`.
2. `light_tree_sample()` is now only called only once from volume
segment. For direct lighting we call `light_sample()`.
3. `light_tree_pdf()` now has a template `<in_volume_segment>`.
4. A new field `emitter_id` is added to struct `LightSample`, which just
stores the picked emitter index.
5. Additional field `previous_dt = ray->tmax - ray->tmin` is added to
`state->ray`, because we need this quantity for computing the pdf.
6. Distant/Background lights are also picked by light tree in volume
segment now, because we have no way to pick them afterwards. The direct
sample event for these lights will be handled by
`VOLUME_SAMPLE_DISTANCE`.
7. Original paper suggests to use the maximal importance, this results
in very poor sampling probability for distant and point lights therefore
excessive noise. We have a minimal importance for surface to balance, we
could do the same for volume but I do not want to spend much time on
this now. Just doing `min_importance = 0.0f` seems to do the job
okayish. This way we still won't sample the light with zero
`max_importance`.
The current solution might perform worse with distance sampling, because
the light tree measure is biased towards equiangular sampling. However,
it is difficult to perform MIS between equiangular and distance sampling
if different lights are picked for each method. This is something we can
look into in the future if proved to be a serious regression.
Pull Request: https://projects.blender.org/blender/blender/pulls/119389
When using light linking with the light tree, the root index of a
mesh light subtree can be 0. The current code assumed this wasn't
possible, and as such it caused rendering issues, specifically the
incorrect computation of the PDF of certain mesh lights during
forward path tracing.
So we adjust the code to allow mesh light subtree root node
indices of 0.
This was worked on by Alaska, Sergey, and Weizhen
Pull Request: https://projects.blender.org/blender/blender/pulls/119770
By restricting the sample range along the ray to the valid segment.
Supports
**Mesh Light**
- [x] restrict the ray segment to the side with MIS
**Area Light**
- [x] when the spread is zero, find the intersection of the ray and the bounding box/cylinder of the rectangle/ellipse area light beam
- [x] when the spread is non-zero, find the intersection of the ray and the minimal enclosing cone of the area light beam
*note the result is also unbiased when we just consider the cone from the sampled point in volume segment. Far away from the light source it's less noisy than the current solution, but near the light source it's much noisier. We have to restrict the sample region on the area light to the part that lits the ray then, I haven't tried yet to see if it would be less noisy.*
**Point Light**
- [x] the complete ray segment should be valid.
**Spot Light**
- [x] intersect the ray with the spot light cone
- [x] support non-zero radius
Pull Request: https://projects.blender.org/blender/blender/pulls/119438
Running a very simple files when Blender is built with the
WITH_COMPILER_ASAN=ON and WITH_CYCLES_KERNEL_ASAN=ON CMake options
leads to ASAN reporting an unknown-crash at line where the worker
pool is being filled in.
It is not entirely clear if it is a real issue in the code, since
placing debug prints with `this` address report proper addresses,
however there is no harm on capturing `this` pointer by value and
it does solve the ASAN reporting issues.
It is possible to reproduce the ASAN crash with the following steps:
- Start with --factory-startup
- Enable Metal device in User Preferences
- Switch render device to GPU Compute
- Switch viewport more to Rendered
Pull Request: https://projects.blender.org/blender/blender/pulls/119867
The original bug report was that the Glossy Toon BSDF behaves incorrectly
when mixed with other closures.
The underlying issue here was that the eval function didn't check whether
the reflection angle is inside the valid cone and always returned its PDF,
which is very high compared to e.g. the diffuse closure's PDF for small
sizes (since the cone is supposed to be quite tight) and therefore breaks
MIS mixing.
However, while looking into this, I found a number of other issues, and so
this commit also contains several other changes to the Toon BSDFs:
- The angle that was used to compute the intensity wasn't the actual angle
between the vectors. From what I can see, the formula that was used goes
back all the way to the initial commit 12 years ago, so this probably was
something that happened to work with one particular cone sampling method.
Now, however, it caused weird asymmetric highlights, so replace it with
the actual angle (which we already compute anyways).
- Setting size to zero caused the BSDF to go black, so clamp to 1e-5.
- The code was overall a bit repetitive, so I've cleaned it up a bit.
The code to compute differentials mixed up the camera-space locations
of the raster coordinate and the camera itself, which caused the dP
differential to be set even when the ray origin is always the same.
This commit fixes that, reorganizes the code so that the Px/Py are
no longer used for both values to avoid future confusion, and skips
some unnecessary calculations stereo rendering isn't being used.
For spherical spot light, when the shading point is close to the light
source, we switch to sampling the light spread instead of the visible
cone from the shading point. This has the benefit of less noise when the
spread is small.
However, the light spread sampling was not considering non-uniform
object scaling, where the actual spread might be different.
This patch switches sampling method only when the smallest enclosing
spread cone is smaller than the visible cone from the shading point.
An alternative method would be to compute the actual solid angle of the
scaled cone, and sample from the scaled cone. However, that involves
ray transformation and modifying the sampling pdf and angle. Since
non-uniform scaling is rather a niche case, it's probably not worth the
computation effort.
Pull Request: https://projects.blender.org/blender/blender/pulls/119661
which resulted in bias when self intersection is excluded in forward scattering.
Below is a comparison using principled BSDF with emission. NEE and MIS were much brighter.
Pull Request: https://projects.blender.org/blender/blender/pulls/119440
Ref: #118534
turns out `in_volume_segment` does need to be checked. If the ray origin
lies on the wrong side of the mesh light, part of the ray could still be
lit by the other side, so the sample should not be considered invalid.
Pull Request: https://projects.blender.org/blender/blender/pulls/119529
In older drivers with an integrated GPU, this may crash. This not only
affects HIP, but also can crash when using Cycles with an NVIDIA or
Intel GPU in combination with an AMD CPU.
Fixes for this are expected to be coming, but there will not be enough
time for user testing, and it is difficult to be certain that the fix
is complete.
So to be careful, this is postponed until it has had more testing.
Pull Request: https://projects.blender.org/blender/blender/pulls/119476
This fixes the following name collisions:
* Compositor Box/Ellipse Mask node: `width` -> `mask_width`
(also renamed the `height` property accordingly)
* Shader AOV Output node: `name` -> `aov_name`
* Geometry Color node: `color` -> `value`.
Those are breaking changes unfortunately, because looking up those property
names yielded the node-specific and not the common property. Therefore, this is
targeted at `main` instead of `4.1`.
Pull Request: https://projects.blender.org/blender/blender/pulls/119284
Previously the CUDA context was always destroyed and the module along
with it. Now that this no longer happens, the missing module free became
a memory leak.
Also fix the same issue for HIP, though this is destroying the context
so it's not a problem yet.
Fix part of #119035
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Xavier Hallade
Campbell Barton
Hoshinova
Brecht Van Lommel
Alaska
Weizhen Huang
Sergey Sharybin
Lukas Stockner
Hans Goudey
Jacques Lucke
Miguel Pozo
Attila Afra