I ran in another problem with normal mapping ie the lack of smothness on the low poly model spoils the effect of the normal map.
Ihe head I am working on is about 1200 polys and turning edges can only make it look smooth to a certain degree.There are always going to be artifacts showing as ther are n't enough polys to descibe a smooth surface
If I add more polys to make it smooth, then there seems no point having a normal map to describe that detail.
I was looking at poops tutorial and his low poly mesh seems very low indeed.
For example if that had to be facially animated, he would have to build a lot more poly detail in .
confused i am
Replies
only the lack of roundness of the silhouette spoils the illusion.
personally, i like the look of that mix between lo and hires.
What seems to be happening that the detail in the normal map seems to be added to the not very smooth surface of the low res mesh, like an overlay layer in pshop for example
I have all smoothing group set to 1 BTW.
So I wonder what is happening here. Surely the whole point of normal mapping is not to display the normals of the low res surface so it appears smoother
The silhouette issue doesn't bug me too much, but this does
It was not designed for facial animation.
Your head is 1200 tris all by itself! That should be MORE than enough for whatever your doing I'd think...
You arent generating your normal from a 1200 poly model or something are you? Im confused.
I hope your talking about silouette.
but when the normal map is displayed on the low res head model( 1200 poly model ) it looks shit. (It has the green channel the right way around in case you were thinking it was that)
the detail of the normal map is showing up fine , but the underlying none smoothnes of the low res model is spoiling the effect
Hard to know what the issue is, if we can't see it ourselves.
Putting "ben cloward normal map" in Google brings up something pretty close to that, too
Big props to Ben for all this stuff, it's invaluable. I use the 3-lights specular version of the shader, it's ideal, and also doesn't downsize viewport textures to 512x512 like 3dsmax's default shaders.
The normal map output from say zbrush is very smooth looking .. which is what max should be doing.
Melody keeps on crashing, the ati normal mapper produces similar stuff to max.
There is a script coming out soon which enhances z brush normal map output. (comes out end of october).
They just released a displacemnt map script thingy also
what's great is granny's (radgametools) builtin baker. easily 10, 20 times faster than orb and noticeably faster than max. yet the output seems like the best of both worlds. it's not freeware though, granny licenses are like 10k and they don't distribute this tool separately.
it's a command line tool with integration into max and maya.
when i render the normal map in max, I can definitely see that the surface anomolies in the low poly mesh are getting baked in to the normal map output.
[/ QUOTE ]If this is happening, then no shader's going to fix it, IMHO you're gonna have to re-cast.
I see this with heightmaps here sometimes. My remedy is to temporarily stick a Meshsmooth/Turbosmooth modifier on the low-res, just during the baking. By increasing the number of ray-cast normals, I get smoother results in the bitmap. Just gotta be careful with the UVs, Meshsmooth tends to round those off as well.
Actually most of the problems were caused by our low poly meshes not being low poly enough. I more or less halved the poly count of the low poly head and it looks sweet now.
Its common sense really, but can't see the wood for trees sometimes.
Thanks for the suggestions guys.
It's becoming rather annoying =\
Now if you we're doing this in doom3 you wouldnt get these errors because it re-normalizes the mesh and renders them out to avoid these errors.
The engine im working with currently works exactly like max which is a shame. I havent really done any character work yet so this is all based on my experiences with props and such.
EQ, thanks for the input. It's a shame, but I'm glad to hear that others are having the same issues that I am.
Have any of you guys had good results from products like Kaldera or Melody? I tried messing around with Melody last night, and I couldn't get it to process the normal maps correctly.
Any input would be great, thanks
BTW, some Kaldera examples here...
http://forums.cgsociety.org/showthread.php?t=274096&page=6&pp=15
I am now z brushing my low poly mesh straight up to a really high z brush version, with no intermediate model.
The normal map looks much better this way.
From the Kaldera demo's I've messed with, this shading issue *appears* to be non-existant. I am however, contacting Diego right now, to see if I can use my own meshes with the demo version. If it does in fact resolve the issue, we're buying the plugin immediately.
Doesn't change the fact that something weird is happening with the ati normal mapper and the max version. the quality is not that great, but if you look poops normal map, because he used a really low poly model, there is more detail in the normal map as you would expect, as the normal map is made from the difference between the two meshes.
That was done in max and look nice.
Scooby, max's RTT does in fact generate some good results. For some reason though, it will sometimes output the funkified shading from the low polys, into the normal map.
So there is actually some bug-ness in the Max RTT utility.
On the other hand, it's really good at what it does. And you can batch-process stuff with some simple MAXScript.
I'm at my wit's end with this now. Eric is trying to help me as well, but there still seems to be a problem.
I viewed them in a suedo-D3 viewer, but it still had artifacts (albeit a little less noticable).
It seems that it's an issue with the actual generation of the normal maps, actually. It doesn't make since though, since I've seen meshes with more low poly shading issues, and they work perfectly fine.
This is something I can't seem to resolve unless I break the mesh up with smoothing groups. Doing that completely fubar's the look the model, though. The normal map has a harsh edge where it shouldn't, yadda yadda.
Any ideas on this would be most apprieciated.
Here's a test I did in Max7 and the Max8 trial today.
This mesh is 256 triangles, and has UV symmetry down the centre. As you can see, Max7's DX Display screws up the mirrored side, all the lighting is inverted. It was actually worse with the normal-map rendered from Max7, this normal-map has been rendered from Max8 and applied in Max7's viewport.
However I can't see any of the artifacts you're talking about on either of these (the low-poly models are pretty low compared to the high!), they appear completely smooth (even in Max7 it does, but only on the non-mirrored side, as you should just be able to see.
I'm using an ATI Radeon Mobility X700 for displaying these.
Then again, I haven't checked these out in any game engine, I'm just going by what I see in the Max viewport, so maybe that error wouldn't show up in something like Doom3 or Unreal Engine 3?
In doom3 you would use one single SG and i would imagine it to be the same in UE3 aswell.
How do you calculate normal maps for industrial stuff just applying 1 smoothing group to the whole mesh? Applying smoothing groups you get seams 'cause it breaks up all the faces.
I only have this problem with normal mapping, in max, orb, ati, melody, kaldera, and anything else.
Is this engine related more than because of the normal map generator?
-DDS
Thanks for the help/input, all
DDS, sounds like you answered your own question. You're right, don't use smoothing groups on the low-resolution mesh.
If your game engine massages the normals properly, you don't need to worry about shading problems on your low-res model.
But if it doesn't, then you can work around it somewhat, by adding a chamfer or bevel to acutely-angled areas of the low-res surface.
No matter what, always use a single smoothing group for the low-res model.
It's a pity.
Vassago I'm expecting your tutorial, thanks for doing this.
DDS.
This kind of information unfortunately seems to be a trial & error expierence, unless you know someone who actually knows how engine/3d app compute their tangents... ideally that would be written in some SDK doc as well.
edit: should have said that the tangents are more the "key" than the normals to normalmapping. They are computed out of your normals and the texcoords. Which is why seams/mirroring of texcoords will make it hard for the app to know what you really want. However as seen in the max8 shots, there already are ways to solve the issues, mostly by breaking the mirrored vertices up again, which results into a higher vertex count in your mesh, then again nothing one should really bother these days, as fill-costs ie. pixelshading is more fancy (useually you see more pixels of your model than vertices )