-
Notifications
You must be signed in to change notification settings - Fork 1.2k
KHR_materials_volume_scatter (replaces #1928) #2453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
KHR_materials_volume_scatter (replaces #1928) #2453
Conversation
…nstead of transmission in example json
|
I personally don't care what you call it, but MaterialX standardSurface, Disney BSDF, Blender Principled, OpenPBR etc. All call it subsurface scattering. Trying to build bridges between systems works easiest (both mentally and technically) when systems align. If they are fundamentally different then I totally get it, but if they align, it may be operationally easier to call it the same thing.. |
|
There's a conceptual difference. The mentioned material models define subsurface scattering as a surface based effect, i.g. a BSSRDF. Some of them additionally define volume scattering (e.g. the transmission_scatter properties in the translucent base of OpenPBR). However, in reality, subsurface scattering is simply dense volume scattering, making separate parameter sets somewhat redundant. This proposal aims to generalize and eliminate redundancy by introducing just a single parameter set that defines the physical behavior of a volumetric medium using scatter and attenuation properties (KHR_materials_volume). The name KHR_materials_volume_scatter should emphasize that it is a pure volume feature, that depends on KHR_materials_volume. Renderers may not support actual volume scattering or may have optimized techniques for dense scattering. This section explains how combining this extension with KHR_materials_diffuse_transmission can help signal a dense (subsurface) scattering scenario. |
....0/Khronos/KHR_materials_volume_scatter/schema/glTF.KHR_materials_volume_scatter.schema.json
Outdated
Show resolved
Hide resolved
…scription; Fix coyright date
The extension in this PR defines volumetric scattering and serves as an replacement/alternative to #1928
Changes wrt. #1928
Naming
Choosing "KHR_materials_volume_scatter" over "KHR_materials_subsurface" clarifies that this extension addresses general volumetric scattering and that it functions only in combination with a real volume (by using KHR_materials_volume). The term "subsurface" scattering is often linked with dense scattering scenarios, such as wax or skin, which can be misleading - dense scattering is just one specific configuration of this extension (also see section on scattering + diffuse transmission).
Scatter albedo replaces scatter coefficient
In KHR_materials_subsurface #1928, scatter color and distance are used to specify the scattering coefficient directly. This PR proposes using multi-scatter albedo instead, aligning more closely with approaches in OpenPBR (subsurface) and Enterprise PBR. Using scatter albedo also better harmonizes with the definition and naming of attenuation parameters in KHR_materials_volume.
Adding scatter anisotropy
Discussion
There has already been some discussion in the PBR TSG on whether to use single-scatter albedo or multi-scatter albedo. Multi-scatter albedo, being a derived parameter, requires conversion to single-scatter albedo. The PR currently suggests the conversion method proposed by Kulla & Conty. What happens if potential future alternative conversions prove more effective? Comments suggested that it is possible to keep the normative part of the multi-scatter albedo abstract and declare the actual equation non-normative.
Currently, volume parameters are not allowed to be texturable. OpenPBR does permit this. As @proog128 notes, should we also decide to allow this at some point, for texturable scatter albedo, the conversion would need to be computed per pixel within the shader.