Yea the light bleeding kepted kicking us real hard too - We had make all of our UV's so the though was always they had just been packed far to tight, we packed them looser and looser but it would not fix it and it ended up with most of our UV space was just blank because there was so much space between islands.
Another big issue was bake times and no indication on how long was left before completion. You could wait an hour and a half for a higher quality setup then once its finished you get crazy black speckles or black patches (the patches was due to some faces not having a UV2 so unity just grabbed its UV1 and overlapped it across the lightmap)
But yea I think it might of taken our programmer a week or so to get our exporting tools up and running - it's quite a complex process under the hood with all the albedo projections and our UV packer which scales our islands to fit into one texture ( nothing quite like waiting 1 hour for a bake and its been pushed over into two lightmaps) and also shows you the pack before you bake...
But if you guys are having trouble I will say its been massively beneficial putting some time into it - really at its core its just chucking out an OBJ and an albedo which you can bake in anything, max, maya or modo and just chucking the bake back into unity.
We are modo fan boys and its got some great rendering features such as the "preview" window that gives you a decent representation of what your world looks like and just auto updates as you chuck lights around. You can do progressive texture baking too in 901 which ive not checked out much. One real big benefit though has been the modo render output options, you setup a tree of outputs, AO, illumination Direct, indirect etc... it bakes it all in one go. We are saving that out as 32 bit exr files and chucking them into photoshop for compiling. Gives you a hell a lot of control.
BTW - unity 5.3 (i think) came out last week at some point - there are a bunch of GI fixes in there so some of it could help you out.
Found another painful mess with the gi lightmap baker... we use a custom shader on our terrain, with four gray textures packed into one bitmap. The packed texture tends towards pink, unintentionally. We dont care, since we unpack them in the shader. But unity uses this (without the material!) to calculate the bounce colors, so we get pink bounces!
We had something similar with "Shadow" geometry. We have a lot of backs of buildings, roof tops that we want to remove from an optimization standpoint but keep in "editor only" for shadow casters. Out of habbit I've always created a "shadow" material which has always been set to a debug style colour, IE bright green. So yea half the level turned bright green.
Are you looking at spitting out your world and trying to bake outside of unity?
it is near the end it is the guy working on P.a.m.a.l.a. that mentions how you can redefine the bounce color. Also yeah the culling mask bug is biting me in the ass as well. I got a few areas where i use spotlights and area lights to cast light indoors a little more intensely than the moon is doing so which looks great indoors but i cant stop it from hitting surfaces outside which is a pain in the ass.
Hmm the only mention of bounce was when there was an audience question about creating flickering light. The Enlighten & Unity guys said you could have invisible emissive meshes in your scene which can add to the indirect illumination. Not really a customizable bounce color, at least not that I heard anywhere. Did you hear something different? I can't find the checkbox for "make this object visible only for lighting". Maybe they simply meant disable the Mesh Renderer?
Hmm the only mention of bounce was when there was an audience question about creating flickering light. The Enlighten & Unity guys said you could have invisible emissive meshes in your scene which can add to the indirect illumination. Not really a customizable bounce color, at least not that I heard anywhere. Did you hear something different? I can't find the checkbox for "make this object visible only for lighting". Maybe they simply meant disable the Mesh Renderer?
Great video though, thanks for posting this!
I managed to get this to work by using the standard material and setting it to be translucent:
My work is possibly migrating to Unity 5 soon, and I just started messing with light maps in 5. I noticed that the padding setting does not seem to change the spacing of the UV islands, just the entire objects themselves. Has anyone else come across this issue? I did a simple test with a couple a cubes and a plane imported from 3ds Max with a low resolution just to see if this was the case.
@neilberard That's expected behavior. Lightmapped UV's are atlased to a lightmap texture. Only UV offset and scale are used for atlasing. (Tiling XY and Offset XY). I'm pretty sure Unity 4 works the same way.
My advice is to hold off upgrading as long as possible. I miss the old Unity 4 days.
Found another painful mess with the gi lightmap baker... we use a custom shader on our terrain, with four gray textures packed into one bitmap. The packed texture tends towards pink, unintentionally. We dont care, since we unpack them in the shader. But unity uses this (without the material!) to calculate the bounce colors, so we get pink bounces!
For custom shaders to work well with the lightmap baker you can write a custom meta pass in your shader that feeds the right information to the lightmapper, otherwise it just uses the diffuse/first texture. http://docs.unity3d.com/Manual/MetaPass.html Looking at the shader source files you can get an idea of how this works
Pass { Name "META" Tags { "LightMode"="Meta" }
Cull Off .....
If you create your own lightmap UVs then don't check the box or you will be generating new UVs for the model. The UVs need to be in the second UV channel. You mentioned "UV1" as long as UV0 is the first channel you are good.
Not sure the uv naming makes to much difference? We call our channels map1 + map2.
It depends if you trust unity to auto generate your lightmapping UV's, using the auto feature is quite quick in the early states of production but in the long run you do get better results from a manual uv pass.
Replies
Another big issue was bake times and no indication on how long was left before completion. You could wait an hour and a half for a higher quality setup then once its finished you get crazy black speckles or black patches (the patches was due to some faces not having a UV2 so unity just grabbed its UV1 and overlapped it across the lightmap)
But yea I think it might of taken our programmer a week or so to get our exporting tools up and running - it's quite a complex process under the hood with all the albedo projections and our UV packer which scales our islands to fit into one texture ( nothing quite like waiting 1 hour for a bake and its been pushed over into two lightmaps) and also shows you the pack before you bake...
But if you guys are having trouble I will say its been massively beneficial putting some time into it - really at its core its just chucking out an OBJ and an albedo which you can bake in anything, max, maya or modo and just chucking the bake back into unity.
We are modo fan boys and its got some great rendering features such as the "preview" window that gives you a decent representation of what your world looks like and just auto updates as you chuck lights around. You can do progressive texture baking too in 901 which ive not checked out much. One real big benefit though has been the modo render output options, you setup a tree of outputs, AO, illumination Direct, indirect etc... it bakes it all in one go. We are saving that out as 32 bit exr files and chucking them into photoshop for compiling. Gives you a hell a lot of control.
BTW - unity 5.3 (i think) came out last week at some point - there are a bunch of GI fixes in there so some of it could help you out.
Found another painful mess with the gi lightmap baker... we use a custom shader on our terrain, with four gray textures packed into one bitmap. The packed texture tends towards pink, unintentionally. We dont care, since we unpack them in the shader. But unity uses this (without the material!) to calculate the bounce colors, so we get pink bounces!
We had something similar with "Shadow" geometry. We have a lot of backs of buildings, roof tops that we want to remove from an optimization standpoint but keep in "editor only" for shadow casters. Out of habbit I've always created a "shadow" material which has always been set to a debug style colour, IE bright green. So yea half the level turned bright green.
Are you looking at spitting out your world and trying to bake outside of unity?
Did you know you can set your lights to cast 2-sided shadows? Works great with our heavily-backface culled meshes.
On a related note, discovered today that cullingmasks are broken for lightmap lights (http://issuetracker.unity3d.com/issues/cullingmask-lightmapping-ignores-lights-culling-mask). And they've postponed any fixes.
Great video though, thanks for posting this!
Somehow my bounce problem went away, maybe one of the recent Unity updates?
That's expected behavior. Lightmapped UV's are atlased to a lightmap texture. Only UV offset and scale are used for atlasing. (Tiling XY and Offset XY).
I'm pretty sure Unity 4 works the same way.
My advice is to hold off upgrading as long as possible. I miss the old Unity 4 days.
http://docs.unity3d.com/Manual/MetaPass.html
Looking at the shader source files you can get an idea of how this works
The UVs need to be in the second UV channel. You mentioned "UV1" as long as UV0 is the first channel you are good.
It depends if you trust unity to auto generate your lightmapping UV's, using the auto feature is quite quick in the early states of production but in the long run you do get better results from a manual uv pass.