AcademySoftwareFoundation / AcademySoftwareFoundation/OpenPBR
Handling of raytraced subsurface entry/exit bounces
- Dominant language
- CSS
- Stars
- 793
- Forks
- 44
- PR merge metrics
- No merged PRs in 30d
Description
When implementing raytraced subsurface scattering, the look of the material can vary significantly based on how the entry/exit bounce at the layer interface is handled.
The draft spec currently doesn't explicitly mention how this is to be handled, but there are some references, e.g. mentioning that the albedo mapping may depend on the interface IOR.
Is this something that should be specified, or is it to be left as an implementation detail?
The approaches that I am aware of are:
- Perform a diffuse lambertian bounce at entry and exit: Easy to implement, but no particularly realistic and prone to overly white edges (since a significant fraction of rays will immediately hit the adjacent face and exit without ever scattering, regardless of incoming angle).
- Refract through the interface according to the microfacet distribution at entry and exit: Arguably the most correct approach, but has practical downsides - additional storage for the microfacet parameters is needed, multiple bounces might be needed due to TIR, the BSSRDF no longer converges to a lambertian BSDF for radius->0.
- Refract through the interface at the entry bounce, perform lambertian exit bounce: Provides most of the visual benefits of the full refraction approach while avoiding the downsides listed above.
Additionally, there is the question whether IOR and roughness values should be reused from the specular reflection lobe or specified separately.
Personally, if this is to be specified, I'd argue in favor of the "refractive entry, lambertian exit, reuse specular interface parameters" approach.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the draft spec's treatment of raytraced subsurface scattering, albedo mapping, and specular interface parameters. Compare the three entry/exit approaches and resolve whether IOR and roughness are reused or specified separately; done means the chosen behavior and parameter rules are explicitly documented.
Written by the indexing model from the issue text.
Assessment
- Domain
- computer-graphics
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100