USD Shader Ball converted for use with glTF

[echadwick-artist]

This is an adaptation and conversion of the USD Standard Shader Ball asset.

Various adjustments were made to the original USD asset, for optimal use with glTF real-time rendering scenarios.

Rendered in threejs editor, "Realistic" pathtracer mode versus "Solid" rasterizer mode.

SSS Rendered in Babylon.js on the left and Adobe Substance Stager raytracing on the right

[MiiBond]

Is this correct?
The node's scale should also be applied to the thickness value so the final thickness in the shader is given as a product of the node's scale with the thicknessFactor and thicknessTexture value. Since the node already has a 0.01 scale on it, I would expect the thicknessFactor to be something between, say, 1 and 9 since the shader ball is about 9 cm on each side.

[echadwick-artist]

Please feel free to change it to whatever makes sense. Unfortunately I don’t have any more time available this week to work on this.

[MiiBond]

Okay, I've updated the thicknessFactor and rebaked the thickness texture using Substance Painter.
I think this makes sense now but it would be good to have someone else in the working group double-check my logic.
My memory (and reading of our spec) is that the thickness should be defined as the largest dimension of the mesh in the local coordinate space of the mesh which, in this case, is in cm. That's where I got the 8.9 from. The transform of the mesh node then converts this to metres.
The thickness texture is baked with fully-white representing the full thickness of the bounding box. So, that's why the thickest parts of the map are still grey. I used a spread angle (of the sample rays) of 90 degrees rather than the default of 180 as it gave better accuracy around the subsurface bars.
Finally, I renamed the "material" node and material to "material_surface" to match the original USD name. I thought that it was nice to be consistent with the original naming and it also makes it easier to programmatically search for this material. I don't have strong feelings about this though, if we want to change it back.

[MiiBond]

I made another update to remove the "flat_nm" normal map. This shouldn't be needed by any renderer and might force a more expensive code path unnecessarily.

On the subject of normals and tangents, I just thought I'd show an example of how awesome your improvements to the asset are when compared to the original conversion that I had made last week. This is anisotropy (which uses the mesh's tangents) in Babylon OpenPBR:

Old asset:

New asset:

[echadwick-artist]

Thanks @MiiBond !

I guess it's ok to have four "Info"s in the glTF Validator for unused tangents? Probably better than including the unused normal map.

We should probably update the screenshot for the new thickness map. And recreate the main screenshot.

Did you test in a rasterizer vs. pathtracer? Looks pretty divergent, at least in threejs editor:

[MiiBond]

Yeah, the unused tangent warning might be something that we want to discuss removing. @emackey? Tangents are needed some some effects (like anisotropy), regardless of whether a normal map is used.

[MiiBond]

@echadwick-artist Three.js and Babylon.js both do screenspace refractions (very common in a rasterizer) and are always going to produce very divergent results from a path tracer. You can try to refract more accurately using the depth of the refracted pixel along with geometry shape and thickness information but the end result is still very much a hack that should give the impression of a refractive material rather than one that closely approximates a path tracer.

What we really get from the thickness map is the ability to approximate the final colour due to absorption and the opacity due to scattering.