Super-fantastic! Thread and very informative.

Always good to learn more and I have read every post so far trying to soak it all in. Keep going gents and I like your suggestions fritz.

Rick that is a lovely link also btw, I think it should be relate to all game art in general even sticking diffuse and all the other maps in there to totally eliminate the need for duplicated threads on the same subject matter that has already been discussed. (Maybe pointing to some links for a visual preception) just a suggestion...

We could just point to that wiki link and boom problem solved for the newest of the noobies or people interested in a career change.

eric:
http://graphics.stanford.edu/papers/surfacefitting/
http://www.cs.unc.edu/%7Egeom/APS/

code behind tangentspace (one way)
http://www.terathon.com/code/tangent.php

haven't wrote such a normalmap generator myself, but basically it should work like this.

basically you first rasterize the mesh and turn it into an image, that is your UV layout, but at each pixel you have information about position, normal and tangent/bitangent. Each were previously calculated per vertex before, and now are interpolated over the triangle, giving each pixel a mix of those attribs.

Now you create a accelerating structure for the raycasting, this is straightforward as raytracing is well, the oldest form in computer graphics. Basically those things make it fast to shoot rays on tri-meshes.

Now for every pixel in that UV layout, you shoot rays along normal. One time to "outside" one time inside, and check for closest hit. Now of course the ray direction and max distances can be influenced by values, cages, but anyway you should get some hitpoint. That hitpoint's normal you calculate (by interpolating the hit triangle's vertices' normals), and rotate it into the tangentspace vectors of your current "pixel". Any 3 vectors that are not all coplanar can be seen as some sort of rotation / axis orientation. They make up a matrix, and in the normalmap shader you use that matrix to rotate the lightvector inversely into tangentspace. While in the baker now, we rotate the hipoly's normals into tangentspace, and that is the result for each pixel.

Now the issues are mostly related to "how accurate" do we store tangentspace. Cause eventually it would need to be "per triangle", but we do per vertex and smooth things, just like the normal's are smoothed. Then when interpolating those vertex attributes, it must match both in baker and runtime version. Afaik that is were problems in 3dsmax arise, as they interpolate differently in the scanline renderer, hence you can generate "perfect" normalmaps that work there, but not in viewport.
Another thing is if you actually store all 3 tangentspace axis (normal,tangent,bitangent) or just 2 and create the 3rd being perpendicular to the plane the other two create. In the top link this simplifcation is done, to save vertex weight. I also read that there are quite some "issues" with tangentspaces that might create errors, some of those cases and workarounds are documented in the nvidia lib meshmender.

A classic problem is the "mirrored" UV issue. Basically the "non mirrored" tangent would look "up", while the mirrored would look "down". Now if both end up being smoothed, like vertexnormals, you get a vector of 0 length (they are total opposites, the mean is 0), which is very bad. Hence you must split this vertex into two, so that each tangent works on its own. There are a couple other cases where such splits can happen, mentioned in that library, though I dont remember them.

so in short:
* create tangent&bitangent vectors for each triangle. Smooth them if they are "similar" (think smoohting groups for vertex normals)
* create rasterized "pixel image" of interpolated tangent matrix (normal,bitangent,tangent), using the UV coordinates as "positions" of that image. Also store positions at each pixel
* For each pixel, shoot ray "in & out" from lowpoly pos, find hitpoint. Get hitpoint's normal and rotate into tangentspace. Store that normal.
* Save lowpoly with the same tangent/bitangent/normals attributes for use in game, and make sure that interpolated tangent matrices in shader match the ones used in baking.

just a note, the polycount wiki was mentioned in here and it *SHOULD* be live soon (as in this week...)

Carry on, lads, carry on...

Thanks CB, that seems more about theory though. CB are you exporting tangent data from another normalmapper, like Xnormal or somesuch?

I was wondering if people have been integrating 3ds Max's tangents, or Xnormals tangents, or something else, and how they work those tangents into their custom game format.

As I understand it, our format uses some special massaging for vertex data because we do all this blending... morphing vertex positions, different material borders, different normals, different UV borders, etc. So apparently our tangents need careful preprocessing. Probably a bit beyond what I need to know, but we're still getting seams here and there, and I want to solve those if we can.

here is my noob question.

What is the best way to generate an ambient occlusion map with floating geometry in 3ds max 7+?

Also is it better to render a higher res normal map and then shrink it down in PS?


I typically model in Silo all quads to get a nice subD shape then export a .obj to max for doing the normal map.

Recently I started looking at using Xnormal going to dig in on it this weekend but seems like this is something that should be able to be accompished in max.

- Jesse

