Partially addresses T72011.
The problem here is that the previous barycentric clamping did not deal well
with skinny triangles and would end up generating "sub-pixel jittering"
locations that were actually >20 pixels away.
Differential Revision: https://developer.blender.org/D16727
Expands Color Mix nodes with new Exclusion mode.
Similar to Difference but produces less contrast.
Requested by Pierre Schiller @3D_director and
@OmarSquircleArt on twitter.
Differential Revision: https://developer.blender.org/D16543
Replace ../lib/linux_centos7_x86_64 with ../lib/linux_x86_64_glibc_228,
built with Rocky8 Linux, compatible with the VFX platform CY2023,
see: T99618.
- Update build-bot configuration.
- Remove unnecessary check for Blosc, this is part of OpenVDB lib now.
- Remove WITH_CXX11_ABI, always use new C++11 ABI now
- Replace centos7 by glibc_228 everywhere
Note that existing builds with cached paths pointing to
"../lib/linux_centos7_x86_64" will need to be updated.
Includes contributions by Brecht.
This adds a new mirror image extension type for shaders and
geometry nodes (next to the existing repeat, extend and clip
options).
See D16432 for a more detailed explanation of `wrap_mirror`.
This also adds a new sampler flag `GPU_SAMPLER_MIRROR_REPEAT`.
It acts as a modifier to `GPU_SAMPLER_REPEAT`, so any `REPEAT`
flag must be set for the `MIRROR` flag to have an effect.
Differential Revision: https://developer.blender.org/D16432
This is done based on the render sample count so that it doesn't impact
sampling quality. It's similar in spirit to the adaptive table size in D16561,
but in this case for performance rather than memory usage.
Differential Revision: https://developer.blender.org/D16726
The first two dimensions of scrambled, shuffled Sobol and shuffled PMJ02 are
equivalent, so this makes no real difference for the first two dimensions.
But Sobol allows us to naturally extend to more dimensions.
Pretabulated Sobol is now always used, and the sampling pattern settings is now
only available as a debug option.
This in turn allows the following two things (also implemented):
* Use proper 3D samples for combined lens + motion blur sampling. This
notably reduces the noise on objects that are simultaneously out-of-focus
and motion blurred.
* Use proper 3D samples for combined light selection + light sampling.
Cycles was already doing something clever here with 2D samples, but using
3D samples is more straightforward and avoids overloading one of the
dimensions.
In the future this will also allow for proper sampling of e.g. volumetric
light sources and other things that may need three or four dimensions.
Differential Revision: https://developer.blender.org/D16443
The use of a struct for device strings caused the CUDA compiler to
generate byte arrays as the argument type, whereas OSL generated
primitive integer types (for the hash). Fix that by using a typedef
instead so that the CUDA compiler too will use an integer type in the
PTX it generates.
Maniphest Tasks: T101222
There has been an attempt to reorganize this part, however, it seems that didn't compile on HIP, and is reverted in
rBc2dc65dfa4ae60fa5d2c3b0cfe86f99dcb5bf16f. This is another attempt of refactoring. as I have no idea why some things don't work on HIP, it's
best to check whether this compiles on other platforms.
The main changes are creating a new struct named `MeshLight` that is shared between `KernelLightDistribution` and `KernelLightTreeEmitter`,
and a bit of renaming, so that light sampling with or without light tree could call the same function.
Also, I noticed a patch D16714 referring to HIP compilation error. Not sure if it's related, but browsing
https://builder.blender.org/admin/#/builders/30/builds/7826/steps/7/logs/stdio, it didn't work on gfx1102, not gfx9*.
Differential Revision: https://developer.blender.org/D16722
The PDF of mesh lights were not being scaled by `pdf_selection` when
the light tree was disable. This resulted in the mesh lights having
the wrong PDF and thus the wrong brightness.
Differential Revision: https://developer.blender.org/D16717
**Problem**:
Area lights in Cycles have spread angle, in which case some part of the area light might be invisible to a shading point. The current implementation samples the whole area light, resulting some samples invisible and thus simply discarded. A technique is applied on rectangular light to sample a subset of the area light that is potentially visible (rB3f24cfb9582e1c826406301d37808df7ca6aa64c), however, ellipse (including disk) area lights remained untreated. The purpose of this patch is to apply a techniques to ellipse area light.
**Related Task**:
T87053
**Results**:
These are renderings before and after the patch:
|16spp|Disk light|Ellipse light|Square light (for reference, no changes)
|Before|{F13996789}|{F13996788}|{F13996822}
|After|{F13996759}|{F13996787}|{F13996852}
**Explanation**:
The visible region on an area light is found by drawing a cone from the shading point to the plane where the area light lies, with the aperture of the cone being the light spread.
{F13990078,height=200}
Ideally, we would like to draw samples only from the intersection of the area light and the projection of the cone onto the plane (forming a circle). However, the shape of the intersection is often irregular and thus hard to sample from directly.
{F13990104,height=200}
Instead, the current implementation draws samples from the bounding rectangle of the intersection. In this case, we still end up with some invalid samples outside of the circle, but already much less than sampling the original area light, and the bounding rectangle is easy to sample from.
{F13990125}
The above technique is only applied to rectangle area lights, ellipse area light still suffers from poor sampling. We could apply a similar technique to ellipse area lights, that is, find the
smallest regular shape (rectangle, circle, or ellipse) that covers the intersection (or maybe not the smallest but easy to compute).
For disk area light, we consider the relative position of both circles. Denoting `dist` as the distance between the centre of two circles, and `r1`, `r2` their radii. If `dist > r1 + r2`, the area light is completely invisible, we directly return `false`. If `dist < abs(r1 - r2)`, the smaller circle lies inside the larger one, and we sample whichever circle is smaller. Otherwise, the two circles intersect, we compute the bounding rectangle of the intersection, in which case `axis_u`, `len_u`, `axis_v`, `len_v` needs to be computed anew. Depending on the distance between the two circles, `len_v` is either the diameter of the smaller circle or the length of the common chord.
|{F13990211,height=195}|{F13990225,height=195}|{F13990274,height=195}|{F13990210,height=195}
|`dist > r1 + r2`|`dist < abs(r1 - r2)`|`dist^2 < abs(r1^2 - r2^2)`|`dist^2 > abs(r1^2 - r2^2)`
For ellipse area light, it's hard to find the smallest bounding shape of the intersection, therefore, we compute the bounding rectangle of the ellipse itself, then treat it as a rectangle light.
|{F13990386,height=195}|{F13990385,height=195}|{F13990387,height=195}
We also check the areas of the bounding rectangle of the intersection, the ellipse (disk) light, and the spread circle, then draw samples from the smallest shape of the three. For ellipse light, this also detects where one shape lies inside the other. I am not sure if we should add this measure to rectangle area light and sample from the spread circle when it has smaller area, as we seem to have a better sampling technique for rectangular (uniformly sample the solid angle). Maybe we could add [area-preserving parameterization for spherical
ellipse](https://arxiv.org/pdf/1805.09048.pdf) in the future.
**Limitation**:
At some point we switch from sampling the ellipse to sampling the rectangle, depending on the area of the both, and there seems to be a visible line (with |slope| =1) on the final rendering
which demonstrate at which point we switch between the two methods. We could see that the new sampling method clearly has lower variance near the boundaries, but close to that visible line,
the rectangle sampling method seems to have larger variance. I could not spot any bug in the implementation, and I am not sure if this happens because different sampling patterns for ellipse and rectangle are used.
|Before (256spp)|After (256spp)
|{F13996995}|{F13996998}
Differential Revision: https://developer.blender.org/D16694
Ensure the environment is set up for blender_test, idiff and oslc so that they
can find the required shared libraries.
Also deduplicate add_bundled_libraries() between Linux and macOS.
Includes contributions by Ray Molenkamp and Brecht Van Lommel.
Ref T99618
Uses a light tree to more effectively sample scenes with many lights. This can
significantly reduce noise, at the cost of a somewhat longer render time per
sample.
Light tree sampling is enabled by default. It can be disabled in the Sampling >
Lights panel. Scenes using light clamping or ray visibility tricks may render
different as these are biased techniques that depend on the sampling strategy.
The implementation is currently disabled on AMD HIP. This is planned to be fixed
before the release.
Implementation by Jeffrey Liu, Weizhen Huang, Alaska and Brecht Van Lommel.
Ref T77889
This was not working well in non-trivial scenes before the light tree, and now
it is even harder to make it work well with the light tree. It would average the
with equal weight for every light object regardless of intensity or distance, and
be quite noisy due to not working with multiple importance sampling.
We may restore this if were enough good use cases for the previous implementation,
but let's wait and see what the feedback is.
Some uses cases for this have been replaced by the shadow catcher passes, which
did not exist when this was added.
Ref T77889
In this case the blocksize may not the one we requested, which was assumed to be
the case. Instead get the effective block size from the compiler as was already
done for Metal and OneAPI.
Unless using WITH_CYCLES_DEBUG.
This is convenient for investigating kernel performance, but too verbose to
always have in the buildbot logs especially now that we are also compiling HIP
and OneAPI kernels.
Materials now have an enum to set the emission sampling method, to be
either None, Auto, Front, Back or Front & Back. This replace the
previous "Multiple Importance Sample" option.
Auto is the new default, and uses a heuristic to estimate the emitted
light intensity to determine of the mesh should be considered as a light
for sampling. Shaders sometimes have a bit of emission but treating them
as a light source is not worth the memory/performance overhead.
The Front/Back settings are not important yet, but will help when a
light tree is added. In that case setting emission to Front only on
closed meshes can help ignore emission from inside the mesh interior that
does not contribute anything.
Includes contributions by Brecht Van Lommel and Alaska.
Ref T77889
* Split light types into own files, move light type specific code from
light tree and MNEE.
* Move flat light distribution code into own kernel file and host side
building function, in preparation of light tree addition. Add light/sample.h
as main entry point to kernel light sampling.
* Better separate calculation of pdf for selecting a light, and pdf for
sampling a point on the light. The selection pdf is now also stored in
LightSampling for MNEE to correctly recalculate the full pdf when the
shading position changes but the point on the light remains fixed.
* Improvement to kernel light storage, using packed_float3, better variable
names, etc.
Includes contributions by Brecht Van Lommel and Weizhen Huang.
Ref T77889
The wrong guiding distribution was used when direct and indirect light
scattering happened at different locations. Now use a different distribution
for each location.
Recording is not quite correct since OpenPGL does not support spliting the
path like this, instead recording at the start of the volume ray. In practice
this seems to make little difference.
Differential Revision: https://developer.blender.org/D16448
This resolves some issues with correlation artifacts at higher sample counts.
Fix T101356, correlation issues in new PMJ pattern.
Differential Revision: https://developer.blender.org/D16561
Commit c8dd33f5a37b6a6db0b6950d24f9a7cff5ceb799 in OSL changed behavior of
parameters that reference each other and are also overwritten with an
instance value. This is causing the "NormalIn" parameter of a few OSL nodes
in Cycles to be set to zero somehow, which should instead have received the
value from a "node_geometry" node Cycles generates and connects automatically.
I am not entirely sure why that is happening, but these parameters are
superfluous anyway, since OSL already provides the necessary data in the
global variable "N". So this patch simply removes those parameters (which
mimics SVM, where these parameters do not exist either), which also fixes
the rendering artifacts that occured with recent OSL.
While this fixes built-in shader nodes, custom OSL scripts can still have
this problem.
Ref T101222
Differential Revision: https://developer.blender.org/D16470
For some pixels with transparent surfaces, no depth value would be written
when sampling chooses a reflection/refraction BSDF instead of transparent
BSDF. Now ensure we always write at some some depth value to the pass.
This is still not ideal as the resulting depth values are noisy same as they
are for depth of field and motion blur, but at least there should be no gaps.
This was previously needed due to poor compatibility between Visual Studio and
NVCC. But it has not been used for a while now as compatibility seems to have
improved.
