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.
Unfortunately that’s correct, you can’t vote against it. But the reason this card is there is that we had serveral feature requests about it, mainly for parity and upgradability. When we are not confident about a feature request and whether we should invest in it, we add it to “in consideration” section to gauge interest and receive more feedback about the use cases.
We also read the feedback messages and we don’t just look at the vote count, and I can already see the feedback against it that was submitted recently as well ;). Anyway, if we don’t receive enough valid use cases or reasoning in the feedback, we will very likely not go ahead with it and try to go after better and more modern replacement option.
As a reminder, if you don’t see a card for a feature you need, you can always submit a request through the same board.
And thank you for raising your concerns and providing your feedback here too.
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.
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
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)
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 : \
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.
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.
) Mr.F even managed to reconstruct specular highlight from volumes so you don’t even need realtime lighting.