Good day,
I’ve encountered a problem with my lightmaps since 3.4.
Attached, you’ll see my scene, the big green plane is my waterfloor gameobject with a simple plane on it and a simple diffuse material. It is not static as I don’t want to lightmap it. Somehow when I’m baking my scene it gets asigned one of the lightmaps onto it.
Also, I have read the changelog and it says to reimport all my meshes… I did that (was quite long re-importing over 900 meshes by the way… I hope this won’t become standard procedure each time Beast is changed)
My guess is the UV’s are all messed up somewhere in the scene metadata for that game object. Any way to clean that up? Or delete/re-import only the UV data?
- Baking info: Single Lightmap, No GI, 25 Texels
Edit:
- I had to delete the plane and re-create it. And it stopped having lightmaps assigned to…
- All non-static objects are getting lightmap assigned to: See 2nd screenshot.
Whats up with that? Did I miss something soo evident I’m going to look like an idiot or is there something fishy here?
Sorry to bump… but 3.4 release-related problems stormed the forum…
the reimport was needed cause the UV data generation was fixed (previously it was different on win and osx making cross platform development with beast impossible basicaly). So reimporting should only be needed if the UV2 generation gets updated again for some reason.
did you check if the objects that get but shouldn’t get lightmap have their UV2 generated as per import settings?
Yes, actually it’s part of my editor script for import options. All my meshes get UV2 generated. And I did re-import every-single-mesh as I said up there.
The problem seem to reside between my hiearchy prefabs and my project prefabs. Even though they are the same in every properties they are somehow different in their UV’s. Doing revert fixes the problem but it’s NOT a solution as I have prefabs in my hiearchy that don’t share the same settings.
I really wouldn’t had expected 3.4 to break my project so badly… I’m working on a work-around right now but why it did happen is a mystery for me. I sent a bug report to Unity yesterday, havn’t got any news yet.
I would never update the engine mid project, no matter what project. Its to expect that things are going to be lost or break (regression or phantom bugs) …
also, since unity 3.1 the prefab system was under ongoing changes, thats why changing a meshes import setting for mesh collider and animation is no longer applied to prefabs using that mesh for example, so that side can actually impact it easily as stuff just is no longer the same as before.
The reason I asked about UV2 is that it potentially missconcludes what the object is meant to have in there or not. but if you reported a bug then thats fine.
That you don’t get a mail back within a day is normal. You will be contacted when its assigned to a Q&A Staff and if he needs input from your side on the matter, otherwise the next mail you will get is when its status changes
Thank you dreamora for taking the time to answer. About not updating the engine… I agree in principle but unfortunately, we are not doing a per-release project. It’s a constant work-in-progress spanning years with regular updates. If I wouldn’t had upgraded the engine I would had been stuck with lack of static batching and no beast in 2.6.4 or beast memory allocation problems in 3.0 or gc cpu spikes in 3.2. Upgrading normally isn’t that problematic…
I said I was working to find a workaround for it, it didn’t work. And scratch what I said about reverting the prefab… it works… sometimes only.
Oh well…
Hurray!
Well, I don’t know WHY but all my renderers in my scene had their lightmapIndex lightmapTilingOffset broken. I’m guessing it’s because in the re-import of asset files → update prefab asset files → update of corresponding go’s pipeline doesn’t update values of mesh renderers like you said dreamora.
Now, by broken I mean that default values when the lightmap is cleared were wrong thus showing lighmaps on (previously-static) objects and so on.
I just created a simple editor script that reseted those values to an index of -1 and tilingOffset of (1.0, 1.0, 0.0, 0.0) for all renderers.
Works like a charm without having to go through 7534 objects manually and re-create the prefab.(actually counted the lenght of the selection just to see what I saved myself from…).
I’m still hoping that Unity implements a check for this so that dynamic objects should NEVER have lightmaps assigned to whatever their index is after a bake, especialy after a bake-selected (coded changes should be fine if someone wants to play with it… but after a bake I don’t see the point). But I can see that it might be just a dumb-proof solution to a stupid obvious problem like I had. Oh well, so much time “wasted” learning from my lack of knowledge.
do you potentially have instances of that prefab in the scene as static objects somewhere which were indeed lightmapped?
Cause with the UV2 pregenerated, I wouldn’t be too surprised if it just went by “oh thats the same mesh, same UV, lets apply it the same way” or something alike that line. I know if you tell it to generate the UV2 it will not do that, but I’m also not sure if the UV2 is generated on import or at the beginning of beast bake in which case it could just spare the lightmap uv channel on objects not being lightmapped.
Anyway I’m glad you were able to find the culprit and fix it 
And I know the problems of longer term / ongoing projects, we upgraded from 2.6.1 to 3.x, that was more than just “2 things not working” 
But it all went well in the end, just took its time to port
I’m fairly certain the UV2 mapping is generated on import, i’ve found doing the UV2 externally is a little more controllable
Dreamora: I had multiple and single instances of the broken prefabs; all my content is prefabed (in case we need it and for more control) so in theory all my content was broken. The UV2 is indeed generated on import.
The sky is cloudy again: I’m using AS for team effort and hah… the fix doesn’t work when I commit the scene! My modelers get the scene and lightmaps but it’s all broken for them. They apply the fix, bake (all is fine)… send it to me and I get a broken scene.
Simply put… I’m going to delete all local content on ALL work stations and re-import it from the latest revision to re-create my metadata. If that doesn’t work I’m reverting to 3.3 and gonna wait for a magical fix in the future. 8.4gb of import… gotta love losing hundreeds of $ of salary for a version update.
Can anyone try this for me?
( is what I’m seeing with any project, test, import I have on 3 different machines with 3.4)
- Create new scene
- Add different assets / objects and a light with soft shadows
- Set everything to static
- Bake all with no special settings in single lightmap around 20 texels or so (just so it bakes fast)
- (everything looks normal… no problem)
- Select one of the static objects and press “Bake Selected”
- (object bakes normaly but the rest of the scene gets asigned parts of it’s lightmap… not that important as bake selected is only for testing)
- Select any of the static objects and remove the static check, bake all
- (dynamic object get assigned part of the scene lightmaps… big problem here, cannot have non-static objects in the scene…)
Update:
From the 3.4 Changelog; “Clearing lightmaps properly resets lightmap tiling/offset on objects, making them batchable again.”
- Not working at all for me. Was actualy working in 3.3 but now it’s not working anymore. Will have to clear lightmaps tiling/offset manualy with script each time I bake.
Oh well.
This is not working for me either. Very nasty bug. Should unchecking “static” checkbox prevent from lightmapping dynamic objects?
Thank god I’m not crazy!
Like I wrote before, I don’t think there are checks in place for an object marked as Dynamic to get lightmaps if it’s lightmap index + tiling + offset were set previously by a bake.
The way I’m getting around this problem right now is that I bake my lightmaps not by the lightmap window but by an editor script that just resets all object’s tiling/offset/lighmtap index before each bake, bake seletect or when I press clear. It’s working alright… but because my project is a team effort, my 3d developers can sometime corrupt those settings when commiting to the Asset Server. This becomes especialy nasty when we have scene A load scene B load scene C inside each other… one forgotten scene (that didn’t get it’s object reseted) can corrupt all others. (probably by having the wrong lightmap index of an inexistant lightmap… somehow the checks don’t work as well as in 3.3 for that)
Anyway, if you want to know more don’t hesitate to ask.
Just to say that I get the same issue, though oddly if I drop the res of the lightmaps down it works but that is not ideal. Hoping for fix in 3.5.
ensure to report it with an exmpale and posting a reference to this thread so it can be approached by UT for 3.5
I have the same issue here; Most of my prefab dynamic objects get a strange lightmap, even the ones I add after the bake!. note that the ambient color in the render settings is pitch black but the dynamic prefabs are still lit by some form of color or distorted lightmap, and they dont have an assigned lightmap in the atlas!!
I will report this issue which I find major and dont think it could wait till 3.5. I hope Unity do a 3.4a and fix both this and the random crash issue.
Hmm nevermind works perfectly now it seems.
I’m getting this problem myself and it seems to me that they’re only getting assigned to dynamic objects that were previously baked.
Help, I’m using 3.4.2 and I want to “undo” or clear lightmapping from my scene but clearing it just left all my static objects and terrain BLACK. I have no clue how to get their normal textures to display now. Looks like lightmapping permanently screwed my scene. What can I do? I tried reimporting individual meshes from inspector and turned off “Generate Lightmap UVs” but that didn’t help. Any ideas? This is a madding waste of time. I’m finding a lot of Unity still feels half-baked after so many years. Thanks in advance!
