UDK normal map compression issue (or I'm really bad at normal mapping)
null
Hello guys,
I'm facing an issue with normal maps inside UDK, you can see an example of what's happening just below:
and this is the actual texture bake:
Besides waviness and bad trace problems which I'll fix with different cage size and photoshop, what I cannot figure is why UDK renders such a bad result.
The normal itself was baked in Maya. The model goes around 2198 tris, and it's a repeated element in my composition, so I think it's pretty heavy already, polycount wise.
Among things I tried already are:
- Changing LOD group inside UDK, even setting it to UI did not help
- Using TC_NormalmapUncompressed didn't help, i think because of the lack of blue channel and my unability to rebuild it in the shader.
- Hard edges around UV islands and uv splits on SOME hard corners
- Baking with Xnormal couldn't remove the artifacts
The problem seems to be absent when I reimport the map in UDK (from Texture Properties), but shows up just after the package is saved.
I'm pointing at severe gradient compression performed by the DXT1 algorythm, but what I'm asking is: how do people render this kind of smooth, techy surfaces?
Other than baking a full hi-poly object on a lower one the only way I can figure out is to model all the bevels in geometry and just add details such as cuts, trims, holes and bolts via normal map, drawn in photoshop and NV filtered, but in this case it would increase my (already high) polycount too much.
If anyone can point me the right in the right direction I'll be very glad
Thank you.
I'm facing an issue with normal maps inside UDK, you can see an example of what's happening just below:
and this is the actual texture bake:
Besides waviness and bad trace problems which I'll fix with different cage size and photoshop, what I cannot figure is why UDK renders such a bad result.
The normal itself was baked in Maya. The model goes around 2198 tris, and it's a repeated element in my composition, so I think it's pretty heavy already, polycount wise.
Among things I tried already are:
- Changing LOD group inside UDK, even setting it to UI did not help
- Using TC_NormalmapUncompressed didn't help, i think because of the lack of blue channel and my unability to rebuild it in the shader.
- Hard edges around UV islands and uv splits on SOME hard corners
- Baking with Xnormal couldn't remove the artifacts
The problem seems to be absent when I reimport the map in UDK (from Texture Properties), but shows up just after the package is saved.
I'm pointing at severe gradient compression performed by the DXT1 algorythm, but what I'm asking is: how do people render this kind of smooth, techy surfaces?
Other than baking a full hi-poly object on a lower one the only way I can figure out is to model all the bevels in geometry and just add details such as cuts, trims, holes and bolts via normal map, drawn in photoshop and NV filtered, but in this case it would increase my (already high) polycount too much.
If anyone can point me the right in the right direction I'll be very glad
Thank you.
Replies
Source: http://udn.epicgames.com/Three/NormalMapFormats.html#TC_NormalmapUncompressed / V8U8
What's your texture resolution? You might just need to increase it.
I was actually going to take a screenshot of the issues I believed TC_NormalmapUncompressed would cause on my model and... it actually worked as intended, beside the resizing of the texture (as the original 512 became a 256).
But still the problem stands in the quality I can get using the uncompressed format. this object should sit on a bigger texture sheet with other objects so the 1/4 resizing performed by UDK will greatly affect my normal map details.
this is the result with a 1024
will result in a normal map with less extreme gradients, and something that will compress better.
I agree though, compress artifacts will always be there, it's a by product from things like generating mip-maps and LOD's. Just some food for though, the blue channel tends to be the most artefact yielding, there is a DeriveZ function that can generate from the R and G channels, which may in turn reduce compression. Some more food for thought, the green channel is typically the least to have artefacts, Epic has stated this before and is stated on their site when browsing the documentation about textures.
Alas, having more UV splits becomes ideal. Normal maps are the combined result of the lo poly and high poly. This means smoothing groups for the low are taken into calculating and having more seams (defining edges moreso) helps to reduce the amount of color and therefore reduces the amount of artefacts to appear during compression (majority of the normal map would be considered blue-ish by the compression algorithm).
Also, most of the change of a constant 3 is actually affecting the R and G channels. Typically, I set it to 1.5, 1.5, 1 - which boosts the R and G, from there I tend to tweak as it's a better starting point.
The following images are the results I've obtained baking a normal map from a large and curved object. As pointed out I added more hard edges where beveled corners are in the high poly:
and then I split and nudged the corresponing UV islands, to give the edges some padding to bleed on (which I believe is very unefficient in terms of vertex count, let aside the discontinuity it will create using photosourced textures)
and decided to bake inside Xnormal, just to see if the artifact wasn't bake dependant.
this is the map I've obtained
and I thought "ok, gradients are minimal, this should work..."
this is what Udk renders (just the the mesh inside a blank scene. two pointlights, a simple material with normal map, a constant color and a cubemap reflection, normal map imported as TC_Normalmap, WorldNormalmap as LOD Group)
so, where's the issue here?
Seeing as one place is generating troublesome errors, I would try another method if possible, Max, Blender, xNormal, and such. It might be a specific setting Maya has internally set, as there are many annoyances that have been set with aDesk products. Try xNormal if you can, it's usually fine in giving the correct errors, if any (it's also not aDesk software).
The output was a 1024x1024 png 24bit map (three channels, no alpha).
If the issue stands in the DXT1 compression, I seriously doubt that even a 16bit per channel texture would resolve the matter, since the compression itself would lower the bit depth of every channel and create optimized gradients, which i believe are the causes of this whole issue.
The thing still is that in marmoset or Maya the shading doesn't look stepped at all, so I keep blaming the UDK compression. The artifacts themselves disappear as soon as I set this texture as TC_NormalmapUncompressed when importing (and reimporting) in UDK.
Clearly I could try to remove even the slightest gradients in Photoshop, but that doesn't see a viable workflow, too time consuming, not versatile, I would probably follow the "model every major bevel" approach instead.
The thing is the map is perfectly fine inside maya viewport, and in Marmoset too.
maya and mamorset dont apply dxt compression, which would be why it looks nice in both of them.
It actually looks like this:
Which is fine for me (just a slight banding but not really an issue), what I don't like about uncompressed format is that it becomes blobby, it looses all its sharpness (beacause of how TC_NormalmapUncompressed works).
What I still can't grasp is: user Passerby adressed the blocking issue to EXTREME gradients in my first bake, what you pint out as the issue are the too shallow graients (which for what I know about compression algorithms is the best answer)
So should I go for extreme gradients or no gradients at all? I'm starting to miss the point on using normal mapping for smooth hard surfaces.....
better off getting rid of gradients on smooth surfaces as much as possible, i cant really say much more since i never had this problem to the same extent as you, ussualy just get very subtle artifacting, that people wotn even notice once i slap hte diffuse and spec on.