Say NO to LPPV!

I thought LPPV died a quiet death but, no, just like The Blob, a little bit remained and it ate someone's brain to grow back to this.

It's under consideration by the URP team.
So if, like me, you've used LPPV and quickly dropped it in the pits of hell where it belongs, Go >here< and Say No to this monstrosity of bad performance and bad workflow.

To get an idea of what is good, look at Mr.F's Bakery lightmapper. Zero light probe placement, just dip your scene in a volume and voila, you get voxel lighting. Ambient only costs 1x3D texture fetch and diffuse+specular costs 3x3D texture fetch which ends up being slightly slower than light probes (on low end hardware) and substantially faster than LPPV, and, more importantly, super easy to deploy.

 

That link only has ways to say yes to LPPV, and no real ways to say no.

 

We can try to rise Up this thread about solution in Backery
https://forum.unity.com/threads/bak...-texture-to-prevent-breaking-batches.1056617/

 

That's a legit reason though.

I guess the question to answer is if you make a replacement for it, are people using LPPV now willing to convert their work to it?

Because otherwise, I'm under the impression that LPPV wasn't a very popular feature, because it kinda performed bad and didn't look that great and with URP / HDRP trying to be more modern, LPPV has no place in them IMO.

 

LPPV as Unity implements it, is not good. I use Bakery though and am thankful it exists. Unity should definitely have a look at improving things.

 

A similar thing that I'd currently like is a 3D texture 'volume shadowmask' for a main directional light.

My current setup is a mixed directional light (Shadowmask mode, so baked directional shadows), with baked point lights, but using a real-time duplicate copy of important short-range point/spot lights set to only affect specific layers (dynamic objects, particularly characters)

What's missing from this is shadowing of dynamic objects when they go into an area of baked directional shadow.

A 3D shadowmask texture might solve this problem. Resolution will obviously be limited as 3D textures quickly become huge, but it could be pre-softened and bilinear filtered, and I'm really just looking to darken the characters as they enter large shadowed areas.

Maybe I'll have a go at implementing something myself at some point...

 

Yeah actually I've coded a projected cookie for that sort of thing but it's not volumetric just directional. What you ask for is in Bakery, of course. Why wouldn't it be

 

They are working on probe volume for URP.

 

Ah, cool - so it is - have just switched over to Bakery recently, hadn't seen that it could bake shadowmask volumes though.

It's already been very nice having access to at least parts of the source code, too. It looks like I can hack the BakeryVolume script to discard the volumes I don't need (maybe I can avoid baking them if I delve deeper into it), and just keep the shadowmask volume.

It's a step closer to a more open/scriptable bake pipeline, something that I've felt Unity has been in need of ever since the extremely painful transition from Unity 4.x to 5.x (with a project full of lightmaps+probes)

 

It bakes volumes in a 3D texture that can achieve the same effect, sorry I wasn't clear.

 

Would somebody explain to my why you're all against this? It's actually the same technique used in tlou2 for shadowing (one of the many). If only it wasn't bound to unity's baked lightprobes though, I wish it would have a custom lightprobe slot or have access to the logic to make my own : \

 

TLOU2’s implementation is quite different, (a lot of parts are in compute shader, results are supplied in texture3d form)

 

How do we know what this lppv implementation is doing? There's no saying about it's internal logic (like everything unity pretty much) in the documentation? The only thing I understood is that it's using a texture3d

 

You can download the shader sources, look at the cginc files and have an idea about how it works.

But even better, you can try using the feature as it is currently implemented in Unity and draw your own conclusions from how it performs and from how it feels using it.

 

It's been written about a lot and benchmarked. Unity staff have also commented on it's excessive use of resources in the past, and how to get around it in one of their support pages on the subject.

Do your own testing of course.

 

Yeah trust these guys, they've gone through loads of productions and initially drank the Unity koolaid like before wising up.
There is so much about a production to worry about, if you want peace, avoid Unity's lightmapping, get Bakery+RT, use volumes and then buy everyone a beer for saving your marriage.

 

