Lightprobes.Positions why Read-Only? (Please provide feedback on this)

As a result of not being able to change Lightprobes.positions, I cannot use Lightprobes on levels that are dynamically created using tile sets. For instance, imagine each tile is a room with lights and that everything is self contained. i.e. None of the lights impact adjacent rooms.

Based on my testing(*) it looks like the results of the coefficient calculations remains consistent provided location of probes and lights (light sources) remains the same relative to each other.So, If I bake probes on a tile set located at (0, 0, 0) and then move the whole tile set to (12, 0, 12) where everything remains in the same relative position to each other, it should work. The only issue right now is that Lightprobes.positions is read-only... Why wouldn't this work? Am I missing something here?


(*) Please note that Baking probes without any scene changes yields slightly different coefficients from bake to bake. Is this normal behavior or a bug? I would love to understand why this is the case.

 

LightProbes.positions is read-only, because changing the relative positions of probes requires re-tessellating the space with tetrahedra and re-generating all the data associated with it. For now that code is editor-only, so you can't use it at runtime. Also it takes some time to do that, so for larger probe sets it would have to be done asynchronously.

It looks like there are two issues you mention. The first one is not being able to move the entire baked probe cloud while keeping the relative probe positions the same. You're right that wouldn't require recreating the tetrahedra, but for now API does not support it, since it's a corner case and you can often work around it by moving your geometry.

Another issue I'm guessing you have is that you would like to bake probes for each tile/room separately and then load them into the scene as you combine multiple tiles at runtime. This would definitely require re-creating the tetrahedra and for now Unity can't do that, sorry. Probes are baked data just like nav meshes and occlusion culling data and normally don't play that well with dynamically generated content.

There is a workaround that should work for you, though. You can write your own tool for placing the probes in grids in the scene view and you can probably also make sure the grid can be chopped up in per-tile pieces. Once you have a grid, probe interpolation is very easy, because it's just trilinear interpolation of the 8 probes forming the current grid cell (bilinear of 4 probes, if you go for a flat 2D grid). So you can still use beast to bake the probe coefficients for you, but hijack that data to do your own interpolation that works well with tile sets, and finally set the coefficients of the resulting interpolated probe as shader uniforms to render the object. Take a look at ShadeSH9() from UnityCG.cginc and Stupid SH Tricks, Appendix 10 to figure out that last part.

The coefficients differ slightly from bake to bake due to how Beast calculates GI using final gather. It has probably something to do with how memory allocation affects the algorithm, giving indeterministic results. Needless to say, it's also a bit annoying to us, as it makes automated testing somewhat harder.

 

Thank you for the feedback

What do you mean by corner case?

In terms of loading them at runtime, I wasn't planning on combining them since each of the tile / rooms are self contained. I was planning on swapping the probe solutions for each room as the player entered them. I was going to bake each solution one tile / room at a time at (0, 0, 0) location and then at run time, load the appropriate probe solution for that tile / room and offset / change the Lightprobes.positions to match the new location of the tile / room. Like (12, 0 ,12) with everything remaining in the same relative position.

Now as to the workaround you suggest, it will take me a few hours to think / process this suggestion

Thanks again for the feedback.

 

By corner case I mean it's not the most common way the API would be used. Typically a completely different array of probes would be assigned, not just all the positions offset by a vector.

I'm not sure I understand exactly what's your setup with the tiles/rooms. Is there always exactly one room in the scene and as player goes from one to the other, you delete the old one immediately and put in the new one? If so, you could bake all the probes for rooms at (0,0,0) and then also load all the rooms at (0,0,0), but just teleport the player. So if a player left room 0 through the door at (6,0,0), you would load room 1 still at (0,0,0), just teleport the player to (-6,0,0). Unless the transitions between the rooms don't allow for that...

 

Sorry for the delay in responding ... I had to sleep

Unfortunately, more than one room is visible at once. At most, two are visible as the player is transitioning (crossing the door frame) from one room to the other. Once the player has entered the new room, the previous room fades away and only the room where the player is located is now visible.

I figured that by carefully setting the lights and probes at those transition points (creating a volume that is pretty much the same and overlapping at the transition point in each probeset) that I could get a smooth transition from one room / Probe set to the other. But all that relied on the ability to change (offset) Lightprobes.positions which it seemed from all testing that it could have worked.

I'll take a look at ShadeSH9() and the Stupid SH Tricks.

Thank you again for your time

 

