I’ve lightmapped my scene and instances of a single model, which appears several times, all appears to lightmap correctly, even when Playing from within Unity. However, upon build and playing the build, a few of those instances all but have disappeared entirely, while other instances remain in tact.
This has only happened after a Lightmap test on High quality with 3 bounces. Is it doing this because it ran out of texture memory or something in the app? Why not when running it in the editor?
Anyone else encounter this? Anyone else know how to fix this? I’m about to try deleting all lightmaps and rebaking, but I doubt that’s actually the issue since it works when running in-editor.
Edit: And yep, the disappearing instances are indeed marked static and they appear lit when running in-editor with all realtime lighting turned off. It’s just during the build that they disappear.
To flush lightmaps and start over with a fresh bake, I just delete the folder Beast generated containing the lightmaps, right? That won’t mess up anything?
A lot of people seem to be doing lightmapping lately, heh.
You actually hit the “Clear” button on the lightmapper panel to clear out the lightmaps. Then delete the folder (in the editor) if it hasn’t been deleted for you automatically (I forget if it does or doesn’t).
How many lightmaps did you bake? Was it more than 256?
Ah, thanks. I’ll try that next. And it was 176 lightmaps at 1024x1024. Beast is spitting out lightmaps at that res which only use 1/4th the area… a lot. Any way around that to optimize texture memory (preferably in an automatic fashion)?
Cleared the lightmaps, deleted them, rebaked on Low, 1 Bounce, Amb.Occ. for 3 hours. Same thing happened= the object instances showed up when running in the editor, but when running a build, they disappeared.
No idea what’s going on here.
I cleared the lightmaps and deleted them again, ran a build with realtime lighting and the instances showed up like they should. Just can’t get these particular instances to show up after a bake and build. It’s always the same instances that fail to render, while other identical instances elsewhere in the scene consistently render correctly.
Upon keeping the Lightmapping tab open while clicking on the instances that disappear on build-run, I noticed there is a note under ‘Scale in Lightmap’. It is set to 1, like the others, but a note appears under it ‘Object’s size in lightmap has reached the max atlas size’.
This particular instance of the object is indeed larger than the others. But that doesn’t make sense for a reason for the issue, since there’s an even larger object instance of another model that does still lightmap and display correctly. It has the same notice, but still displays correctly. In fact, there are numerous objects with this notice and they still display correctly.
For the object instances that are failing to render on build-run under lightmapping (it’s only one model type), I’m going to try rebaking after applying ‘Generate Lightmap UVs’ to that model in the Import settings.
While this model was appearing correctly elsewhere in the scene, it’s my hope that this will fix any confusion Unity was having over it under lightmapping only.
Interesting problem. What size is the UV map for that object that is giving the error message? If I understand how it works correctly, if there is no UV2 already, and you don’t have “Generate Lightmap UVs” selected, then beast will use a copy of UV1 as its UV2. However, by default, Beast creates 1024x1024 lightmaps. If your UV1 is bigger than that, that may be why you are getting that error message? I dunno, I’m just guessing here.
But yeah, I’m guessing your issue has something to do with that error message. It may go away when you allow Unity to generate lightmap UVs, like you are trying now. If not, trying reducing the “scale in lightmap” for that object until that message goes away (and then you could just do a “bake selected” assuming you are using Unity 4).
As for your issue of Beast not packing lightmaps very well, yeah, I get the same problem. It’s annoying, but as far as I know there is no fix for it. Maybe there is something in the Beast XML file that could be tweaked (my understanding is there is lots of stuff in there we don’t have direct access to in Unity) but that is beyond my knowledge. I’m willing to bet, though, that someone has created an asset that will better pack those maps, if you hunted through the asset store. I need to look for such a thing myself
What quality level are you running at in the editor, versus in the built app?
If you’re running at a quality level in the editor that’s got textures set to e.g. quarter res, and then in the app you’re running them on full res, you might be running out of texture memory at runtime and that’s why it’s not working.
Have you checked your player log file?
Packing efficiency mostly comes down to UV2 efficiency. The packer uses the bounding rectangle of the UV2 coords for your mesh when packing, so you if you’re creating your UV2s by hand, you’ll want to arrange them so that they form a rectangle with the minimum possible wasted space between islands. Unity’s built-in UV2 generator attempts to do this automatically I think.
The ‘scale in lightmap’ thing just means that the object is taking up the full width or height of a lightmap yet still isn’t at the texel density you requested, so quality will suffer - e.g. if you requested 50 texels/meter, but you’ve got a big polygon that is 25meters long, that polygon needs 1250 texels along its edge to reach that resolution, so can’t fit into a 1024x1024 lightmap - at best it can do around 40 texels/meter.
Also, I just finished the test bake after generating UVs on that model, despite it appearing correctly on many instances. That fixed it. However this was a Low settings Bake with only 20 rays, so next I’m going to do a High bake with 1000 rays, which should take about 8 hours. That’s to make sure the quality settings don’t affect this issue, eg-- increased quality = increased texture memory usage = instances being dropped from rendering.
I’ll report back my findings, but this should hopefully be a handy tip for many working with lightmaps and large-scale environments.
Increasing the number of rays shouldn’t affect the amount of texture memory used by the results, only the amount of memory used during baking.
If you want the memory to be 100% predictable (and the bake to be slightly faster) then you may want to turn on ‘lock atlas’ in the bake settings - that will skip the pre-bake packing process, so everything will use the same lightmap index/subrectangle as in the low-quality bake. This guarantees for you that the number of lightmaps used will be the same.