TSL twin of glass-partition.ts: the per-fragment depth partition of the emissive
data around refract_data glass, for the WebGPURenderer graphs (native WebGPU and its
WebGL2 fallback).
Two things differ from the GLSL side, both forced by TSL:
The fragment's own window depth is a varying. Every Luxar data graph replaces
the vertex stage (material.vertexNode), so three's positionView-derived depth
nodes would read a quad-corner attribute, and no TSL node exposes fragCoord.z.
The vertex body assigns its clip zw to clipDepthVarying; per fragment
z / w is the rasterizer's own screen-linear depth (perspective-correct
interpolation of z and of w cancel), remapped to window depth by
GlassFragmentDepthNode according to the renderer's coordinate system —
z/w already IS window depth under WebGPUCoordinateSystem, z/w * 0.5 + 0.5
under WebGL's. Window depth in [0, 1] is the one quantity both conventions share
with the depth texture, so the compare needs no further care.
The depth texture is sampled at screenUV, exactly as three's own
viewportDepthTexture does: screenUV is top-left-origin on both backends and
TextureNode Y-flips a depth texture on the GLSL builder (_flipYUniform), so the
same graph is orientation-correct on WGSL and on the WebGL2 fallback. A depth
texture's node type is float, so the sample IS the depth (no .r).
The guard emits its two Discards onto the CALLER's stack — it must be called inside
the fragment Fn body, first — rather than through a nested Fn, the same rule the
other shared helpers in tsl-helpers.ts follow.
TSL twin of
glass-partition.ts: the per-fragment depth partition of the emissive data aroundrefract_dataglass, for the WebGPURenderer graphs (native WebGPU and its WebGL2 fallback).Two things differ from the GLSL side, both forced by TSL:
material.vertexNode), so three'spositionView-derived depth nodes would read a quad-corner attribute, and no TSL node exposesfragCoord.z. The vertex body assigns its clipzwto clipDepthVarying; per fragmentz / wis the rasterizer's own screen-linear depth (perspective-correct interpolation ofzand ofwcancel), remapped to window depth by GlassFragmentDepthNode according to the renderer's coordinate system —z/walready IS window depth underWebGPUCoordinateSystem,z/w * 0.5 + 0.5under WebGL's. Window depth in [0, 1] is the one quantity both conventions share with the depth texture, so the compare needs no further care.screenUV, exactly as three's ownviewportDepthTexturedoes:screenUVis top-left-origin on both backends andTextureNodeY-flips a depth texture on the GLSL builder (_flipYUniform), so the same graph is orientation-correct on WGSL and on the WebGL2 fallback. A depth texture's node type isfloat, so the sample IS the depth (no.r).The guard emits its two
Discards onto the CALLER's stack — it must be called inside the fragmentFnbody, first — rather than through a nestedFn, the same rule the other shared helpers intsl-helpers.tsfollow.