Just playing about with Unity 5 and attempting to recreate the workflow of my current project from Unity 4, but I've hit a snag - Is there any way to assign the Lightmap Index of a renderer in Unity 5? This was possible in Unity 4 once you'd ticked the 'Lock Atlas' option and set the lightmap array size manually, but in Unity 5 the Index property appears to be non-editable, and Lock Atlas / manual array size doesn't appear possible. What am I missing?
You can still do it but you have to do it via code now for some reason. Also keep in mind that the index numbering has changed. What was 255 is now 65535 (no lightmaps) and what was 254 is now 65534 (contributes to lightmap but doesn't receive one). The lock atlas feature has gone though unfortunately.
Try this. It's a hacky little script to set the tiling/offset values on a renderer and also plug in the lightmap textures manually. Attach it to any renderer in the scene.
Sadly, still having issues with this. The script / method @Jde used is fine if I have a pre-existing lightmap generated outside of Unity, but if I want to produce the lightmap in Unity, any Index/Array/Tiling values I alter simply get reverted when I try to build the lighting for my scene.
You can force specific objects into a specific lightmap, by assigning a Lightmap Parameters with Baked Tag set to the desired atlas id.
Thanks @KEngelstoft - that does work but it only partially solves the problem as the Tiling parameters are still being controlled by Unity / Enlighten, so when I assign multiple objects to the same Baked Tag, they end up scaled and arranged on the lightmap rather than all being treated as being a scale of 1. Even when I have a single object occupying a single lightmap it gets scaled to 0.98 and 0.97 mis-aligning it to my texture UV's. Any thoughts on this?
Baked Padding seems to default to 2 and can't be set any lower. All of the issues I'm having could be solved by allowing the user to lock the Baked Lightmap settings for a Renderer, or to skip the UV layout part of the baking process. Is there any way to do this? Or any chance this option could be added? I can imagine a multitude of use cases where having absolute control over the way lightmap UVing is handled would be crucial, especially as it was something done with the ticking of a box in Unity 4.
You can use the 'Preserve UVs' option in the object tab of the Lighting window to keep the UVs from your modelling package. Also, the import settings on the models will allow you to choose if you want to generate UVs.
I've already tried with and without Preserve UV's ticked, it produces the exact same results either way. Generating UV's on the import settings would entirely defeat the point of what I'm trying to achieve...
The preserve UVs is only applicable to the realtime GI lightmaps. This option disables the built in AutoUV feature which will attempt to join adjacent charts in order to get more compact lightmaps for realtime GI. I assume that you are talking about baked lightmaps here. I am a bit surprised that atlassing a single object will adjust the scaling and not leave it at 1. I am a bit worried about being able to disable the UV layout since for most users this would completely mess up the lightmaps. However, we will put a task on the Trello board to improve the script bindings for lightmapping such that this could be done from code better.
Thanks for replying @Jesper Mortensen I totally understand not wanting to provide potential pitfalls for users with options that most won't use, so a scripting solution seems perfectly reasonable - I can already set the scaling/offset options via script, so just being able to tell Unity to leave them alone would work a treat! Also thanks again to @KEngelstoft for taking the time to reply Edit On the point about scaling not hitting 1: Having checked the UV's on the object in question, there are a few points that come close to the edge, so I'd assume it may be because the UV layout for that object encroaches some enforced padding around the edge of the texture / UV chart and gets scaled down. Possibly the 2 texel thing mentioned earlier.
When a new atlas gets created (the current object didn't fit into the previous lightmap or the current lightmap is the first lightmap) then we pass in 0.0f padding. Could you submit your mesh and a simple scene where you see this so that we can check what's up? I agree that it makes sense to be able to "lock atlas" from scripting and we'll add that soon.
Awesome I've submitted a repro project for the scaling issue (Case 681499) - basically a default project with the single model in it (part of the terrain from this contest entry). With the default Baked Resolution (40) I get scaling in the 0.88 - 0.89 range, but even if I go upto something stupid like 10,000 the scaling never quite hits 1. First time uploading a project with a bug report, so let me know if I messed it up somehow!
There is no project attached. That said, someone from QA will probably poke you about that shortly and will help you out. Did you see the project mentioned in the list of files that were about to be submitted?
I added the project folder and assumed it would upload the whole thing, but guess that isn't how it works. I can try again with a package of the scene, or just throw the model up on here with the import / lightmap settings I'm using (apart from that its an entirely default project / scene).
I suspect user error Since the project is so small, I've just zipped it up and thrown it on my dropbox Here Hope that's ok!
This issue is something I have been struggling with for the past couple of days, our studio also frequently uses the lock and editable atlas attributes to manually define lightmap index values for geo in a scene. Our workflow in Unity 4 is as follows: Manually layout light map UVs For the environment in modeling package (usually atlased to fit on a single texture sheet) set the index values for all environment objects to 1, set tiling and scale to 1, lock the atlas and bake. In Unity 5 I have no access to the index values and therefore can't use our manually created UVs, Unity's auto UV layout works in a single scene, but the index values don't seem to be transferred to other scenes using the light map snapshot file. As far as I can tell we have lost the ability to use the same lightmap across multiple scenes because of these changes.
Hey guys, we met same lightmap problems in Unity5. In unity4. In Editor,we put all mesh in a scene, then back the lightmap, assign the light map index, and scaleoffset to each mesh renderer, and save to prefab. In the run time, we load all the lightmap textures into Lightmap setting and light map works. but In Unity 5, during the bake process, we store the light map index and scale offset value to the mesh renderer, In the run time , the renderer's light map index is -1, the scale offset is (1, 1, 0, 0). total wrong.. Any thing wrong with our process or unity 5 lightmap system?
^^ Same problem as above. That was our process, put all in a baking scene and saving prefabs.. now when you put those prefabs in another scene and you load the lightmap via Lightmap Snapshot, the Index is stuck a 65535 (1,1,0,0). What is the workaround to this?
This workflow is indeed not directly supported in 5.0. What will happen right now is Unity will look at the AABBs of UVs of each instance and atlas that for you. Currently it doesn't handle L-shapes nor U-shapes, but we'll use smarter atlasing at some point. You do have access to lightmap index and lightmap scale/offset via API. That said, currently you won't be able to use it for the workflow above, as there is no way for you to tell us not to run the automatic atlasing yet. Could you describe this workflow in more detail? Were you just copying game objects from one scene to another and assigning appropriate lightmaps into specific slots?
The reason why this doesn't work is that lightmap index and lightmap scale/offset is no longer serialized on the Renderer. This data always lives outside of the scene (either in the LightmapSnapshot.asset (soon to be renamed BTW) or is created based on the GICache). To keep using your workflow you'd need to write a simple script that will be able to take a bunch of prefabs, save out their lightmap index and lightmap scale/offset and then reapply that at runtime.
Hi Kuba, What you've just said is exactly the workaround for lightmapping prefabs in Unity 5 that I have implemented. Artists bake the lightmaps, put my Lightmap Controller on each of Mesh Renderers that use a lightmap, and I added a button to grab all the lightmap data and offset and store them in my component. Then those components pull all the lightmap data from prefabs being instantiated into one master list, then it assigns that list to the Scene's lightmap list, and the offset values from my component are applied to the Mesh Renderers. EDIT: As an additional note, for some platforms you may (as we did) need to set Lightmaps project setting to "Manual" instead of "Auto".
Hi Kuba, If I understand correctly, could this be the reason we're having a problem with our lightmaps shifting on a second computer after running an update on version control? Our lightmaps look correct on the computer where they were actually built, but we're getting large black blotches on geometry after the scene(along with lightmaps and snapshot) is committed and the update is downloaded on another computer. The lightmap index appears correct across computers, but if the lightmap scale/offsets are created based on the GI cache (which is not committed using version control) could that be causing our problem? Thanks! *Edit* After some more testing, we found that the Snapshot wasn't showing the right values for either the index or offsets. Manually copying the snapshot file from the first computer to the second (bypassing Version Control) seemed to make it work, but not reliably. We're also getting a lot of errors along the lines of: "Failed opening GI file: '52/527e0763f71b5d8bd1c383d3cc776f52.pps'. UnityEditor.DockArea:OnGUI()"
This is an interesting thread! I have also ran into similar problems with my game Lunar Flight which I'm currently rebuilding with Unity 5. My Terrains consist of [3x3] 2048 Height Fields @ 1mtr per pixel. In Unity 4 I had to bake each one individually and save out the lightmaps and rename them. Then I manually setup the Indexes and assigned each object its lightmap. An unwanted side effect of this method is that each Terrain does not influence the others and there are visible seams. I don't seem to be able to do this in Unity 5 or atleast I'm not aware of a way to assign the index manually. I am currently enabling/disabling each tile individually to bake them but I'm not aware of how I could assign the light map data to the correct Terrain. Given that Unity 5 has a 64bit editor would it now be practical given enough RAM to light all 9 tiles in one bake?
You can assign the index values using different Lightmap Parameters with Baked Tag property. You can also change the Scaling/Offset values via script, but they will be overwritten next time Unity bakes the lighting (so it's really only useful if ur trying to match externally baked lighting to objects inside Unity.)
Others interested in an example implementation please check out: http://forum.unity3d.com/threads/problems-with-instantiating-baked-prefabs.324514/#post-2177524
Hi Kuba, Are there any news about the lockatlas scripting fetaure ? Also note that http://docs.unity3d.com/ScriptReference/Lightmapping.Clear.html still refers to LightmapEditorSettings.lockAtlas which does not exists anymore if I'm not mistaking. I used the Unity 4.x lock atlas feature for archviz project variants presentation. With the lock atlas gone, I'm a bit lost.
Kuba, is there any update to this resolution? I also have the same issues when trying to apply externally baked lightmaps to my model. Can we lock atlas yet? When is it coming back? Thanks
Interesting Timing, just today I went back to unity 5's light baking system today to see if anything had been updated or fixed. Looks like the preserve UVs Option now works a little better (objects tab of the lighting window), however one caveat is that different objects will still show up on different maps and I haven't found the solution to this yet, one workaround is to merge all objects (even just temporarily) and then all of their Uvs will show up on one map together the way they were laid out in your modeling app.
Merge all objects temporarily in unity? Then seperate? How do we do that. Can I be blunt? This is to the unity devs. Guys, there are serious problems with the lightmapping tool, i constantly get black splotches, pixelation, dithering in lightmaps. Why can't you just let us use our own workflow which we have focused on and perfected instead of trying to be über clever and overhauling entire functionality in favor of new ones, which aren't time tested. We all need to import our own lightmaps, just let us do that! Stop chaining our solutions plleease!
Hi! Thanks for the heads up, I have updated the docs. Now you can use Baked tag in Lightmap Parameters to force objects into the same atlas. Also, with Multiscene baking you can group the objects into scenes that will get an atlas per scene.
Unity, or rather enlighten, arranges all my lightmaps in my scene into 2 large atlases. Funny thing is that there is plenty of space in one atlas to hold all the lightmaps, but still Enlighten creates 2 atlases. I can't find a way around it. The frustration I feel atm is monumental.
Perhaps you are assigning two different Lightmap Parameters to your objects? Lighting window -> Object -> Advanced Parameters
So how do you get the scaling/Offset value if the lightmap and UV are done external ? we have objects batched into one set of few lightmaps ( so mulitple object shares one lightmap ) . I don't see how we can get the scale/offset value anywhere.