- "Invalid" in transformation messages.
- For three messages, translation occured after a string
- concatenation, so the full message was not found.
Instead, translate a format pattern and format it afterwards.
- Alembic errors when there is an import type mismatch.
Pull Request: https://projects.blender.org/blender/blender/pulls/108212
While the multiscattering GGX code is cool and solves the darkening problem at higher roughnesses, it's also currently buggy, hard to maintain and often impractical to use due to the higher noise and render time.
In practice, though, having the exact correct directional distribution is not that important as long as the overall albedo is correct and we a) don't get the darkening effect and b) do get the saturation effect at higher roughnesses.
This can simply be achieved by adding a second lobe (https://blog.selfshadow.com/publications/s2017-shading-course/imageworks/s2017_pbs_imageworks_slides_v2.pdf) or scaling the single-scattering GGX lobe (https://blog.selfshadow.com/publications/turquin/ms_comp_final.pdf). Both approaches require the same precomputation and produce outputs of comparable quality, so I went for the simple albedo scaling since it's easier to implement and more efficient.
Overall, the results are pretty good: All scenarios that I tested (Glossy BSDF, Glass BSDF, Principled BSDF with metallic or transmissive = 1) pass the white furnace test (a material with pure-white color in front of a pure-white background should be indistinguishable from the background if it preserves energy), and the overall albedo for non-white materials matches that produced by the real multi-scattering code (with the expected saturation increase as the roughness increases).
In order to produce the precomputed tables, the PR also includes a utility that computes them. This is not built by default, since there's no reason for a user to run it (it only makes sense for documentation/reproducibility purposes and when making changes to the microfacet models).
Pull Request: https://projects.blender.org/blender/blender/pulls/107958
The additional SocktType::VECTOR argument was being interpreted as flags,
which caused the OSL compiler to skip the input (since the Vector type enum
happens to align with the INTERNAL flag), which caused the OSL shader to
always use the hardcoded default absorption regardless of what was entered.
On an iMac (Retina 5K, 27-inch, Late 2015) it crashed when rendering using Cycles. This was due to the fact that it incorrectly detected that the machine supported ray tracing. This uses the device.supportsRaytracing flag to fill in the use_hardware_raytracing flag for the device.
This is a continuation of a fix from the last week in #108311.
The issue was not fully fixed due to a mistake in the regression
test file.
There are two major things which left to be fixed since the
previous patch:
1. Root nodes can not be shared, even if the local and distant
lights belong to the same light set. If the root node is shared
then the flattening will use the same node index for specialized
trees, which is not a desired behavior.
2. The node type needs to be preserved when a new node is
created for a subset of emitters. This is because tree sampling
in kernel will handle distant and local lights differently for
nodes where there are multiple emitters.
Pull Request: https://projects.blender.org/blender/blender/pulls/108427
A couple of mistakes since the light linking commit:
- The +1 got missed in some of the refactors in the branch
- The order of arguments to the shadow path split was wrong
Pull Request: https://projects.blender.org/blender/blender/pulls/108420
This patch removes a workaround for an issue that is now understood to be undefined behaviour (and fixed by #108176). It also adds two useful debug flags that we would like to be available in Blender 3.6.
Pull Request: https://projects.blender.org/blender/blender/pulls/108322
On a user level this fixes configuration when a spot light is
linked to an object, and a sun light is not linked to anything.
It used to be making non-linked receivers to be very noisy.
This is because the distant light did not update the node's
light linking settings when they are added to the node.
A simple demo file will be added to the tests suit as
light_link_distant_tree.blend.
Pull Request: https://projects.blender.org/blender/blender/pulls/108311
Similar to objects, store the name of Blender's side light name
on the Cycles side. This allows to have readable logs where a
name and property is logged (while previously in the logs all
lights will be called lamp).
There is no user-measurable change.
Pull Request: https://projects.blender.org/blender/blender/pulls/108310
The original names were `...update_position()`, but no update in
position is performed in these functions, rather, the entries in
`LightSample` are updated. Also make clear that the functions are used
by MNEE.
This patch fixes an undefined behaviour where we were trying to use linked functions with binary archives. This isn't supported yet. At best this will fail silently, but this is not guaranteed in future. To fix this we simply disable binary archives if any linked functions are involved. The impact of this is that the `SHADE_SURFACE_RAYTRACE` and `SHADE_SURFACE_MNEE` kernels will fall back to the file system cache when MetalRT is enabled. The file system cache will occasionally be purged due to factors beyond Blender's control.
Pull Request: https://projects.blender.org/blender/blender/pulls/108176