iv'e got a question - that i haven't seen addressed here as far as iv'e seen -
it involves normal mapping and uv mirroring

i.e iv'e got two identical limbs on my model - but only space for one in my uvs's (and would normally overlapp for skinning purposes) - i know that when you bake with overlapping uvs the normals get iffy ( and thus only bake one limb) - but what about afterwards?
when i overlay my other limb's uvs on top of the baked one - that limb is inverted as far as normals go (in is out and out is in etc) - i can't invert the green channel because that would reverse the problem..
how can i get my model looking right and not having one limb proper and the other wonky..
( i see a lot of normal map textures, here especially that only have one arm/leg etc in the texture space)..oh and my model was originally created in max using symmetry - does the mirroring effect affect it that way?
and to solve this: do i only have a lowpoly model with one arm - bake it and everything, and then mirror the arm part afterwards...

sorry if this is a long rant - iv'e been experimenting, but nothing seems to work.

hi i just learned normal mapping, i need to know how to fix the seams

this is the map


here's how it turns out



wires



I exported the low poly to zbrush and imported the high poly back to max to bake the normal cause i do not know how to do it with zbrush. [img]/images/graemlins/frown.gif[/img]

[ QUOTE ]
What is the best way to generate an ambient occlusion map with floating geometry in 3ds max 7+?

[/ QUOTE ]
Poopinmymouth offered a quick AO generator in this thread:
http://boards.polycount.net/showthre...age=0&vc=1

For the floating bits, why not just manually push them into the mesh where they would normally intersect, just for the AO bake? Seems like a valid method to me.

[ QUOTE ]
Also is it better to render a higher res normal map and then shrink it down in PS?

[/ QUOTE ]
The idea is this... when you turn off super-sampling or anti-aliasing or whatever multi-ray casting is called in your normalmapper, you get jaggies in the map. This tends to render much much faster, faster than AA-on at true-resolution (does Xnormal avoid this anyone?). So the trick is to render 2x the size and scale down 1/2. Just make sure to re-normalize the map, if your game doesn't do that already, because the un-normalized pixels in your normalmap may cause pixelly artifacts in your specular.

Oops, forgot to add, re-normalizing can be done with Nvidia's normal map filter for Photoshop.

achmedthesnake - sadly this is reliant on your engine that's displaying your normal mapped model. You're fine offsetting the mirrored UVs while you project your render and simply moving them back afterwards. The engine actually is supposed to fix your mirrored UVs when it processes the model. What's supposed to happen is when the tangent bi-tangent and bi-normal are generated it's supposed to see that UVs are flipped, split that vert and calculate accurate mirrored bi-tangent etc... for it.

Achmedthesnake: What tinman says is true, however if you're seeing this problem in the Max viewport, you could try using JIStyle's Skin Shader, or Ben Cloward's HLSL normal map shader. Certain default Max 7 shaders had trouble with mirrored UVs if I remember right.

Eric: We wrote a custom format for xnormal so we can load the exact tangents/bi-tangents from our ingame models, works really well. Anything else would give us artifacts.

Also, simply pushing floating bits into the geometry would be a really bad idea, as it would clip into the rest of hte model and you'de lose detail. what i do is just paint out the shadows around the floating bits, generally just takes 5 or 10 minutes to do this, even on a large texture.

another q for those normal literate -
can you have normal maps as well as alpha maps?(opacity maps). So if i had a b&w image in the 'alpha' channel of the tga - would that carry across into max? i'm currently using one of ben cloward's shaders.
and if so - does anyone know any alternate shaders that support this function in a max viewport?

[ QUOTE ]
[ QUOTE ]
Is it true that as you cross the equator,the green channel in your normal maps changes direction

[/ QUOTE ]

This struck me as HILARIOUS! I need to get out more...

[/ QUOTE ]

Yah, it had me cracking up. God we're nerds.

[ QUOTE ]
another q for those normal literate -
can you have normal maps as well as alpha maps?(opacity maps). So if i had a b&w image in the 'alpha' channel of the tga - would that carry across into max? i'm currently using one of ben cloward's shaders.
and if so - does anyone know any alternate shaders that support this function in a max viewport?

[/ QUOTE ]

absolutely.
IIRC, one of Ben's scripts was updated to work with alphas. And I believe ShaderFX works with alpha as well.

Awesome thread, I just read it from top to bottom. I'd like to make sure I am wrapping my head around this stuff. So I am wondering if someone could check over my notes and let me know if I am incorrect with anything? I've outlined any questions I'd still like to know about with <font color="orange">orange</font>. Anything at all you see as needed a correct please please please let me know. Just go easy on correcting me as I am not very technical minded so technically explaining things should probably be done n00b-friendly.

