Tested versions
Reproduced on 4.8.dev.custom_build.d66836467, built from nvidia-pt-dlss-dev at [e001932](e001932). Also present on [7b6dd6d](7b6dd6d), so not a recent regression.
System information
Windows 11, RTX 4060 Laptop, Vulkan 1.4.325, Forward+, DLSS Ray Reconstruction
Issue description
The fork has no dielectric transmission. evalIndirectCombinedBRDF handles DIFFUSE_TYPE and SPECULAR_TYPE only, there's no Fresnel/refraction path, and no per-instance back-face cull override — so a material intended as glass renders fully opaque under PT.
I've implemented it, based on e001932958:
Transmission — a TRANSMISSION_TYPE lobe using exact unpolarised Fresnel with TIR, reflect-vs-refract chosen inside the lobe so the selection probability cancels against the lobe value. Materials opt in through declared pt_* uniforms read by name (pt_transmission, pt_ior, pt_absorption, pt_absorption_distance); nothing is inferred from raster channels. RT_MaterialData grows 96→128 bytes to carry a precomputed Beer-Lambert sigma. Transmissive instances set TRIANGLE_FACING_CULL_DISABLE — without it exit interfaces are never hit and the lobe degenerates to a single-refraction shell.
Transmissive shadows — shadow rays return per-channel transmittance rather than binary occlusion. The any-hit accumulates signed optical depth (+back / −front) so the result is independent of traversal order, since any-hit invocation order is unspecified.
Three things turned up along the way that seem like straight-up bugs:
cast_shadow has no effect under PT. The TLAS instance mask and all four traceRayEXT cullMasks are hardcoded 0xFF, so the mechanism is present and inert. Fixed with three mask bits at raster parity, which needed the full ShadowCastingSetting plumbed to RenderGeometryInstance — only the cast_double_sided_shadows bool arrives today.
- Texture-less emissive materials contribute nothing. Emission is gated on
RT_MAT_FLAG_HAS_EMISSION_TEX, only set when a texture exists. Energy 48 and 480 render identically because both evaluate to zero.
StandardMaterial3D triplanar falls back to plain UVs, because raster triplanar is generated shader code the hit path never runs.
Also coalesced slSetConstants per frame token — it was re-sent on every re-entry, flooding the log with Streamline duplicate-constants warnings.
Known limits: delta lobes only, no rough refraction. Convex bodies; nested media out of scope. Absorption depth is the traced chord through the tessellated hull, so transmitted shadow quality scales with mesh density (opaque shadows only need the silhouette and are unaffected). The USE_RAY_QUERY_SHADOWS path is updated for consistency but untested — that path isn't enabled in my build.
Branch: Puddlefunk/godot @ pt-transmission — 9 commits, 14 files, +571.
Steps to reproduce
All four reproduce on an unpatched build of this fork. Scene setup for each: any 3D scene, Environment.pathtracing_enabled = true, scaling_3d/mode = DLSS.
1. Transmissive materials
Open https://github.com/Puddlefunk/pt-glass-demo on a stock build. All six spheres render as opaque white — pt_glass.gdshader's fragment body only feeds the raster proxy, and there's no engine-side lobe to transmit.
Confirmable without running: brdf_inc.glsl defines DIFFUSE_TYPE and SPECULAR_TYPE only; evalIndirectCombinedBRDF has no third branch.
2. cast_shadow ignored
Put three identical meshes over a lit plane, set cast_shadow to On / Off / Shadows Only. All three behave identically under PT — the Off one still casts, the Shadows Only one still renders.
Confirmable in the source: instance masks are pushed as 0xFF in build_tlas (render_raytracing.cpp), and all four traceRayEXT / rayQueryInitializeEXT sites pass cullMask 0xFF. RenderGeometryInstance never receives the setting — only cast_double_sided_shadows is plumbed through.
3. Texture-less emissives contribute nothing
StandardMaterial3D, emission enabled, no emission texture, black albedo. Sweep emission_energy_multiplier from 1 to 480. No change at any value.
Cause: emission is gated on RT_MAT_FLAG_HAS_EMISSION_TEX in the closest-hit shader, and process_material only sets that flag when an emission texture exists.
4. Triplanar falls back to plain UVs
StandardMaterial3D with uv1_triplanar enabled, on a mesh whose UVs differ visibly from a triplanar projection. Raster and PT views disagree.
Cause: raster triplanar is generated shader code the hit path never runs, and the flags are shader-code state that never reaches the params table the PT material snapshot reads.
Minimal reproduction project (MRP)
https://github.com/Puddlefunk/pt-glass-demo
Runs on any build of this fork. On a stock build all six spheres render as opaque white — pt_glass.gdshader only feeds the raster proxy, so with no engine-side lobe there's nothing to transmit. That's the control.
To see transmission, build Puddlefunk/godot at branch pt-transmission.
godot.windows.editor.x86_64.exe --path pt-glass-demo
Keys 1–4 — fixed camera positions, defined in code so framing is identical on any machine
F1 — HUD
F2 — cycles the four DLSS-RR guide views
P — scripted constant-rate pan, saves eleven frames to res://shots
Backtick — console; set <prop> <value> writes any Environment property
For cast_shadow specifically, the relevant probe isn't in this project — the three-pillar test (one On, one Off, one Shadows Only, plus a mirror to check the INDIRECT bit) still lives in my game project and honestly rn I need to catch up on some sleep. i can update the demo but i'm sure if you've read this far you'll work it out.
Peace :)
[@lsikkesNV](https://github.com/lsikkesNV) — tagging you directly since I wasn't sure how closely this repo's issues are watched; happy to be redirected if there's a better channel. I can split these into small PRs if you like, some are two line fixes, or i can leave it alone entirely if it collides with anything you've done in parallel.
**** this series of patches was written with heavy AI assistance. i verified behavior empirically for each change, including several hours of frame analysis, however i'm well aware i'm somewhat out of my depth within this domain and i don't want to misrepresent that. ****
Tested versions
Reproduced on 4.8.dev.custom_build.d66836467, built from nvidia-pt-dlss-dev at [e001932](e001932). Also present on [7b6dd6d](7b6dd6d), so not a recent regression.
System information
Windows 11, RTX 4060 Laptop, Vulkan 1.4.325, Forward+, DLSS Ray Reconstruction
Issue description
The fork has no dielectric transmission.
evalIndirectCombinedBRDFhandlesDIFFUSE_TYPEandSPECULAR_TYPEonly, there's no Fresnel/refraction path, and no per-instance back-face cull override — so a material intended as glass renders fully opaque under PT.I've implemented it, based on
e001932958:Transmission — a
TRANSMISSION_TYPElobe using exact unpolarised Fresnel with TIR, reflect-vs-refract chosen inside the lobe so the selection probability cancels against the lobe value. Materials opt in through declaredpt_*uniforms read by name (pt_transmission,pt_ior,pt_absorption,pt_absorption_distance); nothing is inferred from raster channels.RT_MaterialDatagrows 96→128 bytes to carry a precomputed Beer-Lambert sigma. Transmissive instances setTRIANGLE_FACING_CULL_DISABLE— without it exit interfaces are never hit and the lobe degenerates to a single-refraction shell.Transmissive shadows — shadow rays return per-channel transmittance rather than binary occlusion. The any-hit accumulates signed optical depth (+back / −front) so the result is independent of traversal order, since any-hit invocation order is unspecified.
Three things turned up along the way that seem like straight-up bugs:
cast_shadowhas no effect under PT. The TLAS instance mask and all fourtraceRayEXTcullMasks are hardcoded0xFF, so the mechanism is present and inert. Fixed with three mask bits at raster parity, which needed the fullShadowCastingSettingplumbed toRenderGeometryInstance— only thecast_double_sided_shadowsbool arrives today.RT_MAT_FLAG_HAS_EMISSION_TEX, only set when a texture exists. Energy 48 and 480 render identically because both evaluate to zero.StandardMaterial3Dtriplanar falls back to plain UVs, because raster triplanar is generated shader code the hit path never runs.Also coalesced
slSetConstantsper frame token — it was re-sent on every re-entry, flooding the log with Streamline duplicate-constants warnings.Known limits: delta lobes only, no rough refraction. Convex bodies; nested media out of scope. Absorption depth is the traced chord through the tessellated hull, so transmitted shadow quality scales with mesh density (opaque shadows only need the silhouette and are unaffected). The
USE_RAY_QUERY_SHADOWSpath is updated for consistency but untested — that path isn't enabled in my build.Branch: Puddlefunk/godot @
pt-transmission— 9 commits, 14 files, +571.Steps to reproduce
All four reproduce on an unpatched build of this fork. Scene setup for each: any 3D scene,
Environment.pathtracing_enabled = true,scaling_3d/mode = DLSS.1. Transmissive materials
Open https://github.com/Puddlefunk/pt-glass-demo on a stock build. All six spheres render as opaque white —
pt_glass.gdshader's fragment body only feeds the raster proxy, and there's no engine-side lobe to transmit.Confirmable without running:
brdf_inc.glsldefinesDIFFUSE_TYPEandSPECULAR_TYPEonly;evalIndirectCombinedBRDFhas no third branch.2.
cast_shadowignoredPut three identical meshes over a lit plane, set
cast_shadowto On / Off / Shadows Only. All three behave identically under PT — the Off one still casts, the Shadows Only one still renders.Confirmable in the source: instance masks are pushed as
0xFFinbuild_tlas(render_raytracing.cpp), and all fourtraceRayEXT/rayQueryInitializeEXTsites pass cullMask0xFF.RenderGeometryInstancenever receives the setting — onlycast_double_sided_shadowsis plumbed through.3. Texture-less emissives contribute nothing
StandardMaterial3D, emission enabled, no emission texture, black albedo. Sweepemission_energy_multiplierfrom 1 to 480. No change at any value.Cause: emission is gated on
RT_MAT_FLAG_HAS_EMISSION_TEXin the closest-hit shader, andprocess_materialonly sets that flag when an emission texture exists.4. Triplanar falls back to plain UVs
StandardMaterial3Dwithuv1_triplanarenabled, on a mesh whose UVs differ visibly from a triplanar projection. Raster and PT views disagree.Cause: raster triplanar is generated shader code the hit path never runs, and the flags are shader-code state that never reaches the params table the PT material snapshot reads.
Minimal reproduction project (MRP)
https://github.com/Puddlefunk/pt-glass-demo
Runs on any build of this fork. On a stock build all six spheres render as opaque white —
pt_glass.gdshaderonly feeds the raster proxy, so with no engine-side lobe there's nothing to transmit. That's the control.To see transmission, build Puddlefunk/godot at branch
pt-transmission.godot.windows.editor.x86_64.exe --path pt-glass-demoKeys 1–4 — fixed camera positions, defined in code so framing is identical on any machine
F1 — HUD
F2 — cycles the four DLSS-RR guide views
P — scripted constant-rate pan, saves eleven frames to
res://shotsBacktick — console;
set <prop> <value>writes anyEnvironmentpropertyFor
cast_shadowspecifically, the relevant probe isn't in this project — the three-pillar test (one On, one Off, one Shadows Only, plus a mirror to check the INDIRECT bit) still lives in my game project and honestly rn I need to catch up on some sleep. i can update the demo but i'm sure if you've read this far you'll work it out.Peace :)
[@lsikkesNV](https://github.com/lsikkesNV) — tagging you directly since I wasn't sure how closely this repo's issues are watched; happy to be redirected if there's a better channel. I can split these into small PRs if you like, some are two line fixes, or i can leave it alone entirely if it collides with anything you've done in parallel.
**** this series of patches was written with heavy AI assistance. i verified behavior empirically for each change, including several hours of frame analysis, however i'm well aware i'm somewhat out of my depth within this domain and i don't want to misrepresent that. ****