Ok, in that case: does the same room always get loaded in the same place in world space? If yes, then you could just bake all the probes in a scene that would contain all the possible rooms at their destination positions.

If not, then you could:
1. Create a grid of probes for the first room. Let's call this grid "the room grid".
2. Duplicate the grid of probes for every possible position of the other rooms you'll load in. If the rooms are arranged in a grid, that should be very easy. Let's call this grid of grids of probes "the master grid".
3. Bake the scene containing the master grid. It doesn't have to have any geometry or light, because here you only care for the tetrahedra structure to be created properly.
4. Bake each scene containing a single room in their own scene, but make sure to use probe positions from the room grid, properly aligned.
5. At runtime make sure the first scene contains the master grid.
6. Any time you load a new room into the scene, make sure to get the coefficients of the probes you baked for it and put them into the big array of the master grid coefficients in the right place. (the probes stay in the array in the same order you added them).

That's an alternative method to the one I suggested before. This way you don't have to do your own interpolation, but you have to mess around with the coefficients a little bit. I hope I didn't confuse you entirely by now

 

No. I use a Maze algorithm to determine which room will go where and the number of rooms.

I'll think about the method you suggest and see if I can figure out a way to make it work. The challenge is that each room contains different objects affecting light conditions (shadows, illumination, etc) so I sort of have to place the probes differently for each room.

Here are some images of some quick room prototypes sort of showing potential probe layout to try to capture interesting lighting / color samples. If the grid was uniform, the sampling points of the probes could be right on top of a light source skewing the sample or skip right over again skewing the samples... unless I am mistaken (which happens too often )

I so wish I could make this Read-only flag go away so I could simply change the Lightprobes.positions to offset them for the rooms new location.

 

Very nicely positioned probes, you definitely got the hang of it

And you're right that with a regular grid you would run into new problems, like some probes ending up within objects, being black and then making the character black as he would come close to it.

In that case I have yet another suggestion
1. Bake probes for each individual room separately, like you're showing in the picture. So every scene should contain just one room centered at (0,0,0).
2. Assign an empty game object called Anchor to the probe anchor property on your character's renderer.
3. When your character walks around the first room at (0,0,0) the anchor should be at his position and the probes for that room should be assigned to LightmapSettings.lightProbes.
4. When your character crosses the door into room 2 centered at, say, (1,0,0) you should assign probes baked for that room to LightmapSettings.lightProbes. Since your character will be walking in a room centered around (1,0,0) and the probes you just loaded are at (0,0,0), you should make sure Anchor.transform.position = character.transform.position - (1,0,0), so the Anchor should always be offset back by the room's offset.

This will work perfectly when you're walking around in the room, but will give a pop in lighting as you assign light probes for the new room. If you can't ignore that pop, there are two ways to fix it. One is to make sure just the area around the door is identical for all the light probe clouds you bake for each room. So inside the rooms you can have varying placement, but around the door there should be a rectangle of probes sticking out through the door a bit. Those probes by the door should have the exact same positions and exact same coefficients, so you will probably have to fix those positions from a script before baking and patch the coefficients after baking. But it's just two small editor scripts, you don't have to touch anything else and it should work perfectly.

Another way modifies the approach with the Anchor:
1. As before.
2. Disable "use light probes" on the character. Instead write a script, that will call GetInterpolatedLightProbe() at a position, where the Anchor was at, so character position minus room offset.
3. That will give you coefficients for the interpolated probe. To use it for rendering, check out ShadeSH9() and the pdf I mentioned before. It's just copy-pasting the functions, but it's a bit annoying, I know...
4. When you're at a certain distance from the door, use GetInterpolatedLightProbe() one last time and store as coefficients0. Load the probes for the new room and sample them with GetInterpolatedLightProbe() at a same distance from the door, but at the opposite side. Store as coefficients1. When the character goes between the two rooms, lerp between coefficients0 and coefficients1 based on his position until he reaches that certain distance from the door.
5. From then on you can resume sampling just the light probes of the new room.



I know in your case it would be easiest if you could just combine any two light probe clouds at runtime and maybe with so few probes it would even be fast enough, but the code that handles the tetrahedralization is still editor-only and you would have to wait a while before it makes into runtime for some future release. So I hope one of those solutions will work for you.

 

Thanks for your time and all the suggestions

I did a quick test of the Anchor idea and it looks like it might do the trick . In terms of the pop, just as you suggested, I was planning on having probes extend into the adjacent rooms, creating a small overlap where I could ensure light conditions are consistent in those transition areas from baked solution to the other.

