Light Map misconceptions?
polycounter lvl 9
I'm seeing conflicting information so before I start creating my light maps I'd rather weed out the wrong information. I'll just go over what I think is correct and you can tell me what's wrong and what's right.
1) You need to figure out the light map res you want to use before you create the light map uv channel? Is there some reason behind this because that would mean you couldn't adjust the light map res without having to redo the uvs every time.
2) Light map uvs DO or DO NOT have to be snapped to the grid? If true then you have to adjust the uv grid. To do this you need to divide 1 by your light map res(1/256 = 0.00390625 grid spacing for instance). Again, this seems it could become frustrating if you need to adjust the light map res at any point after the fact. The 3D motive video doesn't bother snapping the uvs to the grid let alone even worrying about the light map size calculation. Then there's the World of Level Design videos that implore you to snap the uvs to the grid so you don't get light bleeding.
If you're required to snap to the grid how does this work with unplanar type unwraps? For example, these uvs aren't perfectly square/rectangular. This is what's making me question the grid thing.
This is what happens when I snap the shape to the grid though. The whole uv shape gets out of whack. So grid snapping can't be the answer for "organic" like uvs?
3) Wherever there's a plane change (ie shadow directional change) on your model is where the seam should be.
4) Uvs will need a 2-4 pixel padding, which is also where the checkerboard comes in handy. Again, still not sure if the grid snapping is needed cause that would provide the exact 2-4 padding instead of an estimation like in the 3d Motive video.
5) Uvs size MATTERS or DOESN'T MATTER? As in texal density is still something to plan for?
*Side question regarding AO maps and an issue I'm encountering. I baked AO maps for these separate modular wall pieces. However, this is causing some horrible lighting differences.
It's gotta be the AO right? Should I just not have the AO baked to them and let the light maps control the shadows?
I think I covered all my questions, but let me know if I'm on the right track!
1) You need to figure out the light map res you want to use before you create the light map uv channel? Is there some reason behind this because that would mean you couldn't adjust the light map res without having to redo the uvs every time.
2) Light map uvs DO or DO NOT have to be snapped to the grid? If true then you have to adjust the uv grid. To do this you need to divide 1 by your light map res(1/256 = 0.00390625 grid spacing for instance). Again, this seems it could become frustrating if you need to adjust the light map res at any point after the fact. The 3D motive video doesn't bother snapping the uvs to the grid let alone even worrying about the light map size calculation. Then there's the World of Level Design videos that implore you to snap the uvs to the grid so you don't get light bleeding.
If you're required to snap to the grid how does this work with unplanar type unwraps? For example, these uvs aren't perfectly square/rectangular. This is what's making me question the grid thing.
This is what happens when I snap the shape to the grid though. The whole uv shape gets out of whack. So grid snapping can't be the answer for "organic" like uvs?
3) Wherever there's a plane change (ie shadow directional change) on your model is where the seam should be.
4) Uvs will need a 2-4 pixel padding, which is also where the checkerboard comes in handy. Again, still not sure if the grid snapping is needed cause that would provide the exact 2-4 padding instead of an estimation like in the 3d Motive video.
5) Uvs size MATTERS or DOESN'T MATTER? As in texal density is still something to plan for?
*Side question regarding AO maps and an issue I'm encountering. I baked AO maps for these separate modular wall pieces. However, this is causing some horrible lighting differences.
It's gotta be the AO right? Should I just not have the AO baked to them and let the light maps control the shadows?
I think I covered all my questions, but let me know if I'm on the right track!
Replies
You should target a min or common lightmap res. Going to a higher with the same UVs should work fine. Going lower might work ok depending on the case. The idea is to optimize for the common case.
Not sure if lightmass does padding so it might be important on the uv islands to avoid black shadows bleeding in. If it does padding you really only need to worry about making room for the padding.
Inside the uv islands the smoother the surface the less important. The thing you are trying to avoid is having a texel wrap around a corner as that may cause light or shadows wraping around as well.
Yes anywhere you absolutely do not want a smooth transition in the lighting such as a hard edge etc should be a seam on the UV. You may want to break this rule in some cases to save UV space.
Again depends on if lightmass does padding. Hopefully someone else can weigh in on this.
Not sure what you are asking about here but the texel density defines how detailed the captured lighting can be. You may want to give complex parts of your mesh a higher density than big flat surfaces.
Normally you wouldn't put object level AO in your material. Stick to details that is only available in the textures just as cracks etc. The engine is doing a pretty good job providing AO based on the geometry using the light maps and post process AO so you will just end up adding more AO in some places than others.
The problem seen in your screenshot can be avoided with careful planing of the AO baking but it's generally just not worth it due to the reasons above.
Edit: The problem in the screenshot could also be a lightmap seem. If it persists after removing the AO you probably need to tweak the lightmap resolution and/or lightmass settings.
Ok I'll just bake with a high res light map and decrease from there. This is for my portfolio anyways.
I'm positive they require padding. Someone just needs to confirm if I can guestimate the padding distance in between each uv shell. I'm leaning towards yes, but I guess I'll find out when I make mine tomorrow.
Yeah, I was just wondering if having a larger uv shell yielded a better quality shadow than a smaller uv shell. Looks like the same rules apply as with texel density/baking normal maps. Not sure why I thought otherwise.
I've always just provided an AO for anything that required a baked normal map. Are you suggesting otherwise? Sorry, just not understanding what you mean here.
I removed the AO from both of these walls yet neither wall blended together. Hopefully making their light maps does the trick. Even though these are separate meshes the lighting should still be able to blend the two seamlessly no?
Thanks for the replies too!
I only am worried about how the giant tube and and the platform/poles it's sitting on are baking
I've baked with as high of a res as 512. Is this something in my settings? Is it my uvs? My shadows are blotchy and fugly. One mesh has packed uvs while the other has plenty of padding. Both result in bad shadows. HELP!
Check out this thread.
http://www.polycount.com/forum/showpost.php?p=2116903&postcount=3
Things are looking much improved. I redid the light maps for the test tube as I completely forgot I had overlapping uvs. Woops! I also needed to fix the texel density between uv shells. It wasn't horrible, but it wasn't great either. Then I bumped up the light map res to 512 and things turned out ok, but I was still getting the ugly compression. I learned about disabling the lightmass compression setting which helps some. Also, to bump up the static lighting level from the default 1 to something higher like 20. This is the game changer from what I can tell. When you do that you allow for smaller photons to hit the surfaces. The smaller the number the larger the photon, the uglier the shadow basically. To disable the light map compression you have to go to where you saved your UDK install, UDKGame/Config/UDKLightmass.ini and Engine/Config/BaseLightmass.ini.
Static lighting level = 1......compression
Adjusting just the static level lighting is definitely a marked improvement.
Static lighting level = 20......compression
Turning off just the compression while leaving the static lighting at 1 isn't much different than having compression enabled. The shadows are less blocky and smoother though.
Static lighting level = 1......no compression
The real difference comes in adjusting both settings.
Static lighting level = 20......no compression
The higher the light map res is also makes a difference. I hope this helps someone else that runs into the same issue as I did!