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.
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
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
Global built-ins appear to not work on AMD cards.
Also add a tweak to avoid a performance regression, similar
to what was done before. Disable adaptive subdivision kernel
code if not used.
Pull Request: https://projects.blender.org/blender/blender/pulls/119175
for a camera ray, compute the actual range of the hair width that the
current pixel covers, and only integrate that subset, to prevent a
ribbon-like appearance in close-up looks.
When the hair covers less than one pixel on the screen or when the ray
is not camera ray, the model works the same as before.
Pull Request: https://projects.blender.org/blender/blender/pulls/116094
The valid interval from incoming direction was shared between
`...eval_r()` and `...eval_residual()`, so compute that in `...eval()` instead.
The valid interval from outgoing direction was computed for
`...eval_r()` to further reduce the integration interval. This part is
removed because the check `dot(wo, wm) > 0` is relatively cheap inside the loop.
The geometry normal of the curve might not be precisely orthogonal to
the tangent due to interpolation. Previously, the tangent was adjusted
to be orthogonal to the normal. However, the normal is linearly
interpolated, which is less accurate than the tangent computed using Catmull-Rom.
This commit keeps the tangent and adjust the normal instead, besides
better accuracy, it ensures a smooth transition when the cross-section
shifts between circular and elliptical.
if emission sampling is not set, we do not use MIS weight when sampling
from the BSDF, but we were still drawing samples from the light,
resulting in double contribution.
Pull Request: https://projects.blender.org/blender/blender/pulls/118534
These are now included in the OSL shared libraries, so no reason to
link against it.
The CMake code for WITH_LLVM remains in case it is useful in the future,
but is not enabled by any Blender feature now.
Pull Request: https://projects.blender.org/blender/blender/pulls/118229
This commit updates all defines, compiler flags and cleans up some code for unused CPU capabilities.
There should be no functional change, unless it's run on a CPU that supports sse41 but not sse42. It will fallback to the SSE2 kernel in this case.
In preparation for the new SSE4.2 minimum in Blender 4.2.
Pull Request: https://projects.blender.org/blender/blender/pulls/118043