Last comment / question about Lightprobes.positions. In this type of application (tiling), giving us the ability to change the Lightprobes.positions could be helpful. Although we could change the positions of individual probes, I don't see a scenario where doing it on a probe per probe basis makes sense. Therefore, given that we would need to change / offset the positions of the whole group, maybe considering adding something like LightprobeGroup.position may make sense?

[UPDATE] Did some additional testing transitioning from room to room and thus far this works. Unless I run into some weird issue, I am

Thank you Robert! You Rock!

 

Badass support, Robert!

 

This has got to be the best support I've ever seen; awesome detail as well as anticipating issues (eg. pop) and suggesting solutions for them. Robert for Unity President!!!

 

We have the similar situation here (It's a racing game with generating road) and we will try the solution you've offer, but also we have a traffic cars around the character car - is there any way to use lightprobes for them? Because on the edge of each piece you will see that traffic cars in forward of you are not lighted and then suddenly it became lighted as you switch to the new lightprobe goup.

Of cource we can make traffic unlited but it is not so nice looking as to use Light Probes for them

 

Resurrecting this old thread as we've run into the same problem. We want to be able to translate/rotate the entire probe cloud for similar reasons.

We're currently on 4.6 - but it sounds like 5.x lightprobes have taken a huge leap backwards - being broken for 6 months, and being unable to bake probes independently of lightmaps?

Lightprobes are a critical feature for mobile 3D games - but they seem to have been rather neglected in the push for shiny high-end features (much to the frustration of mobile developers who can barely get away with using basic postprocessing on real-world mid-spec devices, let alone even considering deferred shading, PBR, and real-time GI!)

I think the importance of Beast was rather underestimated.

 

Like the guy 5 years before me, I'm also sorry to resurrect this ancient thread, but the problem is still there although I'm not sure why because Unity seems to have fixed the critical part a while ago.

Short summary of the problem: Lightprobes can't be used for procedural levels that randomly connect different prefab-rooms together at runtime because Lightprobes.positions is read-only.

The reason for that:

In Unity 2019.3 these missing functions were finally added: LightProbes.Tetrahedralize and LightProbes.TetrahedralizeAsync

So now there is a way to recalculate the lightprobe data in runtime but Lightprobes.positions is still read-only.
Is this just an oversight or am I missing something here?

 

Bumping.

 

Also bumping. Unity seems to strangely be avoiding this issue. It makes using baked lighting for procedural games infeasible unless you're willing to effectively write your own light probes implementation.

 

Bump. Let us set the position

 

Another bump here.

 

@robert @Stephan-B bump

 

I need this Unity! However a good alternative is the Bakery lightmappers Volumes solution

 

Bakery is great if you're developing on a machine with Nvidia hardware and Windows, but it is not supported on other hardware or operating systems, which severely limits its usability on team projects.

 

Lightprobes are now a legacy feature. APV is the replacement from 2022.2 in preview and probably a 2023.x release. This is because a decade later requires more flexible and powerful approaches with easy authoring. Find out more from Enemies promo vid and here: https://forum.unity.com/threads/ada...erimental-release-for-hdrp-in-2021-2.1238824/

It'll head to URP as well. While I don't see the legacy probes going away soon, I also don't expect any work to be done on that part of Unity.

 

It's a shame that URP remains the '2nd class' render pipeline, with new features always going into HDRP first (even if they're not particularly high-end).

HDRP has a fairly niche audience, and URP is in a much better position to eventually replace the legacy pipeline. But it seems to be a low priority compared to HDRP.

(It's also a shame that the render pipeline updates are so tightly tied to Unity versions. It'd be great if we could get more render pipeline updates while sticking to a stable LTS version of the engine itself)

 

HDRP's team is tiny, they just work hard, all the time.

HDRP is only 'niche' if you count mobile. That's basically like saying "guys.... UE5 is only niche". HDRP also runs on way more hardware than you think. It runs on anything since 2013 basically. Should run on you too!

That is how it used to be and it was deliberately changed from that because it resulted in way more broken projects, misery and bug reports. Also they couldn't move forward at all, because every C++ change had to be backward compatible. It caused that the very complaint you have about URP being a 2nd class pipe.

Now they coupled to engine once again you get faster updates. They also changed how their versioning worked so that NDA code can be developed without blocking regular updates and fixed merging performance.

So now you have a brand new renderer added to URP called Forward+. Still not happy!