Add Metallic BSDF Node to the shader editor.
This node can primarily be used to create more realistic looking
metallic materials than the existing Glossy BSDF node.
This commit does not add any new closures to Cycles, it simply exposes
existing closures that were previous hard to access on their own.
- Exposes the F82 fresnel type that is currently used by the
metallic component of the Principled BSDF. Results should match
between the Metallic BSDF and Principled BSDF when using the same
settings.
- Exposes the Physical Conductor fresnel type that was previously
limited to custom OSL scripts. The Conductor fresnel type accepts
IOR and Extinction coefficients to define the appearance of the
material based off real life measurements.
EEVEE only supports the F82 fresnel type with internal code to convert
the the physical conductor inputs in to a colour format for F82,
which can lead to noticeable rendering differences with
some configurations.
Pull Request: https://projects.blender.org/blender/blender/pulls/114958
Hair objects did not take the curves into account that could go
outside the bounds set by the keys of the curves. These bounds
are used in the dynamic bvh, leading to clipped curves in the
viewport.
Pull Request: https://projects.blender.org/blender/blender/pulls/126157
Overload resolution must have changed and is causing issues for one
particular code path attempting to use `isfinite(ccl::uchar)`.
Compiler output attached.
It turns out that the code in question can be simplified to just remove
the ambiguity because only the float codepath wants to check for finite
values.
----
Reduced repro: https://godbolt.org/z/YWz3Yc3x8
Pull Request: https://projects.blender.org/blender/blender/pulls/125348
This type of projection is often used e.g. in exhibitions that leverage big
curved screens.
Effectively, the frame is mapped onto a cylinder, with the x axis becoming the
longitude and y axis becoming the height.
Users can configure the min/max longitude, the min/max height and the radius of
the cylinder.
Co-authored-by: Lukas Stockner <lukas.stockner@freenet.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/123046
When the spread of a spot light is at it's maximum (180 degrees),
then `atan(tan(theta_e))` could become quite unpredictable due to
a asymtote in the tan function when working with lights with this
spread (because theta_e is `spread * 0.5 = pi/2`).
This lead to issues like theta_e for the spotlight becoming negative,
which lead to rendering errors due to a malformed light tree.
This commit fixes this issue by adding a episilon region around the
troublesome values and sets theta_e to `pi/2` when in that region.
Candidate for backporting to 4.2 and potentially 3.6
Pull Request: https://projects.blender.org/blender/blender/pulls/125172
Setting this option to a value above zero replaces the lambertian Diffuse term
with the modified energy-preserving Oren-Nayar BSDF, which matches the OpenPBR
behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/123616
This is because with the addition of new features to Cycles, these GPUs
experienced significant performance regressions and bugs, all stemming
from bugs in the Metal GPU driver/compiler. The only reasonable way to
work around these issues was to disable parts of Cycles code on
these GPUs to avoid the driver/compiler bugs.
This resulted in increased development time maintaining these platforms
while being unable to deliver feature parity with other
GPU backends.
It has been decided that this development time is better spent
maintaining platforms that are still actively maintained by
hardware/software vendors, and so AMD and Intel GPU support will be
removed from the Metal backend for Cycles.
Pull Request: https://projects.blender.org/blender/blender/pulls/123551
On some Macs, MNEE would be disabled in Cycles to work around a bug.
However this just led to these devices skipping over MNEE related
parts of the rendering pipeline and not properly progressing through
the render.
This commit fixes this issue by properly disabling MNEE on these devices.
Pull Request: https://projects.blender.org/blender/blender/pulls/123765
This patch implements a new Gabor noise node based on [1] but with the
improvements from [2] and the phasor formulation from [3].
We compare with the most popular existing implementation, that of OSL,
from the user's point of view:
- This implementation produces C1 continuous noise as opposed to the
non continuous OSL implementation, so it can be used for bump
mapping and is generally smother. This is achieved by windowing the
Gabor kernel using a Hann window.
- The Bandwidth input of OSL was hard-coded to 1 and was replaced with
a frequency input, which OSL hard codes to 2, since frequency is
more natural to control. This is even more true now that that Gabor
kernel is windowed as opposed to truncated, which means increasing
the bandwidth will just turn the Gaussian component of the Gabor
into a Hann window. While decreasing the bandwidth will eliminate
the harmonic from the Gabor kernel, which is the point of Gabor
noise.
- OSL had three discrete modes of operation for orienting the kernel.
Anisotropic, Isotropic, and a hybrid mode. While this implementation
provides a continuous Anisotropy parameter which users are already
familiar with from the Glossy BSDF node.
- This implementation provides not just the Gabor noise value, but
also its phase and intensity components. The Gabor noise value is
basically sin(phase) * intensity, but the phase is arguably more
useful since it does not suffer from the low contrast issues that
Gabor suffers from. While the intensity is useful to hide the
singularities in the phase.
- This implementation converges faster that OSL's relative to the
impulse count, so we fix the impulses count to 8 for simplicitly.
- This implementation does not implement anisotropic filtering.
Future improvements to the node includes implementing surface noise and
filtering. As well as extending the spectral control of the noise,
either by providing specialized kernels as was done in #110802, or by
providing some more procedural control over the frequencies of the
Gabor.
References:
[1]: Lagae, Ares, et al. "Procedural noise using sparse Gabor
convolution." ACM Transactions on Graphics (TOG) 28.3 (2009): 1-10.
[2]: Tavernier, Vincent, et al. "Making gabor noise fast and
normalized." Eurographics 2019-40th Annual Conference of the European
Association for Computer Graphics. 2019.
[3]: Tricard, Thibault, et al. "Procedural phasor noise." ACM
Transactions on Graphics (TOG) 38.4 (2019): 1-13.
Pull Request: https://projects.blender.org/blender/blender/pulls/121820
This multiscattering term comes from the OpenPBR specification and nicely
preserves energy while correctly modeling increased saturation at high
roughness.
Preparation for adding a diffuse roughness option to the Principled BSDF.
To me, the difference in output and computation seems small enough to
not need an enum for the old behavior.
Note that this also switches sampling to cosine-weighted, in my tests this
gives lower noise. I also checked doing MIS between cosine and uniform,
using the A term as a weight for how often to use cosine (since that term
is Lambertian diffuse), but always using cosine was better.
A nice consequence of that is that you don't get a huge noise jump when
going from 0.0 to 0.01 roughness.
Pull Request: https://projects.blender.org/blender/blender/pulls/123345
Cycles runs a check to see if the camera is possibly inside a
volumetric object by seeing if the bounding box of the camera
and volumetric object intersect.
If the calculation is wrong (Cycles says the camera is outside the
volume when it's inside it), then the volume will not render properly.
This commit resolves most of these issues by making the camera
bounding box larger than before, taking into consideration
features like:
1. The impact DOF could have on the camera ray start position and how
that should impact the bounding box size.
2. Taking into consideration near clipping, which was missed from the
orthographic camera due to a oversight in a previous commit
(08cc73a9bb).
Pull Request: https://projects.blender.org/blender/blender/pulls/123341
The base-4 Owen scrambling hash needs a seed value that's somewhat random-
looking, so the default value of 0 causes problems. Hashing the input seed
avoids this.
To avoid changing the noise pattern in pre-4.2 scenes, this hash is only
applied to blue-noise patterns.
Pull Request: https://projects.blender.org/blender/blender/pulls/123274
`num_distribution` in `KernelIntegrator` has type `int`, which holds a
maximal value of 2147483647. However, when computing the distribution,
`size_t` is used, which can go beyond this value and result in a
negative value when converted to `int`.
This PR handles this case as an error, stops rendering and suggests
alternative solutions.
Also early return when `use_light_tree`. The block was there because
`num_distribution` was needed for light tree before bfd1836861.
Pull Request: https://projects.blender.org/blender/blender/pulls/123177
Currently, during baking each pixel stores a seed input that comes from the
Blender side. This is only needed for vertex color baking, however -
for regular image baking, we can just as well hash the pixel coordinates.
Therefore, we can save some memory (4 byte per pixel) by splitting the seed
info out into a separate pass and only storing it when needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/122806
This patch implements blue-noise dithered sampling as described by Nathan Vegdahl (https://psychopath.io/post/2022_07_24_owen_scrambling_based_dithered_blue_noise_sampling), which in turn is based on "Screen-Space Blue-Noise Diffusion of Monte Carlo Sampling Error via Hierarchical Ordering of Pixels"(https://repository.kaust.edu.sa/items/1269ae24-2596-400b-a839-e54486033a93).
The basic idea is simple: Instead of generating independent sequences for each pixel by scrambling them, we use a single sequence for the entire image, with each pixel getting one chunk of the samples. The ordering across pixels is determined by hierarchical scrambling of the pixel's position along a space-filling curve, which ends up being pretty much the same operation as already used for the underlying sequence.
This results in a more high-frequency noise distribution, which appears smoother despite not being less noisy overall.
The main limitation at the moment is that the improvement is only clear if the full sample amount is used per pixel, so interactive preview rendering and adaptive sampling will not receive the benefit. One exception to this is that when using the new "Automatic" setting, the first sample in interactive rendering will also be blue-noise-distributed.
The sampling mode option is now exposed in the UI, with the three options being Blue Noise (the new mode), Classic (the previous Tabulated Sobol method) and the new default, Automatic (blue noise, with the additional property of ensuring the first sample is also blue-noise-distributed in interactive rendering). When debug mode is enabled, additional options appear, such as Sobol-Burley.
Note that the scrambling distance option is not compatible with the blue-noise pattern.
Pull Request: https://projects.blender.org/blender/blender/pulls/118479
This is an implementation of thin film iridescence in the Principled BSDF based on "A Practical Extension to Microfacet Theory for the Modeling of Varying Iridescence".
There are still several open topics that are left for future work:
- Currently, the thin film only affects dielectric Fresnel, not metallic. Properly specifying thin films on metals requires a proper conductive Fresnel term with complex IOR inputs, any attempt of trying to hack it into the F82 model we currently use for the Principled BSDF is fundamentally flawed. In the future, we'll add a node for proper conductive Fresnel, including thin films.
- The F0/F90 control is not very elegantly implemented right now. It fundamentally works, but enabling thin film while using a Specular Tint causes a jump in appearance since the models integrate it differently. Then again, thin film interference is a physical effect, so of course a non-physical tweak doesn't play nicely with it.
- The white point handling is currently quite crude. In short: The code computes XYZ values of the reflectance spectrum, but we'd need the XYZ values of the product of the reflectance spectrum and the neutral illuminant of the working color space. Currently, this is addressed by just dividing by the XYZ values of the illuminant, but it would be better to do a proper chromatic adaptation transform or to use the proper reference curves for the working space instead of the XYZ curves from the paper.
Pull Request: https://projects.blender.org/blender/blender/pulls/118477
Transport rays that enter to another location in the scene, with
specified ray position and normal. This may be used to render portals
for visual effects, and other production rendering tricks.
This acts much like a Transparent BSDF. Render passes are passed
through, and this is affected by light path max transparent bounces.
Pull Request: https://projects.blender.org/blender/blender/pulls/114386
This replaces the fixed Tangent input in BsdfNode::compile
with a custom input.
This is done because very few nodes actually use the tangent input
and it would be better to have this slot available for other inputs
on different nodes in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/119042
The slowdown was caused by the volume step calculation returning an
infinite value. This was caused by the calculation happening before
the object bounds are calculated via the code path which does some
early update for the displacement and hair transparency. The actual
value was never re-calculated after bounds are valid.
The solution is to only clear need-update after the final call of
the device_update_flags().
Pull Request: https://projects.blender.org/blender/blender/pulls/121042
by ensuring `KernelLight.lightgroup` is properly assigned in
`device_update_light()`. The value is later retrieved via
`lamp_lightgroup(kg, lamp)`.
`light_manager->device_update()` is called after
`background->device_update()`, so the background light group should
already been assigned when `device_update_lights()` is called.
Pull Request: https://projects.blender.org/blender/blender/pulls/120714
This is a regression since fdc2962beb
The size of state can not be different between CPU and GPU.
This change replaces compile-time condition with a kernel feature
check, which solves the render regression on AMD Metal. It also
minimizes the state size on other GPUs when Light Tree is disabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/120476
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
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
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
