Hi. Wanted to ask you a few questions about lightmapping in Unity.
First, are there any drawbacks to using lightmapping as a fast way to add baked ambient occlusion to animated or otherwise non-static objects in the level? Essentially, what I’m doing is this:
Import models with the lightmap UVs generation turned on.
Situate them in the scene in a way that will rule out unwanted shadows or occlusion (scattered in the air, for example).
Mark them as “Static” so that the lightmapper will accept them.
Bake the ligthmaps for the selected objects with appropriate settings for the task (no sun shadows, high AO, single map).
Disable the “Static” flag.
Move the objects into their place in the level.
Animate them (rotation, movement, diffuse color multiplier, etc.).
Experience unease and shame about the inappropriate thing I just did with the lightmapping system.
Here is the example with multiple lightmapped objects participating in an animation:
Some dirty seams on the generated UVs aside, this workflow saves me enormous amount of time that I would have otherwise spent creating UVs and a texture manually - when I usually don’t need anything on the said texture except for the baked AO. It’s will be invaluable if I will encounter a project where tons of animated hard surface models will be required quickly.
So, are there any drawbacks to using lightmaps on objects like those? I’m worried about three things the most:
How can I disconnect the lightmaps from the level they were baked in and make it possible to transfer them freely just like all the other resources linked to the models across any levels I’d like? At the moment I’m thinking of creating a shader that will read the second UV channel instead of the first, thus allowing me to move all generated lightmaps to the Materials folder near the model and assign them to the model through the traditional material properties, thus ditching the level-bound lightmapping system entirely. Is that a good way of doing it? Are there any problems accociated with using lightmaps as traditional textures?
Are there any issues associated with removing the Static flag from the ligthmapped objects? I know that it helps the batching (fortunately I probably won’t have more than one instance of an object like that per level), helps with occlusion (fortunalely it’s not usually a concern for the scenes I’m targeting) and allows the lightmapping system to work. So far, no issues relevant to my goals. Is there anything I am missing?
I’m not sure how multiple object’s lightmaps are atlased together, that can prove to be a problem if I will move to using the lightmaps as traditional per-object textures. Potential solution will probably be to create a separate level dedicated only to lightmapping, set the lightmapping resolution to something low (like x512) and bake only one object at a time, therefore creating texture maps that can be used with 1.0;1.0 scale and offset later (atlases, on the other hand, will require guessing the offsets and scale for each objects, which is unreliable and inconvenient). Is that a good idea?
Nope. The static flag actually doesn’t really exist at runtime; it’s just used by various systems in the editor (lightmapping, occlusion, batching, and navmesh) but as you’ve observed it’s not appropriate for your object to be used by those systems anyway.
It sounds like you should skip the atlasing step and force Unity to use particular values - you can edit an object’s atlas values directly via the Lightmapping window (the ‘Object’ tab). Set the scale and offset values to (1, 1) and (0, 0) to use the whole lightmap. You’ll also need to set the lightmap index to something in the 0-254 range - if you want to bake multiple objects at once, each object needs a unique index value, and that determines which lightmap file will be generated for the object (LightmapFar-X.exp, where X is the lightmap index). Then just turn on ‘Lock Atlas’ in the Bake settings to force Unity to use your manually-entered values.
Awesome, that will save me a lot of time otherwise spent baking each object separately.
A bit off the topic then: can you recommend any particular values for the properties in the Advanced tab of the Generate Lightmap UVs that will work best with the sort of geometry I’m showing on the screenshots above? In particular, something that will force generated UVs to have as few seams per smoothing group as possible (even at expense of stretching or leaving some of the tile area unoccupied). I’m interested in that to make wrapped cylindrical surfaces (that are very abundant there) to be predominantly represented with just one or two islands per surface. Right now they can often get pretty fragmented, which can be pretty visible from AO inconsistencies.
Here is a screenshot from a completely different scene, but showing a similar issue on the pipes:
I take it you’re doing it manually? As far as I remember from trying it some time ago, automatic flatten unwrapping wasn’t very nice there (too much fragmentation and wasted space).
It’s not great, but if you make sure that all your vertices and UVs are welded first, it’s not terrible. We used MAXScript to batch-flatten-UVs all the objects at first, and then went back and redid the worst offenders by hand. The results have been reasonable, though I think in the future I’ll probably figure out some way to export the generated lightmap UVs from Unity back to Max.
I wouldn’t call myself a lighting expert, but that all sounds like it should work.
Possible alternative, if wrestling with Unity turns out to be difficult: you could always use another program to bake lighting information into the textures directly, so that all of this is taken care of before you even bring the assets into Unity.
Unity’s light probe system is also pretty powerful without using too many resources, if you’re at all interested in dynamic lighting.
I’m mostly interested in this workflow because it allows me not to spend any time on proper unwrapping, so baking outside of Unity won’t really happen, as there are no valid UVs for a bake (unless you’re talking about 3ds Max auto flatten, which is a fair bit worse than UVs generated by Unity).
Sounds interesting, I’ll make sure to try it too, thanks!