And thank you so much for doing this.

NOTE: Any time I refer to something as an 'object' I mean the low-poly render mesh that'll be used in the game. If I am asking about the high-poly mesh, I'll simply say 'high poly mesh'.

My notes:

World-space maps:
-good for static props,
-collects the normal info based on the worlds XYZ
-collected through the 3d application
-object should not rotate in the game.
-smoothing groups should be defined before baking the normal map
-those same smooth groups shouldn't be changed after the normal map has been rendered. Or if you do change them, re-render the normal map
-blue/purple/pink/green colours

Object-space map:
-good for dynamic assets
-collects the normal info based on the objects location in XYZ
-most likely the normal map is generated through the game engine/custom pipeline for the game
-object shouldn't be rotated in the 3D app once the normal is collected
-Object can be 1 smoothing group because the hard-edge info is collected in the normal map. <font color="orange">Can someone elaborate on this for me? Is this correct?</font>.
-If it was rotated in the 3D app, re-bake the normal map
-Object can rotate in the game without lighting flaws
-blue/purple/pink/green colours

Tangent-space maps:
-Considers the normal of a face to be the Z axis then collects the normal information from that XYZ
-Hardly ever used
-multiple colours, not just blue, pink, green, and purple
-uses more resources when used in real-time

<font color="orange">Would a world-space map and an object-space map look identical if they were collected from the same high/low mesh? If so, is that because of how the normal information is stored in the vertices of an object-space map and thats where the real difference lays between object &amp; world space maps?</font>

Adam I remember reading something someone wrote a while back about the difference between all of these broken down simply and I almost thing it was something Rorshach posted. I'm digging through my stuff i have saved but if anyone else knows what I'm talking about please help.

world-space, basically a no-no, they are extremely unlikely to be used, as it would be never allowed to rotate an object at all. And for every instance of the object in the world, you would need a new normalmap, which is bs. Hence I doubt these are ever practically used in any game.

object-space, however lifts this rotation limit, hence is perfect for solid stuff.

in both cases the object(low poly mesh) normals arent needed at all, and completely ignored, so whatever its smoothing group is, doesn't matter whatsoever. (but to aid your exporters and minimize vertex split, you should just give all the same smoothing group)

the problem with all these things is how you define "world and object" space. Say what 3dsmax calls world, in a scene, actually becomes an object in a level after export, and in that level the worldspace might be different again... I refer to the final world (that is level geometry) as world space.

Thanks Tinman for replying to my question about the uv island thing. I'm not sure if I illustrated it correctly or I made my point at all with my examples though. [img]/images/graemlins/wink.gif[/img] It's kind of hard to ask questions about something when you don't really know what to ask.

Does the orientation (rotation) of the uv islands matter with respect to each other. Say the left side (uv island) of the object when unwrapped is pointing up and the right side is pointing down. Would this create seams? It seems from the render in my first post of the baked normals that the colors of the normal mapped get assigned depending on how the uvs are oriented and not the actual model geometry. Is this correct? You'll notice that when I rotated the entire uv layout just to save time on my part, the colors of the normal map change to match the orientation of the uvs islands instead of the model geometry.

What's the best way to get rid of seams in normal maps and is there any way to prevent them entirely? I have read Poops tutorials on dealing with seams, but doing this on a complex machine would kind of suck in terms of how practical is it, and he kind of jumps. He mentions that it took him awhile to get to the final normal map. I'm wondering what happened. If you don't just press the magic render button and wait for the 5 to 10 minute magic to happen then what. [img]/images/graemlins/smile.gif[/img] I have seen tutorials were people use the rubber stamp tool and stamp errors out but I'm concerned about how good is doing that even if you renormalize the map. I'm I worrying about things to much here? It also seems that ever since I started using my new computer my normal maps are getting rendered better? I used to get all kinds of wierd crap happened, now they are gone. I haven't done anything different. Does having an old machine make a difference even if the old machine had a direct x 9 card? My old machine used to be a P3 with 768 megs of ram, geforce 256 6200. My new machine is a AMD 2.4 with 1 gig of ram and a geforce 128 6600.

What the best way of dealing with UV seams? I noticed that when when rendering tangent space normal maps padding in max 7 didn't do anything? What setting do you set the padding to to correct seam problems.

Do you have to set up even lighting to get good normal maps? Does the lighting setup matter at all when rendering normal maps? I noticed soemtimes I got strangely colored tangent space normal maps when having my low poly model have one smoothing group assigned to it. They seemed to go away when I added smoothing groups to the low poly. Imagine a tangent space normal mapped except the colors were more pastel looking and a rosy purple all over vs the typical tangent space normal map. Does using a skylight with the light tracer applied make normal map generation screw up? I read once that it causes problems, but I have gotten issues seem to get fixed when using it to bake normal maps.

