Okay. Using the MeshDebugger class on my Blender MD5-exported model confirmed that the MD5 exporter I’m using is doing the same thing that Mark Middleton’s was: cloning vertices and giving them different vertex normals. (I suppose I could have checked the python script, but this was faster.) It also confirmed that his class Normals.as is fixing my MD5 model just the way it’s supposed to: average the normals of both cloned vertices and then apply that average to both of them. It almost cures the issue. There’s a visible difference, but the hard seams are still there. (Picture)

And as 80prozent and Richard Olsson suspected, MD5 does not preserve vertex normals: MD5 specification says so.

However, OBJ format does preserve vertex normals (OBJ specification), if you check that option in Blender, and using the MeshDebugger on an imported OBJ shows that Blender’s OBJ exporter does not clone vertices. (Picture) (FlashDevelop project complete with source, normal, and diffuse maps, .obj file, and .blend file.) Furthermore, checking for autoderivenormals on a Blender OBJ export (as you can see I have done with a trace) turns up a False boolean.

So my question is, why do the hard seams still show up on an imported .obj whose vertex normals are completely intact??

Incidentally, Blender and Away3D also appear to use different normal mapping conventions. To make the normal map not all screwed up and black, I had to use GIMP on my Blender-created normal map and invert the red and green channels. However, this is an independent issue. The hard seams were there before I inverted the color channels.

hi

there is definitv something wrong with your normalMap.
if you do not apply the normalMap, most of the seams are gone.

hope that helps

Could you be a little more descriptive? What is wrong with my normal map? I followed standard Blender normal map baking procedure to generate it. The only thing that’s not standard is, as I said, inverting red and green channels so that it doesn’t look like this in Away3D. And as I said, even before I inverted the red and green channels, the seams were there.

Ah, you did remind me though: the normal map I used in that .zip wasn’t the one I’m using with my actual project.  This is. And here’s an updated version of the project file which uses it. As you can see, it makes no difference.

i am not shure what is wrong with your normalMap.
i just tried your model without the normalMap and it looks a lot better.
i dont know much about blender, so i cant tell you how to generate a normal map in blender. to me it looks like the normalMap is created while the verts on the uv seams have different normals.

Yes, that’s exactly how it looks, but if that’s wrong, why does it not have hard seams in Blender?

For anyone else reading this and familiar with both Blender and Away3D, I’d love to get the Blender -> Away3D workflow in order. Has anyone successfully used a normal map generated by Blender in Away3D without getting hard seams?

in c4d i would not see a normalMap on my object inside the editor (only if i activate it in the editor-display-settings, which i dont). so in c4d i would see a smooth object in the editor, but when rendering, or sending to away3d i would see the seams, due to a invalite normalMap.

dont know if thats much help, but its the only solution i can think of. (in blender there are no seams, because the normalMap is not shown ?)

Alright. I’m trying to isolate variables here. I’ve used three other normal map generation programs to create normal maps for my models, and with ALL of them, I still get hard seams. So, either this isn’t a Blender thing, or I’m making the same mistake with four different programs. Results:
Blender
OpenRenderBump
XNormal
Nvidia Melody

I also tried applying the other three normal maps to my low-poly model in Blender. The ORB (unsurprising) and Melody (surprising) normal maps caused the same hard seams in Blender that Blender’s normal maps are causing me in Away3D. What does it mean!?

I need to contact the dev who’s in charge of the BasicNormalMapMethod.as class because I just don’t understand the math of normal maps deeply enough to continue here. If I get any further with this, I will post further discoveries / conclusions in this thread for future Google searchers.

Edit: I should also mention that for all of these tests, the .obj file was the same one I linked to before and autoderivenormals was still false.

For the sake of test, can you try using the airbrush tool to correct the map by hand in Photoshop, gymp or whatever image editor you have. Simply color one edge using the color of the opposite side. (Use another layer to do this, in order to be able to fine tune, yet have the original info intact). And look if it desapears.

Fabrice, there is actually a better way to do that than using a 2D image editor. Blender 2.5+‘s Smear tool in Texture Paint mode allows you to manually smear the edges of textures together in 3D. I’ve already tried it. Doing anything to a normal map by hand is just too inaccurate. I tried to be really careful / conservative about it, but it just messed up the normals. There were smudges of darkness and light around the hard seams, and the hard seams were mostly still there.

I see what you’re going for, but if you look at the normal map I generated with Nvidia Melody, you can see that its edges are already the way you wanted me to make them with Photoshop/GIMP. The colors at the edges match.

I have more information.

The most obvious hard seams, the ones on the legs and arms, have sharp angles. So I thought the hard seams issue might have to do with the geometry of my mesh. How would one avoid that issue, if that were the problem? In Max, you use smoothing groups. In Blender, you use Mark Sharp and the Edge Split modifier. Doing this (in Blender) helped slightly but did not solve the issue.

Then I tried creating a UV map that only had seams along the edges of clothing/skin/hair/etc. The rationale for this test was, if this had anything to do with sharp edges, those sharp edges would still have hard seams even if there was no UV map edge touching them.

The hard edges went away. (Picture) Obviously, UV maps can’t and shouldn’t be done this way, but the fact that the hard edges are showing at wide angles and not sharp angles demonstrates that this is a UV map / normal map problem, not a geometry one.

hi
after all you tested i still believe that somehow the normals of the seam-verticles are not merged correct. really cant think of any other reason.

i would try to get the model imported correctly without using any normal map.
once the uv-seams stop showing, you can go back to apply your normals.
e.g. try getting a uv-mapped sphere into away3d, without any visible uv-seams.

80prozent, thank you for sticking with me through this thread. I appreciate all of your suggestions.

However, with OBJ format, no merging can happen because there are no doubled/cloned verts (provided you choose “include normals” in the Blender export UI). They only show up in MD5. I’ve been working with OBJ a while now to rule out that possibility.

As you suggested, I imported a UV-mapped ball with no normal map. It has no hard seams. (Picture) Now, if I don’t choose “include normals” in Blender, it does get hard seams, and autoderivenormals is True—- but so long as I select that option, it’s seamless. Plus, as you mentioned before, my human model is seamless too, if you don’t use the normal map.

Here’s the ball with a normal map applied. (Picture)

And here’s the ball with a normal map applied, this one baked with Blender’s “Mark Sharp” on all the mesh’s UV edges, and Edge Split applied. (Picture)

so it must be that your normalMap calculation doesnt work correct.

have you tried other appz than blender (like importing your model into zbrush, hit subdivide several times, go back to first subdivisionLevel and calculate normalMap.)
thats how it works for me.
normalMaps produced in c4d work too.
i dont need to swap any channels of my normal-maps when producing them in c4d or zbrush.

I haven’t, no. I’ve come to the same conclusion, that whatever normal math Blender and those 3 other free tools I tried use must not be the same normal math that Away3D uses. This suggests that Max and Maya produce normal maps in a certain way and that there are other ways to do it. Being as there are AWD2 exporters for Max and Maya, I suspect that Away3D is geared toward that standard. So the next step is for me to try Max/Maya I think.