"Lightmap Index" and Draw-Call Batching

Looking at the Frame Debugger shows a lot of draw-calls are generated because of different lightmapIndex values in our game.

I assumed objects with the same material, which are close to each other, would share the same lightmap(index) if there is enough space on the texture.

However, it seems Unity does not try to assign the same lightmap to objects in close proximity, which would reduce draw-calls, because of less render state changes when rendering what's in the view.

This is basic stuff, but I'm new to lightmaps and I must be missing something here. What can I do to achieve that Unity assigns the same lightmap to objects in close proximity?

Spoiler: Actual lightmap index

Spoiler: Mockup with lightmap indices I would expect

 

They were planning to do that, I don't think it has landed in any release (yet?).

https://forum.unity.com/threads/progressive-lightmapper.454362/page-15#post-3777937

 

Many thanks for the quick answer!

 

Hi Rasmusn,

many thanks for your answer. I was able to reduce draw-calls by 38% by using the "Baked Tag".

Below I describe how I achieved this and would like to get some feedback on whether this is the approach you recommend, because it felt kinda odd in the way I used it.

My initial assumption was that "Baked Tag" would be part of a Renderer. That would allow me just iterate over all renderers in a scene and assign a baked tag. However, there is no Baked Tag in a Renderer, but there is the LightmapParameters object.

In order to assign a different Baked Tag to individual objects, I created a few hundred LightmapParameters assets in the project and assigned an unique bake tag to each of those assets.



Then I wrote an editor tool that spatially groups renderers ("world" is represented by several square cells/sectors) and assigns one of those LightmapParameters asset depending on what cell in the world-grid the renderer occupies. This makes sure all objects in a world-cell use the same baked tag.

Before


After


A draw-call reduction of about 38%. That is great!

However, the workflow of having those hundreds of LightmapParameters assets in the project feels like that's not the way you want your users to work with that. Specifically because it seems there is no way to only modify the baked tag. What if I want to keep all settings the same except for the baked tag?

How would you assign the Baked Tag automatically to renderers without having to create hundreds of LightmapParameters?

Thanks for your help!

 

Any ETA when PLM will support automatic lightmap tag grouping?

 

Any progress on this?

 

Is there a reason this isn't prioritised? It seems like a relatively straightforward/backend change that would be a free performance win across the board for most developers. I am asking because I am wondering if this is not something Unity thinks is worth investing effort in, maybe it is not as big of a deal as it seems and I shouldn't invest time in it either.

​

If not, could we have some reliable lightmapping callbacks (https://docs.unity3d.com/ScriptReference/Lightmapping-bakeStarted.html this doesn't work when Auto is enabled) and some way to manipulate lightmap params pre-bake via code?

I was thinking I could hook into bakeStarted, collect renderers, group them, instantiate lightmapParams's for each cluster and assign them to their own lightmaps that way, marking them as DontSave https://docs.unity3d.com/ScriptReference/HideFlags.DontSave.html

This seems like it'd work, but only if the user pressed Bake button, and I am not sure what happens if the bake is cancelled - do I get a bakeCompleted callback? I guess not, because it didn't complete? I have no reliable way to clean up.

Not to mention it all feels very janky and gross.

 

I don't know if it's a huge deal, but it's definitely a "nice to have".

I think they have completely frozen the lightmapper feature set to be able to get it out of preview.

I sincerely hope that once they get it out of preview it's not the end of PLM development, but rather the start, since there are a bunch of features that would be really nice to have (this one included), which should be reasonably easy (=a lot of work, but doable), once the basis is stable.

So I'm willing to give them a pass... for now.