I would agree if you were starting from zero and your only alternative is unity lighting system... But we managed to make our own lightprobe system that we can actually move around and properly use for procedurally generated levels (before bakery volumes were a thing). So now I must choose between trying to hack lppv, make one of my own or discard everything to use volumes (which are way lower in quality and you can clearly see the voxels until proper compression for 3d textures is introduced, unless you know something I don't?!).
What would you do if you were in my position? ^^ an lppv tech would make our game lighting look very believable but there's no info on it's internal works and we don't even know what the shader is expecting from the lppv (while there's enough documentation on lightprobes and how to send your custom sh9 data to unity's own shader)

Also, yeah, it feels like I'm in an abusive relationship with unity so thank you for the counseling XD

 

bakery now has compression on 3d textures, you trade one type of artifact for another but hmmm yeah frankly i barely can tell chromatic artifacts when compression is on
one thing that balloons vram usage is that volumes need a fairly hefty overlap of at least the size of your largest dynamic object, since bakery's implementation doesn't lerp between volume, that can be remedied by changing the way volumes are uploaded to the gpu and change the shader to do 12 3D texture fetch.

I don't know your target hardware, style or the max size of your dynamic object so I don't know what position you're in.
I just know that bakery works super fast, RT workflow is awesome if broken (usually takes a shake of the mouse or a retry), performance impact of volume is below 5% on a switch with a megaton of dynamic objects, and cherry on the cake (who puts icing on cakes! ) Mr.F even managed to reconstruct specular highlight from volumes so you don't even need realtime lighting.

LPPV bakes the contained SH lightprobes into a 3d textures EVERY UPDATE, then sends it to the client material, different world to uvw coordinate conversion but same format as bakery: L0 L1 L2. More than that, follow @AcidArrow suggestion and read the shader, in non URP it's quite readable.

 

My target hardware is high end pc with fairly realistic graphics, i care about performance but fidelity comes first for us. I would find quite disturbing if LPPV would bake every frame for every object that's using it, i would definitely disable sampling updates on objects outside the view frustum and also from those that didn't move from last frame or even do it every nr of frames if it's not the main character or monsters. The problem is this is all guessing and none of it is customizable from our end.

I'll take your guy's suggestion and read the cginc file to see what I can dig off, i really think i should do one of my own.

About bakery volumes, do you have any guide to suggest for proper implementation? I may be testing them wrong, i did one bake the size of one of our rooms and raised the 3d texture resolution till I've got a similar quality to the lighrpobes.

 

Just in case if somebody like me was looking fo it it's in the UnityCG.cginc

Code (CSharp):

1. #if UNITY_LIGHT_PROBE_PROXY_VOLUME
2.  
3. // normal should be normalized, w=1.0
4. half3 SHEvalLinearL0L1_SampleProbeVolume (half4 normal, float3 worldPos)
5. {
6.     const float transformToLocal = unity_ProbeVolumeParams.y;
7.     const float texelSizeX = unity_ProbeVolumeParams.z;
8.  
9.     //The SH coefficients textures and probe occlusion are packed into 1 atlas.
10.     //-------------------------
11.     //| ShR | ShG | ShB | Occ |
12.     //-------------------------
13.  
14.     float3 position = (transformToLocal == 1.0f) ? mul(unity_ProbeVolumeWorldToObject, float4(worldPos, 1.0)).xyz : worldPos;
15.     float3 texCoord = (position - unity_ProbeVolumeMin.xyz) * unity_ProbeVolumeSizeInv.xyz;
16.     texCoord.x = texCoord.x * 0.25f;
17.  
18.     // We need to compute proper X coordinate to sample.
19.     // Clamp the coordinate otherwize we'll have leaking between RGB coefficients
20.     float texCoordX = clamp(texCoord.x, 0.5f * texelSizeX, 0.25f - 0.5f * texelSizeX);
21.  
22.     // sampler state comes from SHr (all SH textures share the same sampler)
23.     texCoord.x = texCoordX;
24.     half4 SHAr = UNITY_SAMPLE_TEX3D_SAMPLER(unity_ProbeVolumeSH, unity_ProbeVolumeSH, texCoord);
25.  
26.     texCoord.x = texCoordX + 0.25f;
27.     half4 SHAg = UNITY_SAMPLE_TEX3D_SAMPLER(unity_ProbeVolumeSH, unity_ProbeVolumeSH, texCoord);
28.  
29.     texCoord.x = texCoordX + 0.5f;
30.     half4 SHAb = UNITY_SAMPLE_TEX3D_SAMPLER(unity_ProbeVolumeSH, unity_ProbeVolumeSH, texCoord);
31.  
32.     // Linear + constant polynomial terms
33.     half3 x1;
34.     x1.r = dot(SHAr, normal);
35.     x1.g = dot(SHAg, normal);
36.     x1.b = dot(SHAb, normal);
37.  
38.     return x1;
39. }
40. #endif

Time to see if we can make propertyblocks and pass these data to the main shader to make it believe it's using the proxyvolume...

 

B has tons of settings, best you join the bakery discord.

 

Nah I did, nobody answers and MrF is a busy guy. Also yeah compression is implemented but not in any official release capacity yet (and the non official is broken at the moment)

 

what's your discord name? F only replies once a week, also he's far more reliable on github.
elefantopia#3229 is my discord handle if you want to bug me maybe i ran into the sort of problems that's crapping out your project, it took me a while to set it up right.
In my prod volume look much better than probes and is far more detailed obviously, it could be that you set up your lighting to unity's L2 and set bakery in default L1 which will give you negative values. yeah, so many variants that it's better you attach a few photos and info concisely in case someone ran into it. #srplife * bakery settings
btw, the last mid-release patch works, - I use it in production. Don't use github for patching or you'll kill someone, use this instead https://discord.com/channels/648434698825236481/648811209390292992/834843504354132020

 

Oh thank you for your offer but don't worry about it, I was confirmed a couple of days ago by MrF that he fixed the errors I was having, I'm going to test bakery volumes once again shortly!

Speaking of tests, I did my research and seems like I'll have to modify unity shaders a bit to make it accept custom lppv which is very annoying considering I didn't have to do it for lightprobes... which probably means I'll give up on it cause I can't just work on fixing unity's engine issues, at some point I'll need a game to go with these graphics features ^^

 

if you're using shader graph or BetterShader's template (so keeping Unity's lighting functions). You can set the unity_SHxx" float4s in your fragment program regardless of how they're calculated (per-object, per-pixel), before the lighting functions. So you could sample your version of a LPPV there.

I actually don't think LPPV is bad and I would have voted for it.

This is misleading because it's something like a 4^3 to 16^3 Texture3D. I believe the main performance issue was sampling the light probe network. Volume vs LPPV are almost the same thing, except the object is moving through the volume so the volume doesn't need to update it's values, but there's tradeoffs.

Isn't this only for BIRP where there is the option to use non-linear SH?