I can't bake normal maps properly. (Examples).

[louis]

I spent hours looking over different ways to bake normal maps from high poly to low poly meshes. I feel like an idiot.

Every time I try it, the closest I get is an ugly mess. This is what it looks like as an asset in UDK.



I've tried it in 3DSM, Maya, and xNormals and I get similar results each time.

Here is the high poly test I've been playing with.



And here is an average normal I get. (Only jpg for this example).




I've tried to have the low poly as just a plane with smooth normals that goes where the grout is between the bricks. I would have thought that worked based on what I've read. I've tried creating a low poly version of the entire wall to see if that worked any better, but I still got the same poor results.

Can anyone tell me what the hell I am doing wrong? Does the problem look familiar.

[WhiteHyena]

Hrmm.. it almost looks as though our normals are being inverted. I could be wrong but try just swapping the green layer around and see if it looks any better. For something like that wall, you should be able to use a single flat plane with a single smoothing group, doesn't need to be any more complicated than that really. Try flipping and let me know how it goes.

[RaPtOr_v9600]

when you import texture do you check normalmap compression ?

[XilenceX]

In XNormal set the normal map settings to Y+ that might fix the problem. Also try importing uncompressed normalmaps in the udk import settings. See if that helps the quality a bit.

[nabiul]

When you import, there is a setting that says TC_Default, it needs to be set to TC_Normalmap. You may also need to click the invert green channel option.

This is what it looks like with TC_Normalmap and inverted green channel option.

[louis]

Wow. That is crazy. The inverted channel worked. How did you know the channel was inverted, though? (It was set as TC_Normalmap in UDK, though).

Also, thanks!

[mAlkAv!An]

It's easy to spot. The bricks are pointing outwards so their shadow has to be at the bottom side.
The green channel of a normalmap describes shadowing of the surface with light coming from the bottom/top (red channel, right side). Watch your channels separately in photoshop/gimp and you'll see.

[louis]

I wasn't aware of that. (Obviously I'm new to this, well, at least haven't messed with any of it in years). Thanks guys! I don't know how long I searched and never ran into that answer once. Do you guys happen to know what causes it or why it would happen in my situation?

[Kelt'ar]

Try using a bump offset...youtube it.

[nabiul]

The normal map format isn't universal, each graphics engine handles it differently and the red and green channels can be whatever the programmers decided it to be. Only the blue channel is predictably the same in all cases. It's not that big of a deal since you can use an image editing program to easily invert the channels if they don't work right in whatever modelling program or engine you are using.

[Spoof]

You might have read this, but it's always worth posting: http://wiki.polycount.com/NormalMap

[louis]

You might have read this, but it's always worth posting: http://wiki.polycount.com/NormalMap

Yeah, I have it. Thanks all the same for responding, though.

[louis]

Just wanted to give an update that things are getting a bit better now. Still a lot of work I'd like to do with the mesh itself (not to mention texture and AO), but I'm trying to go slow enough to learn everything as I do it. Thanks again for everyone's help.

[jasonseabaugh]

Yeah, by default the 3D max interpretation of Normals is opposite of Unreal. If you look at the Normal Map texture options in Max there is a check box for "flipping the green" which will allow you to use the same texture in renders as you do exported in UDK. Alternately you can select "Flip Green" on texture import into UDK, but you can't change it after the fact without dropping the texture back in.

When you look at the channels you can tell where the light appears to be coming from. This has all been said, but the memory device I use is thus:

R = from the Right
G = from the Ground

This will of course, screw you up when you go to a software package that doesn't invert the green, so good luck staying sane.