Since upgrading to Unity 4 automatic lightmap atlasing has stopped packing UVs correctly for me. I’ve asked this over on answers but I’m having no luck, so trying here.
I create all my lightmap UVs outside of Unity and there is often empty space in the [0,1]x[0,1] UV square. Previously Unity would use up this space but in Unity 4 it leaves this space empty. Is anybody else seeing this?
Here’s a before and after…
Please check your UVs outside of Unity, using your modelling software.
Lightmap UV should put on channel 2.
Once bring in Unity,
uncheck “Generate Lightmap UVs”
uncheck “Swap UVs”
Turn on Lightmap Static for the Object, and Bake using Beast.
If the lightmap does not lighted your scene properly (leaking and black patch everywhere),
then it should be Unity Beast Lightmap bug,
else the UV2 for the Object is done it that way.
So…
I think the problem here is not with Beast though, it’s with the lightmap UV atlasing process, which I think is all done in Unity before Beast gets it.
Here’s the Unity 4 lightmap as above but I’ve highlighted a couple of the [0,1]x[0,1] UV squares. You can see that there is empty space in some of the squares which isn’t getting used up. In 3.5 this would get used up…
To make bake selected possible (and efficient) we needed to move away from texel packing to bounding box packing. The reason is that it’s easy to remember where each bounding box came from, but remembering that per lightmap texel would be too much.
So the effect you should be seeing is that concave areas of UV sets are no longer filled up with smaller UV sets, but when looking at (tight) bounding boxes everything should be nice and tightly packed. In practice our unwrapper rarely produces concave UV sets, so on levels we tested it on (like Angry Bots) there was no visible difference.
BUT! Your image shows that the bounding boxes of the UV sets aren’t tightly packed. So either there are some stray vertices in your UV unwrap that make the red boxes stretch all the way to [0,1]x[0,1] or it’s a bug in our atlasing code. Could you check if it’s the former and if not, submit a bug report with a small scene with a couple of those meshes and post the bug number here? Thanks!
The UVs are all confined to where they should be (not spread to the bounds of the UV square) so I’ve submitted a bug (#504094). This is a serious one for us as it triples our lightmap count and will likely not run on device because of memory limits. Thanks.
Thanks! We’ll take a look.
Any news about that huge bug ?
I’ve got the same problem, and in my case it can go to 1 object per LM, and the object takes 1/16 of the place, for an
“Object’s size in lightmap has reached the max atlas size” …
I’m at 85 LightMaps for a scene that takes 6 in unity 3.5…
And without mentioning that the base ratio calculated for the scene is horribly wrong between objects. Looking for the ratio previsualisation, and the diffrence between the shecker size for each object are huge, even when I use the automatic UV for all the objects.
And when they are pieces of the same roads with a difference 10,1551723 : 1 for one piece, 17,38971 : 1 for another, then 35,35871:1, how possibly correct that manually everywhere ???
It’s only when I maximize the scale in LM that I can have the same ratio everywhere. And it obviously not maximize the size in the LM, as you can see above, not mentioning the empty space, for a non-concave UV of a plannar mesh (a piece of road) with a centered pivot…
I would also like to know what is up with that bug, we’re having the same problem on our projects. Since we’re making texture atlas, the UVs or certain object leave huge gaps of empty space. Lightmaps on a previous project on 3.5 takes twice the size minimum in 4.0 !
@Aynis Scale in Lightmap 50? Its kinda big.
Here is the results. Meshes are set to Create LightMap UVs and are mapped to map1 in Maya with no out of bound UVs. You can see the black gap between the rectangular plane mesh uvs and it’s doing the same thing with they other meshes on the right and top.
Yeah, I know, but otherwise it’s impossible to have a correct ratio all over the differents meshes. Even if all the pieces have a uniform scale at 1, a correct sets of UV (1 and 2), and the same materials…
When two continuous pieces of the same road have totally differents ratio if the LM scale is 1, and that for almost all the pieces, it’s awfull when lightmapped. I’ve tried different ratio, but only the 50 make all looking fine and similar Oo And when I look at the maps created, it is not really at that scale as you can see in the picture, and really not using the maximum size of the map…
There really is a problem with the ratio and the atlasing in unity…
I’m getting a similar problem on my end. Every single lightmap generated for me is 1024 x 1024, no matter how small the scene is.
I made an empty scene with one cube, baked lights, and ended up with a 1024 x 1024 atlas. In 3.5 this would have been 128 x 128 or smaller. We’re unable to update bugs in our iOS game until this issue is fixed because it will increase memory usage in scenes that were already pushing memory limits. We’ve also had to drastically lower texel resolution in some scenes just to get them on single atlases. This seems incredibly broken.
@robert - Any news on the UV bounding box packing problem yet Robert? It’s getting more serious the deeper we get into production. Is there any way of writing a custom editor script to get around the problem for now? Thanks.
@Aynis - Though related, I think the ratio problem is a separate issue. I noticed slight inaccuracies with the ratio back in Unity 3. It’s possibly just a result of approximating UV shell scale from UV surface areas. I’ve mostly been able to live with it.
@MightyRabbit - This also sounds like a separate issue. I’ve not experienced this myself though.
I’ve just discovered that not only all the meshes with a second UVset are all in separate LM like my precedent picture, but also the atlas has just take the second UVset as it is.
No UVshell was moved, no reorganisation in order to low the maps of the scene like an atlasing should do. It’s like there has been no atlasing at all for those meshes Oo I’ve combined the maps in photoshop and without moving anything I’ve just reconstruct the UV I’ve made in maya, the simple up plannar with unfold (it’s for the roads, no need for a complicate method)
@Jde : about the ratio problem, in my case it’s really huge. And it exists allready in the previous versions. With a road cut in several pieces, and an night atmosphere, the ratio difference become really visible with every light source near the separations, not to mention the quasi-impossibility to correct it manually. And with a ratio problem, I don’t think that the atlasing could be efficent. After all, the atlasing is based on the UVshell’s size, those depends on the ratio. In my case, even with squared UV (no noticable blank space in the UV bounding Box) there are a lot of empty space in the other maps (not the ground part), pieces without manually created second UVset and a low ratio (between 1 - 5).
I’m pretty sure the atlasing process is not intended to separate individual UV shells from within a single mesh. So that’s correct behaviour you’re seeing. It should however be packing those shell groups better.
I can see how the ratio thing is hard to ignore in your case. And the ratio problem will certainly impact on the atlasing efficiency. I guess it’s just that the bounding box packing is the more serious problem for me right now. In my scenes the ratio problem wont be that noticeable. Worth bugging though (if you havent already).
I guess my english is very bad and my explanation was wrong ^^"
The road is separated in severals meshes. And every mesh has is own LM !!! The atlasing is inexistent for all thoses meshes : the UVs are in the same place than in maya.
The atlasing has to pack every UV shell the more efficently, same mesh or not. It’s like the Layout UV in maya : it packs the UV for all the meshes selected, using only the shells as reference, and the meshes are somewhere irrelevant (single or multi selection, it doesn’t care, it only pack the selectionned UV with the parameters we set).
In my scene, the atlasing separate the UV of every meshes with second UV in is own LM, without touching the shell, and only a 50ratio can make all the elements have the right ratio even if they use a very small amount of texture. It’s like it was saying :
Oh, a second UV set ! I won’t use it to calculate and organise the atlas, it’s simplier to use it as-is. And in case they are overlaping between the diffrent meshes, I will separate all the pieces in is own LM, so it’s clean. And the ratio ? I can’t calculate an accurate one, let’s say that 50 is the exact size of the second UV in the 10241024, it would be fine.
And tada, that’s exactly what I have ><
For me : big ratio errors + inexistant atlasing for every meshes that have second UVset = 86 10241024 LM
Unuseable for anything else than screenshots…
And the atlasing for the rest of the scene (Unity generated LM UVs) is broken too, with lot of blanck space (more than half the texture at least for one of them, 1/3 for 2 more … ) without any reason. And like for the road, if I check the ratio, it’s wrong. And I can’t correct all the ratios in hand (it’s a big town with lots of roads, places, buildings, and of course urban props everywhere…)
Its a big problem as well for us here. Look at what I get right now.
It could easily be 2 lightmaps, now its 4 with huge gaps!
Hi all.
I am having the same issue and for us this is a massive problem. However, considering how much of an issue this is there doesn’t feel like there is enough noise around it from the community. I have also contacted other companies that say they are not having these problems.
This makes me wonder if it software, export method specific.
I’m using a Mac running Maya 2013 and exporting using FBX. Are we all using the same software/import method?
I’m using Maya2012, FBX export, and windows7 64bit.
From what I have seen, it seems to happens for a specific reason but I havent been able to pinpoint the problem. I have this issue on one project but not on the other.
The difference seems to be on the scale of the environment and the shapes of the meshes to lightmap. I could partly fix the problem by cutting somes pieces so their UV are layed in squares rather than rectangles
Im using Maya 2012 with the latest FBX exporter. I was using a previous version but updating did’nt fix the problem… however, since it seems to be project related, I dont think the exporter is to blame.
Thanks for the quick response.
I have thought about face mapping everything in a similar method to Ptex which will do the same sort of thing Julinoleum is suggesting. Still not ideal.
I will have a play with scene scale and import scale. Thanks for the tip.
Sorry Julinoleum, but are you Maya users aswell?
Ok cool. The studio I contacted are Max users and have not had this issue. We are all Maya users, so It might be worth looking at how Maya scene scale effects things.
I’ll do this and post my results on here. Thanks for the help all.
