I've been porting the LTCGI shaders to URP (with single-pass instanced stereo so both eyes render right in VR) and have a working branch: Simple URP + Surface (APIv2) URP variants plus a small LTCGI_URP_Compat.hlsl shim. Tested rendering in a URP project, and confirmed it changes nothing in a BiRP/VRChat project — the URP files are purely additive, no BiRP shader or shared include touched.
Before opening a PR I wanted to check how you'd prefer to structure it, because of one snag: a URP .shader living in the package throws a red error in any BiRP-only project —
Shader error in 'LTCGI/Surface (APIv2) URP': Couldn't open include file
'Packages/com.unity.render-pipelines.universal/ShaderLibrary/Core.hlsl'
Unity compiles the SubShader at import even with "RenderPipeline"="UniversalPipeline" set, and there's no shader-level "is URP installed" define to guard the include with. Since most LTCGI users are on BiRP/VRChat, I don't want to land something that spams their console.
A few ways to keep BiRP projects error-free, depending on how you'd like it to live in the package:
Samples~ folder — URP shaders ship as an importable sample; BiRP projects never compile them. Single package, one opt-in click for URP users.- Separate
at.pimaker.ltcgi.urp package depending on URP + the core package — only installed in URP projects.
- Editor-generated define — a small script detects URP and writes a define the shaders guard the include with, plus a BiRP fallback SubShader, so it's truly drop-in. More machinery / a generated in-tree file.
Happy to do whichever fits your preferences (or something else) — the branch is ready to shape into a PR. What would you like?
Branch / diff for reference (current state, vs your main): main...towneh:ltcgi:main — that's the two URP shaders + compat shim, a cull-mode option ported onto the URP Surface v2, and a small compile-gate on the Light Volumes adapter so it doesn't try to build in a non-VRChat/URP project.
I've been porting the LTCGI shaders to URP (with single-pass instanced stereo so both eyes render right in VR) and have a working branch:
Simple URP+Surface (APIv2) URPvariants plus a smallLTCGI_URP_Compat.hlslshim. Tested rendering in a URP project, and confirmed it changes nothing in a BiRP/VRChat project — the URP files are purely additive, no BiRP shader or shared include touched.Before opening a PR I wanted to check how you'd prefer to structure it, because of one snag: a URP
.shaderliving in the package throws a red error in any BiRP-only project —Unity compiles the SubShader at import even with
"RenderPipeline"="UniversalPipeline"set, and there's no shader-level "is URP installed" define to guard the include with. Since most LTCGI users are on BiRP/VRChat, I don't want to land something that spams their console.A few ways to keep BiRP projects error-free, depending on how you'd like it to live in the package:
Samples~folder — URP shaders ship as an importable sample; BiRP projects never compile them. Single package, one opt-in click for URP users.at.pimaker.ltcgi.urppackage depending on URP + the core package — only installed in URP projects.Happy to do whichever fits your preferences (or something else) — the branch is ready to shape into a PR. What would you like?
Branch / diff for reference (current state, vs your
main): main...towneh:ltcgi:main — that's the two URP shaders + compat shim, a cull-mode option ported onto the URP Surface v2, and a small compile-gate on the Light Volumes adapter so it doesn't try to build in a non-VRChat/URP project.