WebGPUPathtracer: Iridescence extension#762
Conversation
|
This looks great!
Directional lights will require next event estimation so this is fine.
I would expect this to be the case. But the noise will potentially be primarily a result of the environment map and no NEE rather than issues with the iridescence path. Using a purely white or a gradient env map would make it easier to compare the results on the left-most dielectric model. I'm thinking if we can get that looking right then we can merge this? |
| ); | ||
|
|
||
|
|
||
| ` ); |
There was a problem hiding this comment.
Is this something that can be done with a mat3 in TSL, now? In the latest version of three.js global variable declarations are working:
const XYZ_TO_REC709 = mat3(
3.2404542, - 0.9692660, 0.0556434,
- 1.5371385, 1.8760108, - 0.2040259,
- 0.4985314, 0.0415560, 1.0572252,
).setName( 'XYZ_TO_REC709' );The variable will be declared globally by default.
| let phase = 2.0 * ${ Math.PI } * OPD * 1.0e-9; | ||
| const val = vec3(5.4856e-13, 4.4201e-13, 5.2481e-13); | ||
| const pos = vec3(1.6810e+06, 1.7953e+06, 2.2084e+06); | ||
| const _var = vec3(4.3278e+09, 9.3046e+09, 6.6121e+09); | ||
|
|
||
| var xyz = val * sqrt(2.0 * ${ Math.PI } * _var) * cos(pos * phase + shift) * exp(-phase * phase * _var); | ||
| xyz.x += 9.7470e-14 * sqrt(2.0 * ${ Math.PI } * 4.5282e+09) * cos(2.2399e+06 * phase + shift.x) * exp(-4.5282e+09 * phase * phase); | ||
| xyz /= 1.0685e-7; | ||
|
|
||
| let rgb = XYZ_TO_REC709 * xyz; | ||
| return rgb; |
There was a problem hiding this comment.
nit: some indentation issues. I wonder if there's any way to get these template strings to be linted in any way 🤔
There was a problem hiding this comment.
This is very weird, since in my editor its displayed correctly:
There was a problem hiding this comment.
It's a mix of tabs and spaces (you can tell by highlighting). I'm not sure what editor you use but editor config has a plugin for most IDEs (I think?) and will automatically configure "tab" behavior based on the config within a project to help enforce consistency.
|
|
||
| ` ); | ||
|
|
||
| const evalSensitivityFunc = wgslTagFn` |
There was a problem hiding this comment.
nit: Would be good to include the wgsl tag here for syntax highlighting:
wgslTagFn/* wgsl */`| let dielectric = ${ this.iridescentDielectricLayer }( | ||
| dielectricBase, diffuse, specular, ctx.VdotH, /* outsideIor */ 1.0, | ||
| surf.ior, surf.iridescenceIor, surf.iridescenceThickness, surf.iridescence | ||
| ); | ||
|
|
||
| let metallicBase = ${ this.conductorFresnel }( ctx.NdotV, ctx.VdotH, surf.color, specular, alpha ); | ||
|
|
||
| let metallic = ${ this.iridescentConductorLayer }( | ||
| metallicBase, specular, surf.color, ctx.VdotH, /* outsideIor */ 1.0, | ||
| surf.iridescenceIor, surf.iridescenceThickness, surf.iridescence | ||
| ); |
There was a problem hiding this comment.
I'm guessing for "outsideIor" this is something we'll need to track per ray? Something like the "current medium"? I expect other path tracers will track multiple mediums but I'm not exactly sure what the right way to do this would be considering we can have overlapping geometries 🤔
There was a problem hiding this comment.
Yeah, ior tracking is not really a viable option since we can enter a transmissive body, never hit a back facing triangle and still "exit" the body because of alpha transparency/non-watertight meshes.
If we think about it as an ior of medium that interfaces with iridescence layer, then its 1.0 ( other value in case there is a clearcoat layer? ) when triangle is hit from the front and ior of the object itself when hit from the back.
There was a problem hiding this comment.
Yeah, ior tracking is not really a viable option since we can enter a transmissive body, never hit a back facing triangle and still "exit" the body because of alpha transparency/non-watertight meshes.
I think it's okay. If users are marking non-watertight meshes as transmissive it will have to be expected that things may behave a bit oddly. This is a probably for another time, though, I think.
If we think about it as an ior of medium that interfaces with iridescence layer, then its 1.0 ( other value in case there is a clearcoat layer? ) when triangle is hit from the front and ior of the object itself when hit from the back.
I'm not sure I'm completely following this. Perhaps we're talking about different things, but Ignoring clearcoat for a moment (which I believe is modeled as above the iridescence layer) what I'm intended to say is: we're tracking a ray as it enters the iridescence layer, is color shifted based on the ior difference, and then bounced back out of it. So that "outside ior" depends on the medium that the ray had last entered - a ray entering a body of water and then bouncing off of an iridescent object, for example. The "outside ior" should have to be ~1.33 in that case and will impact the color shift from the model.
Not that we have to get to this level of granularity. I just want to know where the lines are at the moment and keep things in mind for later.
There was a problem hiding this comment.
If users are marking non-watertight meshes as transmissive it will have to be expected that things may behave a bit oddly. This is a probably for another time, though, I think.
Hm, I wonder if some kind of cheap check can be done on transmissive meshes for users that encounter weird artifacts. This ties into the idea of checking user's mesh attributes for valid tangent / normal combination mentioned in #758 (comment).
a ray entering a body of water and then bouncing off of an iridescent object, for example
Okay, yes, I overlooked that case. Ior would need to be tracked for correct interactions of light with objects inside of other objects. What I meant to say is that material has a layered model:
ray from back -> | base | iridescence | clearcoat | <- ray from front
So if the ray is entering from the back, it interacts with base and then transmits to iridescence layer which makes baseIor the outside ior for this interaction.
And if its entering from the front, then maybe clearcoatIor should be used as outsideIor for the interaction if the layer exists.
At least this is my understanding of how it should be modeled taking layers into account. I don't recall seeing this anywhere so should be double-checked.
Tracking current medium's ior does make me think about how one would determine ior in the camera point.
I agree, this is an issue for a more detailed transmission implementation.
There was a problem hiding this comment.
Tracking current medium's ior does make me think about how one would determine ior in the camera point.
In the WebGL version the ray origin is tested for being within any relevant volume using single raycast. If a backside is hit that means we're "inside" the volume. This was done for fog volumes, at least - I hadn't added transmissive volume support for this but the same should apply.
ray from back -> | base | iridescence | clearcoat | <- ray from front
This is my impression, as well, which gets a bit complicated. Though iridescent + clearcoat models may be less common.
|
I've gone ahead and implemented NEE with directional lights and env map sampling in separate branch (and a bunch more, but thats for later). And indeed, noise on the left suzanne is much lower:
So now I'm pretty sure about the implementation here. Let me know if you want to hold out on merging this or get more information. |
2 participants
This PR extends brdf to take into account iridescene. Code ported from official gltf example implementation and effectively equivalent to webgl. Iridescent fresnel calculation atleast seems to be the same. However, in practice images appear to be very different:
Notably:
I'm not confident in this implementation because that and would like to hold on to this until we can validate dielectric materials correctness with better sampling techniques.