Unity lightmapper doesn't take object's normal map into account?!

Unity Engine
1

This is continuation of my older post (Baked GI issues when using tangent space low poly models - Unity Engine - Unity Discussions ) which has no answers yet.

As far as I can see. Unity ightmapper simply doesn’t take object’s normal map into account when baking. Only object’s geometry normals matter. That’s why smooth shaded meshes suffer from shading issues. I think I can fix shading with an additional support geometry. But I’m curious if anyone knows why Unity lightmapper don’t take normal maps into account and if this сan be fixed somehow?

2

I’ve been looking at some of the standard shader code and this does seem to be true. The meta pass is used for baking and it has a fairly simple calculation for albedo:

// Albedo for lightmapping should basically be diffuse color.
// But rough metals (black diffuse) still scatter quite a lot of light around, so
// we want to take some of that into account too.
half3 UnityLightmappingAlbedo (half3 diffuse, half3 specular, half oneMinusRoughness)
{
   half roughness = 1 - oneMinusRoughness;
   half3 res = diffuse;
   res += specular * roughness * roughness * 0.5;
   return res;
}

You could of course change this and create your own meta pass.

3

I don’t believe this would help in this case. The meta pass is used for getting the color of the surface for light bounces and light emission. Unfortunately I don’t believe it’s used for the actual light collection or determining lighting direction. None of the meta shader functions deal with light direction or surface normal, that’s all hidden away in shaders we don’t have access to.

@Twainxxi My suggestion would be to report this as a bug using the Report bug… interface in the editor (along with a simple test project). I don’t know of any good way to solve the problem in the short term.

4

Some additional thoughts on why this is the way it is. Normal mapping and light mapping are at odds most of the time, especially if the vertex normals are significantly different that the surface plane.

The main problem comes from the fact that light maps tend to be a much lower resolution than the normal map itself. Normal maps can also have large differences in direction that if used for the light map would cause unexpected splotches of bright or dark light. The “obvious” solution would be to use a lower mip level of the normal map when baking out the lighting, but this has it’s own issues as well.

The realtime ambient works by storing a full sphere’s worth of ambient lighting that the shader then looks into based on the surface normals. Baked lighting doesn’t do this and basically just gets one color when using non-directional mode.

With directional light maps or realtime GI it stores the average light color and the direction for the majority of the light, but it’s still limited to a single color. However I think directional light maps should be able to replicate a similar quality to the realtime GI on their own.

1 Like
5

@bgolus Thanks for your answer. This is sooo strange that I’ve never heard of this problem before. I will definitely pay more attention to my geometry normals from now.