Cycles: add distance-dependent transmission color in Principled BSDF #111806

Weizhen Huang · 2023-09-01T21:34:21+02:00

Weizhen Huang commented

2023-09-01 21:34:21 +02:00

attenuate the ray color so that a white light becomes exactly the base color after traveling the distance specified in Transmission Depth. When set to zero, the tint is constant as before.

This is realized by adjusting the transmission and reflection color via sd->ray_length when the mesh is backfacing. The result is very similar as attaching an additional Volume Absorption node to the Material Output. However, the main point of the new parameter is to be able to control the exact color at certain depth. This is currently very difficult via the Volume Absorption node because it uses 1.0 - weight as the extinction coefficient (see fa34992def/intern/cycles/kernel/svm/closure.h (L832)). If change that to -log(weight), then Density is equivalent to 1.0 / transmission_depth:

Transmission Depth 0.1	Volume Absorption Density 10

The highlight difference near the eyes is because Suzanne mesh is not closed.

This poses the question that the behaviour is not well-defined when the mesh is not closed or when there are intersecting regions (as in nested dielectrics). In these cases the volumetric approach is arguably better. However, the current approach is simpler to implement, and seems faster and less noisy than the volume approach. Maybe a more sophisticated logic can be applied than just checking if the surface is backfacing (camera ray? The number of transmission events?).

Another problem is that there is already a Transmission Depth in the Light Path Node, which means something different, so the naming of the new socket seems confusing, but I couldn't think of a better name yet.

