Baked normal map (seams problems)

Hi friends, I baked asteroid in blender, and put it in JMP. But normal map shows incorrect seams. I also tried that model in XNA Engine and i fixed it with inverted red channel of normal map.

I tried to fix it in JMP with many ways, but i failed. I tried ogre mesh, blender mesh, invert red channel, invert green channel, invert red and green, change red and green, use JMP material… Nothing helped… Actually this is a vital thing for artists (zbrush, blunder, 3dcoat, mudbox bakingggg).


Normal map -

Blender glsl -

JMP scene viewer -


Asteroid Model - (3,7Mb)

PS: I did it in blender 2.5, I also have put normal map with inverted Red channel, as it looks right in 3DMAX and XNA. J3o is also there. - ogre export for blender 2.5 (just in case).

The blender 2.5 exporter is not officially supported yet, nobody was testing it from our side. Of course we will do that at some point, probably when its clear which of the exporters becomes the “official” one.

Did you generate the tangents and binormal (when making the J3o file or in code by TangentBinormalGenerator.generate(mesh)).?

You don’t need to invert channels for JME3.

If this does not work, maybe there is an issue in the blender 2.5 exporter and uv coords.

Try to open the model in blender 2.49 (there will be no loss as long as there are no animations) and export it with the official exporter.

I tried:

blender 2.5, blender 2.49, Ogre mesh.xml, generate binarmals. Nothing helps… this model looks with seams. The problem is not in in blender version. Blender plugin works cool!!! - blender 2.49 and ogre model.

Any suggestions?

Blender 2.49 screens -

I see nobody is interested in this problem. I suppose the problem is in Common.MatDefs.Light shader. I think there should be some kind feature to correct tangent normal map seams. I ask you for help! there should be a way to solve the problem. Please, download my model and have a look at this inside of jmonkeyengine. – blender 2.49 and ogre model.

As i said before: in XNA engine the problem was solved with red channel inverting (as blender bakes normal map with inverted red channel unlike 3dmax does). So right normal map will be asteroid_01_normals_inverted_red.png (in my folder).

Actually i downloaded your model 2 days ago, and spent at least 30 minutes on it, trying to figure out the issue.

It’s not that we are not interested in your issue. But as you can guess, we have a lot of things to do and we can’t spend too much time on individual issues.

Always remember we are doing this on our spare time…

The problem with your model is that it’s very low on polygons and that UV seams are not ideally placed.

The model looks good with Blender, but if you look closer you can see the seams too.

It seems Blender only apply normals from the map and not normals from the mesh…

There is maybe something to do in the lighting material regarding normals management.

I’ll try to spare some more time on this issue, but i can’t promise you anything.

Oh, sorry I didn’t know. Thank you very much for your time. I appreciate it.

I have just downloaded unity free version for testing that model. The asteroid looks pretty good with inverted red and green channels (not as in XNA). So, there are about 2 engines where I can see baked model pretty good. I DESIRE to see it in JMONKEYENGINE. It would be really cool. Thank you devs beforehand!!!

Unity screenshot - - texture with inverted red and green channels

Nehon, this is specially for you!!! I did a character model tomorrow evening to test it in Jmonkey Engine. Just for case if you don’t like asteroids :slight_smile: . I hope you find it useful. I included a sculpt model, blend2.5 model, fbx model, ogre model, jmonkey model, jmonkey light material, different normal maps (with inverted channels). - model archive

model -

seams -

sculpt -

engine comparison -

I hope it will be helpful for solving such a problem. Let’s make Jmonkey nextgen engine!!!

Cool!! i’ll look at it

this guys is frightening… :frowning:

There is really an issue with the way we handle normal mapping…

Ok…i looked a bit more into this issue…I think there might be an issue on the way we compute tangents and binormals.

If you look closer at your model in JME3, not only the seams are visible, but normals are flipped in the back of the model.

I looked at the HoverTtank model and it’s less noticeable, but there is the same issue (visible on the reactor on the back of the tank)

I’ll keep searching to find a solution.

Thank you for your work!!! hover tank has seams too, but seams are hidden inside of mesh. I can bake any model or the same character in Xnormal (special program for baking from hi-poly to low-poly) and normal map looks the same way. Possibly, the issue could be solved in glsl shader (some parameters). Or the way how Jmonkey works with normals should be reviewed. Just my humble opinion.

I would like to make next gen invironment in Jmonkey, but I’m not able because of that issue.

Just for testing how normals work… download free version of Unity and test the character model. Unity uses fbx.

If you need any other model or any additional help, just ask me.

Also, there is RenderMonkey program for glsl shaders making. Possibly it could be helpful.

I forgot to say that there are 4 normal maps with different channel inversion.





did you test them all? normal_inv_red.png looks correctly, but seams are seen too.

In Unity normal_inv_red_and_green.png looks correctly and seams are not seen.

In XNA engine normal_inv_red.png looks correctly and seams are not seen.

In Blender normal.png looks correctly and seams are not seen.

Every engine has its own approach for normals. Normally, normal_inv_red.png is the best way as 3dmax bakes in such a way.

Yhea the seams are hidden on the tank model, I did it on purpose, because I once read somewhere that hiding seams was a common rule of thumbs when modeling for video games.

But still…normals are inverted on some parts of the rendered mesh and that’s not normal (huh)…

But in case of character modeling it’s not that easy to hide seams especially in the shoulder/neck region, and Blender and Unity seems to handle this no problem. So there should be a way

Honestly I looked in the shader and normal are handled in a pretty standard way, can’t see any error. that’s why i think the issue might be on the tangent and bi-normal side.

I use RenderMonkey from time to time…but their GLSL support completely sucks and sometimes that’s a pain to work with it…

Btw Unity and XNA are commercial engines, and i’m sure that they have better renders than we do, but it’s not that easy to keep up their pace :stuck_out_tongue:

I’ll keep you informed

Thank you for your hard work! keep us (community) informed. I’ll ask about that problem at forum (there are many developers). Possibly, they can assist.

I did this thread at I hope someone will reply.

Another decent app for shaders is FX Composer. I haven’t really had the chance to use it yet, but read it was good for shader development.

mhhh…this sound familiar?

The issue might definitely be with tangents bi-normal calculation

to Lwsquad: FX Composer does not support glsl as far as i know.

to Nehon: Sounds familiar, but the issue explained at that link was with mirrored uv map. It means that one half of a model was mirrored to another.

Jmonkey works correctly with morrored uv models. I think the problem could be in tangents and bi-normal either. But where? - mirrored result in Jmonkey. - mirrored and not mirrored models comparison. - mirrored model (blend.2.5 file)