`sd->type` was set to `PRIMITIVE_TRIANGLE` when it should be
`PRIMITIVE_LAMP`.
Function #lights_intersect_impl sets `isect->prim` to `lamp`, which is
passed to function #shader_setup_from_sample. There `prim != PRIM_NONE`
is evaluated to `true`, thus setting `sd->type` to `PRIMITIVE_TRIANGLE`
erroneously. This fix checks `lamp != LAMP_NONE` first, as in all other
usages of #shader_setup_from_sample `LAMP_NONE` is passed as the value
of `lamp`.
Pull Request: https://projects.blender.org/blender/blender/pulls/108769
In Embree, tfar modification is taken into account by rtcIntersect1
only when hits are accepted. In order to overcome this, we now check
manually for a max_t value in the filter function.
Pull Request: https://projects.blender.org/blender/blender/pulls/108706
We should be recording only the N closest hits in case the number of
hits is exceeding the maximum allowed or the size of the hits stack.
Previously, some cases made it record hits beyond the furthest recorded
one due to lack of hit distance check.
The input socket of Image Texture node is connected with the UV output
of Texture Coordinate node by default, the later reads the geometry UV,
which is not available for lights because they have no real geometry.
The current implementation simply retrieves UV from shader data.
Pull Request: https://projects.blender.org/blender/blender/pulls/108691
This is added so that some texture pipeline with point light and spot
light could work as before. Some people use the Normal socket from
Texture Coordinate node for texturing light, however the Normal there is
actually the incoming light direction and should be corrected. Using the
Parametric socket from Geometry node + normal transform from world to
object with Vector Transform node delivers the same result as using the
Normal socket from Texture Coordinate node.
Currently for lights only normal transformation works, because only
there we fetch light transform properly. This is a confusing behaviour,
but testing if it's a lamp in all relevant functions could have bad
impact on the performance. A more proper solution would be to change
lights to real objects, which is planned for the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/108666
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
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
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.
Only Embree CPU BVH was built in the multi-device case. However, one
Embree GPU BVH is needed per GPU, so we now reuse the same logic as in
the other backends.
Pull Request: https://projects.blender.org/blender/blender/pulls/107992
Used to be https://archive.blender.org/developer/D17123.
Internally these are already using the same code path anyways, there's no point in maintaining two distinct nodes.
The obvious approach would be to add Anisotropy controls to the Glossy BSDF node and remove the Anisotropic BSDF node. However, that would break forward compability, since older Blender versions don't know how to handle the Anisotropy input on the Glossy BSDF node.
Therefore, this commit technically removes the Glossy BSDF node, uses versioning to replace them with an Anisotropic BSDF node, and renames that node to "Glossy BSDF".
That way, when you open a new file in an older version, all the nodes show up as Anisotropic BSDF nodes and render correctly.
This is a bit ugly internally since we need to preserve the old `idname` which now no longer matches the UI name, but that's not too bad.
Also removes the "Sharp" distribution option and replaces it with GGX, sets Roughness to zero and disconnects any input to the Roughness socket.
Pull Request: https://projects.blender.org/blender/blender/pulls/104445