attenuate the ray color so that a white light becomes exactly the base color after traveling the distance specified in Transmission Depth. When set to zero, the tint is constant as before. This is realized by adjusting the transmission and reflection color via `sd->ray_length` when the mesh is backfacing. The result is very similar as attaching an additional Volume Absorption node to the Material Output. However, the main point of the new parameter is to be able to control the exact color at certain depth. This is currently very difficult via the Volume Absorption node because it uses `1.0 - weight` as the extinction coefficient (see https://projects.blender.org/blender/blender/src/commit/fa34992def0a162bddbec5d903ef043d547fc4f2/intern/cycles/kernel/svm/closure.h#L832). If change that to `-log(weight)`, then `Density` is equivalent to `1.0 / transmission_depth`: | Transmission Depth 0.1 | Volume Absorption Density 10 | | -------- | -------- | | ![13.52s](https://projects.blender.org/attachments/6768c9b4-8afa-4c8c-82b2-ed82647c904e) | ![15.59 s](https://projects.blender.org/attachments/6c1d4b53-dde7-4b4c-a0a3-305008659f8f) | The highlight difference near the eyes is because Suzanne mesh is not closed. ![Suzanne eye](https://projects.blender.org/attachments/82db3975-c5d6-441f-9fb2-af93354e0ef2) This poses the question that the behaviour is not well-defined when the mesh is not closed or when there are intersecting regions (as in nested dielectrics). In these cases the volumetric approach is arguably better. However, the current approach is simpler to implement, and seems faster and less noisy than the volume approach. Maybe a more sophisticated logic can be applied than just checking if the surface is backfacing (camera ray? The number of transmission events?). Another problem is that there is already a Transmission Depth in the Light Path Node, which means something different, so the naming of the new socket seems confusing, but I couldn't think of a better name yet.

glass_volume_absorption_15.59.png

176 KiB

Screenshot 2023-09-01 at 21.24.50.png

165 KiB

glass_transmission_color_13.52.png

175 KiB

Weizhen Huang added 1 commit 2023-09-01 21:34:34 +02:00

60d52649b8 Cycles: add ray length-dependent transmission color in Principled BSDF

Weizhen Huang added this to the Render & Cycles project 2023-09-01 22:11:34 +02:00

Alaska commented

2023-09-02 04:50:09 +02:00

Just for reference, a benefit of this approach is that it works with shadow caustics (Manifold Next Event Estimation) without further additions or modifications to the shadow caustics code. Adding a volumetric shader to the object does not work with shadow caustics.

This is probably a known issue or limitation of this technique. It seems objects inside transmissive objects render incorrectly (the transmission depth is the wrong length for objects inside transmissive objects).

There are two images below. "Actual result" and "Expected result". The "Actual result" is a transmissive cube with a perfect mirror in the middle. As you can see, there is a bright bit inside the cube. This comes from the transmissive depth being incorrect as it only takes into consideration the length from the mirror to the backface of the cube, not the combined length of cube to mirror + mirror to backface of cube. The "Expected result" is what I would expect in the real world, and this was achieved in Blender by removing the mirror inside the cube.

Actual result	Expected Result

.blend file: Transmission Depth Inside Object Example.blend

Just for reference, a benefit of this approach is that it works with shadow caustics (Manifold Next Event Estimation) without further additions or modifications to the shadow caustics code. Adding a volumetric shader to the object does not work with shadow caustics. --- This is probably a known issue or limitation of this technique. It seems objects inside transmissive objects render incorrectly (the transmission depth is the wrong length for objects inside transmissive objects). There are two images below. "Actual result" and "Expected result". The "Actual result" is a transmissive cube with a perfect mirror in the middle. As you can see, there is a bright bit inside the cube. This comes from the transmissive depth being incorrect as it only takes into consideration the length from the mirror to the backface of the cube, not the combined length of cube to mirror + mirror to backface of cube. The "Expected result" is what I would expect in the real world, and this was achieved in Blender by removing the mirror inside the cube. |Actual result|Expected Result| |-|-| |![Incorrect absorption for objects inside glass.jpg](/attachments/ddf65a2d-72c8-40a3-b0d3-45df120443ef)|![Expected result for absorption for objects inside glass.jpg](/attachments/a86e264c-ae2e-4127-b42e-51c914d33d57)| .blend file: [Transmission Depth Inside Object Example.blend](/attachments/dd1d5342-a3b8-483e-a3c0-46b792c3b971)

Transmission Depth Inside Object Example.blend

982 KiB

Expected result for absorption for objects inside glass.jpg

37 KiB

Incorrect absorption for objects inside glass.jpg

48 KiB

Alaska commented

2023-09-02 11:30:46 +02:00

Another problem is that there is already a Transmission Depth in the Light Path Node, which means something different, so the naming of the new socket seems confusing, but I couldn't think of a better name yet.

Arnold and Redshift calls this feature "Depth". I assume users understand that it's "Transmission Depth" due to context in the UI. Maybe once grouping and separators are added to nodes, the Principled BSDF could have a "Transmission" group with "Depth" as one of the options?

Renderman calls this feature "Transmittance Distance".

Mantra calls this feature "At Distance" in the "Absorption" section of their material. So it's probably "Absorption At Distance".

Here's some other names I thought of "Transmission Absorption Depth" or "Absorption Depth"?

While looking at what other render engines called this feature. I found that Mantra appears to do this feature differently.

Note: This is just speculation on how this feature works simply based on reading the documentation for Mantra.

Unlike this pull request where the absorption is applied based on the ray length from the previous interaction to the back face of the material. Mantra seems to enter a transmissive material and mark the ray as "inside transmissive material X". Each time the ray interacts with another surface, the absorption is applied based on the distance the ray traveled from the previous intersection. This keeps repeating until a light is hit, or the ray leaves the transmissive material by hitting a back face or by entering a higher priority nested dieletric. I assume this takes advantage of the medium tracking feature required for nested dieletrics to work, and hence probably isn't a viable feature to implement into Cycles until the ground work for nested dieletrics are implemented.

The approach I described above would solve some issues, and would support using this feature in conjunction with nested dielectrics, but there's still some weird behavior in cases like when the mesh is not closed.

> Another problem is that there is already a Transmission Depth in the Light Path Node, which means something different, so the naming of the new socket seems confusing, but I couldn't think of a better name yet. Arnold and Redshift calls this feature "Depth". I assume users understand that it's "Transmission Depth" due to context in the UI. Maybe once grouping and separators are added to nodes, the Principled BSDF could have a "Transmission" group with "Depth" as one of the options? Renderman calls this feature "Transmittance Distance". Mantra calls this feature "At Distance" in the "Absorption" section of their material. So it's probably "Absorption At Distance". Here's some other names I thought of "Transmission Absorption Depth" or "Absorption Depth"? --- While looking at what other render engines called this feature. I found that Mantra appears to do this feature differently. Note: This is just speculation on how this feature works simply based on reading the documentation for Mantra. Unlike this pull request where the absorption is applied based on the ray length from the previous interaction to the back face of the material. Mantra seems to enter a transmissive material and mark the ray as "inside transmissive material X". Each time the ray interacts with another surface, the absorption is applied based on the distance the ray traveled from the previous intersection. This keeps repeating until a light is hit, or the ray leaves the transmissive material by hitting a back face or by entering a higher priority nested dieletric. I assume this takes advantage of the medium tracking feature required for nested dieletrics to work, and hence probably isn't a viable feature to implement into Cycles until the ground work for nested dieletrics are implemented. The approach I described above would solve some issues, and would support using this feature in conjunction with nested dielectrics, but there's still some weird behavior in cases like when the mesh is not closed.

Weizhen Huang commented

2023-09-02 12:14:25 +02:00

Maybe once grouping and separators are added to nodes, the Principled BSDF could have a "Transmission" group with "Depth" as one of the options?

I think this is a good idea. “At Distance” also sounds very intuitive to me.

I am aware of the limitations @Alaska mentioned, so I’m also not sure if this is the approach we want to take. But I think it works well as an initial implementation, for the cases it doesn’t work, people can still use the volume, so there is no loss.
However, the volume approach looks unusually slow and noisy to me for such a simple scene, maybe I can dig in there a bit and see if there’s any issue with the volume. Or, we can revisit this patch once we have a better idea of how to support nested dielectrics.

> Maybe once grouping and separators are added to nodes, the Principled BSDF could have a "Transmission" group with "Depth" as one of the options? I think this is a good idea. “At Distance” also sounds very intuitive to me. I am aware of the limitations @Alaska mentioned, so I’m also not sure if this is the approach we want to take. But I think it works well as an initial implementation, for the cases it doesn’t work, people can still use the volume, so there is no loss. However, the volume approach looks unusually slow and noisy to me for such a simple scene, maybe I can dig in there a bit and see if there’s any issue with the volume. Or, we can revisit this patch once we have a better idea of how to support nested dielectrics.

👍 1

Weizhen Huang commented

2023-09-04 15:07:09 +02:00

Turns out that the excessive noise is because I enabled path guiding. Without path guiding both are much less noisy.
The 12% overhead because of the extra volume closure seems expected though.

Turns out that the excessive noise is because I enabled path guiding. Without path guiding both are much less noisy. The 12% overhead because of the extra volume closure seems expected though.

Brecht Van Lommel commented

2023-09-06 16:48:20 +02:00

I think we should use actual volume rendering here. In Standard Surface and upcoming OpenPBR, there are controls not only for absorption but also scattering. And dealing correctly with internal blocks and transparency I guess will be tricky even for the absorption only case. It will be slower but it seems acceptable.

The easiest way to implement this would be to modify the shader graph on the host side in PrincipledBsdfNode::expand. It would involve adding volume nodes linked to the Volume material output, using Add Shader nodes if something is already connected.

One issue with scattering and sharp refraction is that you end up with a volume caustic which is very noisy to render. The trick to sidestep this would be to either increase roughness on exit from a volume bounce, or to use a transparent BSDF instead of refraction. A transparent BSDF is probably most efficient.

I think we should use actual volume rendering here. In Standard Surface and upcoming OpenPBR, there are controls not only for absorption but also scattering. And dealing correctly with internal blocks and transparency I guess will be tricky even for the absorption only case. It will be slower but it seems acceptable. The easiest way to implement this would be to modify the shader graph on the host side in `PrincipledBsdfNode::expand`. It would involve adding volume nodes linked to the Volume material output, using Add Shader nodes if something is already connected. One issue with scattering and sharp refraction is that you end up with a volume caustic which is very noisy to render. The trick to sidestep this would be to either increase roughness on exit from a volume bounce, or to use a transparent BSDF instead of refraction. A transparent BSDF is probably most efficient.

Weizhen Huang commented

2023-09-06 17:12:14 +02:00

I don't think scattering would be a problem (do we want anisotropy or not?) but internal blocks might be, so I want to figure out how to do nested dielectrics first. 12% seems a lot to me.

Brecht Van Lommel commented

2023-09-06 17:37:06 +02:00

Scattering would support anisotropy.
https://autodesk.github.io/standard-surface/#closures/speculartransmission

We can perhaps optimize the fixed color homogeneous volume absorption case somehow, without it being Principled BSDF specific. It could skip shade_volume for that case, and instead at the start of shade_surface loop over the volume stack and compute the absorption, regardless of which material it is shading. That way it could correctly deal with internal geometry.

Scattering would support anisotropy. https://autodesk.github.io/standard-surface/#closures/speculartransmission We can perhaps optimize the fixed color homogeneous volume absorption case somehow, without it being Principled BSDF specific. It could skip `shade_volume` for that case, and instead at the start of `shade_surface` loop over the volume stack and compute the absorption, regardless of which material it is shading. That way it could correctly deal with internal geometry.

This pull request has changes conflicting with the target branch.

intern/cycles/kernel/osl/shaders/node_principled_bsdf.osl
intern/cycles/kernel/svm/closure.h
intern/cycles/scene/shader_nodes.cpp
intern/cycles/scene/shader_nodes.h
source/blender/gpu/shaders/material/gpu_shader_material_principled.glsl
source/blender/nodes/shader/nodes/node_shader_bsdf_principled.cc

View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u principled-transmission-tint:weizhen-principled-transmission-tint

git checkout weizhen-principled-transmission-tint

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles: add distance-dependent transmission color in Principled BSDF #111806

Checkout