UDK Lightmass Lightmap affected by vertex normals?
polycounter lvl 11
Hi, Polycount. :poly121:
I've got the following problem with Lightmass and Lightmaps:
As you can see, there is a nasty black gradient in the 2 corners of the fusebox. The problem presents itself when the light is not directly in front of the asset. The more severe the angle - the worse it gets. This gradient always appears on the side, opposite to the position of the light.
The UVs for the lightmap are below:
The faces with the problem are separated for the sake of testing and are completely flat. There is enough padding around the shell, so it can not be bleeding from other UV shells. The lightmap resolution is 256 (just for testing). The UVs have no overlaps. The triangulation is correct (the same as in the app, used to create and normal-map the asset). At first I thought that it could be some bleeding from the gutters between shells (which doesn't make much sense, since the edges in the shell in question are all horizontal or vertical in the UV when non-triangulated, and the problematic gradient is skewed). But upping the resolution of the lightmap did not help. The gradient only became smoother - so it can't be it either. The vertical and horizontal lines of the separated shells are not perfectly alligned to 256x256 grid, but if that was causing the issue, then upping the resolution also should have helped.
Here is the wireframe of the asset and and a shaded shot so that you could see my smoothing groups:
As you can see, there are the same sort of gradients on the same faces in the Smoothing Groups. Since there were no substancial details on those faces I saw no reason to add any support loops for normalmap projection (to avoid skewed detail). And the gradients themselves did not look too extreme to me. When non-lightmapped the asset looks clean (in UDK Asset Browser or Cryengine), apart from the minor, expected and negligible distortion of the specular on those same faces.
So, my conclusion s that Lightmass is actually vertex-normal dependant. Or am I wrong? If it really is so, then does it mean that the only means to solve the issue is to add additional support loops or assign the problematic flat faces into a separate smoothing group (which would lead to unfortunate need to separate the UVs and give additional padding to avoid normalmap black seams)? Adding additional support loops or bevels just for the sake of lightmaps also doesn't seem like an optimal solution. I do understand that vertex count is not that much of an issue as before, but adding support loops or bevels everywhere, where there is any kind of shading gradient, seems wrong.
Right now a separate smoothing group or loop\bevel can help my mesh, but I would need to either redo UVs, reproject the normal, AO and other maps and probably even retexture or reallign the diffuse\specular. I've somehow done a stupid mistake and lost my Edit Poly in the modifier stack in 3ds Max, in which I exploded the mesh before normalmapping in xnormal. So perfectly realligning the low-poly to the high-poly after adding bevels or support loops could be very difficult and lead to retexture or in case of separate smoothing group I would have to reallign\redo everything in the textures, since I will have to change the UVs.
UDN doesn't give much explanation on the issue. It only explains unwrap, padding, bleeding etc. I've searched everywhere for 3 days now and while there were people with similar issues, there was no clear explanation anywhere. Or am I looking in the wrong place?:) Out of despair I tried to test everything, even those things that did not make sense: All the possible settings in Lightmass (world and per-object). Tried to change Indirect Normal Influence Boost. Tried enabling and disabling Use Two Sided Lighting on the mesh - nothing helped.
It's not just about this mesh. I would love to understand how vertex normals and lightmaps interact.
I've got the following problem with Lightmass and Lightmaps:
As you can see, there is a nasty black gradient in the 2 corners of the fusebox. The problem presents itself when the light is not directly in front of the asset. The more severe the angle - the worse it gets. This gradient always appears on the side, opposite to the position of the light.
The UVs for the lightmap are below:
The faces with the problem are separated for the sake of testing and are completely flat. There is enough padding around the shell, so it can not be bleeding from other UV shells. The lightmap resolution is 256 (just for testing). The UVs have no overlaps. The triangulation is correct (the same as in the app, used to create and normal-map the asset). At first I thought that it could be some bleeding from the gutters between shells (which doesn't make much sense, since the edges in the shell in question are all horizontal or vertical in the UV when non-triangulated, and the problematic gradient is skewed). But upping the resolution of the lightmap did not help. The gradient only became smoother - so it can't be it either. The vertical and horizontal lines of the separated shells are not perfectly alligned to 256x256 grid, but if that was causing the issue, then upping the resolution also should have helped.
Here is the wireframe of the asset and and a shaded shot so that you could see my smoothing groups:
As you can see, there are the same sort of gradients on the same faces in the Smoothing Groups. Since there were no substancial details on those faces I saw no reason to add any support loops for normalmap projection (to avoid skewed detail). And the gradients themselves did not look too extreme to me. When non-lightmapped the asset looks clean (in UDK Asset Browser or Cryengine), apart from the minor, expected and negligible distortion of the specular on those same faces.
So, my conclusion s that Lightmass is actually vertex-normal dependant. Or am I wrong? If it really is so, then does it mean that the only means to solve the issue is to add additional support loops or assign the problematic flat faces into a separate smoothing group (which would lead to unfortunate need to separate the UVs and give additional padding to avoid normalmap black seams)? Adding additional support loops or bevels just for the sake of lightmaps also doesn't seem like an optimal solution. I do understand that vertex count is not that much of an issue as before, but adding support loops or bevels everywhere, where there is any kind of shading gradient, seems wrong.
Right now a separate smoothing group or loop\bevel can help my mesh, but I would need to either redo UVs, reproject the normal, AO and other maps and probably even retexture or reallign the diffuse\specular. I've somehow done a stupid mistake and lost my Edit Poly in the modifier stack in 3ds Max, in which I exploded the mesh before normalmapping in xnormal. So perfectly realligning the low-poly to the high-poly after adding bevels or support loops could be very difficult and lead to retexture or in case of separate smoothing group I would have to reallign\redo everything in the textures, since I will have to change the UVs.
UDN doesn't give much explanation on the issue. It only explains unwrap, padding, bleeding etc. I've searched everywhere for 3 days now and while there were people with similar issues, there was no clear explanation anywhere. Or am I looking in the wrong place?:) Out of despair I tried to test everything, even those things that did not make sense: All the possible settings in Lightmass (world and per-object). Tried to change Indirect Normal Influence Boost. Tried enabling and disabling Use Two Sided Lighting on the mesh - nothing helped.
It's not just about this mesh. I would love to understand how vertex normals and lightmaps interact.
Replies
I thought it has been done by smoothing groups, but tweaking didn't fix the problem.
It's saved i FBX and exported to UDK ...in 3Ds max it looks great.
someone please help...I'm not able to find, where the problem is.
While Importing mesh, just try to check ,,IMPORT TANGENTS" - that could fix this problem