Well that's it for now. Sorry for the delayed reply but I wanted to think about what I wanted to ask before posting. Thanks for the feedback.

Alex

[ QUOTE ]

Tangent-space maps:
-Considers the normal of a face to be the Z axis then collects the normal information from that XYZ
-Hardly ever used
-multiple colours, not just blue, pink, green, and purple
-uses more resources when used in real-time


[/ QUOTE ]

Tangents space maps are the *most* frequently used of anything. Most games you see, d3, ue3, use some sort of tangent space maps.

OK so object-space is great for dynamic props (animated, or moved about with physics, etc.)

Tangent-space: Great for static props

World-space: Don't bother wasting my time learning if all I am wondering about it games.

EQ: D3 uses both... so are tangents more for level art, or a gun?

tangent space = animated props, especially deformed meshes (characters), or as tileable texture detail
object space = "rigid props" mostly. That is "unique" stuff

tangentspace is much better for reuse, as you can use the same normalmap on multiple objects. I refer to the simple normalmaps used in levelgeometry here, not the unique per-character stuff. those typical tileable textures you use in levelgeometry... objectspace normalmaps would not work with tiling, or anything but require unique texture per mesh. (not per instance of the mesh, which is their difference to world-space normalmap)

say you ahve that "unique" trashcan, that could be both object or tangent, although object is "faster/easier".

once you want to derform the mesh on vertex level, like a characters arm, muscles, skin... you are better off using tangentspace. Also say you build a bigger house and texture it with several tileable textures, tangentspace would be the natural choice.

D3 does not use both.
You have tangent and object space mixed up there.

Anyone mind explaining these..?


Normal
Tangent
Bittangent
tri-stripping
&lt;any other technical term related to the subject&gt;

[ QUOTE ]
Anyone mind explaining these..?
Normal
Tangent


[/ QUOTE ]
A normal is a vector (an arrow) that points in the direction a face or vertex is "facing" for example, imagine a pine tree coming out of the ground. It would be the ground's normal.

The way the normal points is compared to where the light is located, and math is used to determine how much light it is receiving. if the normal is pointing dead on towards the light, it is fully lit.

I am not positive about tangent space, but I believe this is correct: Tangent space is the "plane" that our normal is perpendicular to. So in our example of a pine tree normal, the ground is the tangent space.

The old lighting method involved having a normal for each vertex, and blending the light values between vertices to give that smoothed sort of look. Having a normal per face gives you that faceted look.

The new lighting method allows us more normals, by baking them into a normal map. So instead of looking at each vertex, we look at each texel (texture pixel) and get a normal from that, allowing us to have many normals per triangle instead of the 3 for vertex normals or the 1 for face normals.

There are different ways to define a normal on a normal map. Both of them use red, green and blue to define the angle of the normal along the X, Y, and Z axises. There is no exact standard for which is which as certain compression algorithms may make it better to swap them around, or swap one of them for the alpha channel, etc. It is generally used as Red =X, Green =Y, and Blue =Z. Remember mapping a point on graph paper in math class? To define a normal we do the same thing, except along 3 axises instead of 2. The beginning point of this vector is always at 0,0,0, so we only need the end point to know how to draw the normal, and thus figure out which direction it is facing. since RGB is a 0-255 scale, and has no negatives, we move 0 to the 128 color value, so that &lt;128 is considered moving down the negative axis, and &gt;128 is considered positive. So a color like R=64, G=192, and B=128, is considered X=-0.5, Y= +0.5, and Z=0.0.

Object/World space normal maps place the origin of the normal at the origin of the object/world, so all of the endpoints it stores pointing away from that. As a result, you wind up with all the colors of the rainbow, because the Object/World normal map has to face in all directions.

Tangent Space normal maps put the origin of each normal at the location of texel, oriented along the tangent space. As a result, they tend to mostly point outward, which is why they are mostly blue, as they are mostly X=0, Y=0, Z=1, which is RGB 128,128, 255, which is a pale blue.

When building the low poly I have been adding extra loops on hard surface models to get decent shading when everything is smoothed. I guess it would be the same as adding smoothing groups in max because what I understand from this thread smooth groups adds verts.

Though adding a loop and sliding it gives me really good control of the shading.

Thanks again to all the vets in this thread.

Is this a good practice or do most engines sort out proper shading without those extra loops. Makes the low poly look much better in both silo and max.