[Technical Talk] - The ultimate be-all end-all normal mapping thread

[perna]

Summary: Ask all your nooby normal mapping questions in this thread, and we'll compile the info in a sticky to lower the level of noise on this subject and make things clear once and for all. I just say one thing to those wanting to volunteer answers: Get your facts right. I'm up to here with people trying to educate who have no idea what they're talking about and just make the situation worse, like saying that the low and hipoly models shouldn't intersect or some messed up stuff like that. Sorry, you guys just make the situation a lot worse.

Long rambling version of the above:
ok.. this... wtf...
I know there are moments when I don't understand shit of something and have such a lack of confidence in that subject that I just want to be let through the thing from step one. So I can understand that whole deal. It's like when I'm in bed with a woman, I still didn't figure out what goes where. You're right, Alex, there should be some sticky, if only to shut people up about this stuff because the same questions are answered I feel several times a week. Oh and it can be nice to be helpful. I just remember now how a lot of the people that now teach this stuff needed a hell of a lot of teaching themselves.

OK, let's do a new take on this. Of course I and some of the more experienced guys can give you all the information you need, we just think there are things so obvious you don't need to hear them. Let me get a sense of where the most nooby of the noobs are, ok? And let me understand if you're just damn lazy, or if you're actually making an effort.


So I'll try out some random questions just to test the waters.


Bounchfx: [ QUOTE ]
how do you go about re-building the low poly model on top of the high poly one if the high poly one is way too many polygons for your computer to handle?

[/ QUOTE ]

Don't you understand that you can just use a lower subdivision level of the hipoly that runs fine in the viewport? I'm not asking to insult you, I really want to get an idea of where you guys stand here. Feels like being one of those TV cops trying to track down a murderer by psychologically evaluating his crimes.

ok noobs, do you understand and can you visualize the direction that rays travel from the lowpoly to scan the hipoly model during processing time? This is vital.

What do you feel are the slowest steps of the whole modeling and generating process?

Do you have the necessary viewers/viewport shaders you need to properly check your results?

What kind of timeframes do you work with and what kind of timeframes would you LIKE to work with?

Where exactly does it fail for you?

And so on. Don't be embarrased to ask stupid questions. I might make fun of you, but hey, you'll get the information you want.

Also, let me tell you this, so you won't think that you're a complete moron to fail at this stuff: Some of the guys you look up to and who teach you about normal mapping now were completely retarded on the subject and took like years to understand the basics some of them.

I figured out all this stuff 6 years, so there's no question you won't get answered, just make at least a half-hearted attempt at prose. State which software you're using, what you're trying to do versus the results you're getting, and include illustrative images as needed.

quick addendum: Don't start moaning like a crybaby about how a poster hates you if you don't get the answer you wanted. Most likely you have to rephrase or elaborate on your question.

[perna]

No joke answers this time around, guys, let's get a good idea of where you all are.

[jgarland]

Great idea for a thread, Per. I don't have any issues with normal mapping right now, but I'm sure I will sometime down the road. I'll know who to pester from now on. /images/graemlins/wink.gif

[Brice Vandemoortele]

in this tutorial (http://www.svartberg.com/tutorials/article_d3normalmaps/d3normalmaps.html) the author shows differences between render and realtime, only refering it as "smoothing errors". Where does this come from? Is there different method to generate normals on-the-fly from a geo and how can there be differences in the results? how are they called and wich package use wich one? Does storing normal per vertex using "proper normals" (according to the generated nm) would solve theses issues?

thx /images/graemlins/wink.gif

[perna]

Brice:

In realtime rendering, vertex data is generally linearly interpolated between vertices.
For lighting, the original("gouraud" shading) reason is to give the appearance of curvature where there is none. In fact only faceted shading is ever "correct", but by having gradual transitions between verts, we can do things such as give the appearance that a 5-sided cylinder is actually round.

Now, in offline rendering the interpolation does not have to be linear, which means that between two verts on a cylinder, the normal can move in a curve(the curvature is determined by analyzing surrounding geometry). Because of this, the shading on an offline lowpoly cylinder can look undistinguishable from that of a hipoly version of the same geometry.

Non-linear shading can be performed in realtime shaders, though due to the calculations involved it would often be more beneficial to rendering speed if you simply add more geometry instead.

In offline rendering there are also other similar tricks that will improve visual quality. In max, for example, it takes me half a second to render a box, while my graphics card can draw literally millions of them in the same time.

When you use world space normal maps, the problem goes away, since you're no longer relying on the existing, crude vertex normals of the mesh.

When you consider that each polygon influences the normal of the verts it touches, it may make sense to say that relatively smaller polygons should contribute less than larger ones. This can help cases where, say, a big smooth surface has bad lighting because a small piece of geometry sticks protudes from it. How solutions like this are handled, however, relies on the generator and renderer.

edit: oh, and this is an advanced topic, Brice is just hardcore and you won't be expected to know this stuff to work anywhere... though it can't hurt.

[Joao Sapiro]

per is made of winsauce BBQ ! u monkey...

[Rick Stirling]

Howsabout a few:

Q. Should I build the lowpoly or highpoly first?
A. It's up to you.
* Some people build a lowpoly model, then up-res it and sculpt it.
* Some people build and sculpt a high resolution model and then build a new low poly model around that.
* Some people build a low res model, upscale that, sculpt and detail it, then step down a few levels of detail and usd use that as their low poly (or as a base for building a better lowpoly).



Dunno if this will be useful, but when explaining what a normal map actaully was to someone, I explained the difference between a pixel and a polygon, and how UVmaps worked. Once this was understood I said that basically on a normal map each pixel was pretending to be a polygon.

[perna]

I think it's an issue of semantics. If you have a lowpoly model, then quadify, distribute its elements evenly and clean it up to become a cage, then make a hipoly model from THAT, then you didn't start the hipoly from the lowpoly, you started it from your cage.

There's a very large distinction between lowpoly and cage, and only in extremely rare cases can they both be the same model.

I would like to ask a question now: For those of you who see any advantages to building and optimizing a game model before you start working on the hipoly, what are they? I see a lot of people discuss this subject without ever stating what the advantages would be of finishing the lowpoly work first. If you don't see any advantages to it, why are you even contemplating doing it that way? It's like, I don't see any advantages to sleeping in the sewers, so I DON'T.

Not saying there can't be any advantages to a low-first approach, mind you, I've worked like that at times too.

[perna]

Rick: What I say along the same lines is first teach them about vertex normals, and when they get that.. I say, well now imagine you have such normal at each texel rather than at each vertex. I guess I cover that in the powerpoint thing on my site

[jgarland]

What do you mean by "the difference between a pixel and a polygon," Rick? Surely they couldn't have gotten this far in the industry, learning to use normal maps, without understanding the difference between the two?

[poopinmymouth]

Per, I've made a low poly first, and used it as my cage in Mudbox without any adjustments or quadification. In that instance the pros were:

Approval of the in game model first (important for this client)
I knew what the low poly would hold, since I already had it.
It seemed to go faster for my personal workflow.

That said, I've only done two models that way, but it worked out pretty well in that instance. Very few triangles anyway, and it was low enough that when subdivided a few times in mudbox, it didn't get any kinks.

http://www.mr-chompers.com/images/poop.gif (http://www.poopinmymouth.com)

[perna]

poop: Well I got to ask you now, has there ever been a case where the lowpoly doesn't "hold" as you say? /images/graemlins/smile.gif I mean you're experienced now.. lowpoly modeling tends to be a minor detail at the end of a project, not a big challenge exactly.
Maybe you can get into why it was faster for you that way?

You know, I want to pick everything apart so we can get to the depth of things once and for all, not because I'm saying one way is better than the other. It's like with the square UV thing; sometimes you do stuff because it "feels" right, not necessarily because it has any real advantage.

I wouldn't want this thread to dissolve into "whatever works for you".. which is very like hippie, peace and love, and everything, but is really worthless for someone looking to be awesome at what he does.

Like with you, I worked from lowpoly models because the client already had them made.
Mind you, I didn't subdivide the lowpolies, I used them as base for the cages. In some cases, like with you, there's been very little difference between low and cage, but those are exceptions.

If you're given 20k tris to do a character and told to optimize for polystrips, then your low may very well end up looking like a nice cage. If however you're working with 6k tris and every poly counts, that mesh is going to make a terrible cage.

My point of view is that lowpoly and cages are so easy and quick to make that you might as well always take the advantage of optimizing them both for what they are.

[poopinmymouth]

Oh to be certain, if given my own preference, I like working with a cage that I upres for the high poly and optimize for the low. No question. I find that to yield the best results.

However if I'm trying to be super fast, building a game res, sculpting it up quickly and then baking, can be faster. Not sure why I feel that way, I've never tried it twice on identical models to check. It just feels like the shortcut hack that yields passable but faster results.

Oh and by "hold" I mean what amount of silhouette I can make with the poly limit I'm given. If I model the game res first, I can figure out if the pocket on the pants can be an extruded volume, or if it has to sit flush on a tube. That can dictate how I sculpt it, flat, or more volumetric.

http://www.mr-chompers.com/images/poop.gif (http://www.poopinmymouth.com)

[perna]

haha this back-and-forth is working, you just brought up a great point.. the shortcut hack. Personally I find it hard to turn something in that isn't like Per128 representative. Often the clients are more than happy with something that is just ok looking, and it's important to know how to churn stuff like that out.

I got to stop writing how I speak, I mean not because it offends people but it just takes too damn long /images/graemlins/smile.gif

[Joao Sapiro]

i usually work on the highpoly first , then i import a mid level of detail into max and make lowpoly around it , but in a recent work i had to present a game model with uvws before even starting highpoly, what did i do ? i made the highpoly basemesh ,and made the lowpoly around it and bake normals from it to see if it could hold it and it worked, twice the work , but i got the work delivered before time...

P.S - yeah im dumb.

P.P.S - awesome thread.

[Joshua Stubbles]

[ QUOTE ]
I got to stop writing how I speak, I mean not because it offends people but it just takes too damn long /images/graemlins/smile.gif

[/ QUOTE ]

Are all norweeeeeeeeeGiAN's long winded?
You're a mean bastard though, Per. Thank you. /images/graemlins/laugh.gif

I usually work on a middle-road cage, then split off into each version. Usually I'll do the low poly first, then the high (with the low poly semi-transparent in the same scene).

[JKMakowka]

Ok here is my question:
I was told that is is best to tweak the lowpoly mesh before rendering the normalmap and then just use the resulting texture with the original untweaked lowpoly mesh (since the uv is the same). This all make perfect sense to me in theory, but does anyone have any good tips on how to tweak an actual model for normal map generation?

[perna]

JKMakowka: I take it you talk about when you have normal map warping, but are at the top of your polybudget, so you want to: add polies to the generation mesh that are not added to the game mesh.

OK, if we just asssume for now that you know how and where to add those polies, I'll briefly explain why that technique can be good sometimes. The lowpoly normals control the direction of each ray. When normals point in all sorts of weird directions, you can end up with a skewed result, like a perfectly round shape on your hipoly turns out oval in the normal map.

When you add extra, temporary geometry, you force the normals in that area to angle more towards the position of the geo you added, like to avoid interference of polies wrapping around a corner or edge. This is great for capturing the shapes correctly, but since the new geometry won't exist in game, there's now an inconsistency that results in lighting errors. Sometimes it's not very noticeable, and I've used this technique myself on mechanical work.

[StJoris]

Thanks for having this awesome thread.
My question:
I usually have trouble getting the cage right, I'm not sure wether tweaking the individual points fixes things or makes things worse. If I manually move points into other directions, not perse in the normal direction used when doing "push", it seems to sometimes be beneficial. Especially with cylinders it seems to work well, but I'm wondering wether in other cases this might mess up more than is good. Is it bad when the cage intersects? I have had some problems preventing it from intersecting when I had tubes running close to a surface.

[perna]

the cage controls the direction of the rays, meaning it's no longer in the hands of the normal directions and you'll have less need for techniques like the adding temporary geometry to control your result.

I think the best thing to do would not be to explain how to use the cage, but to make clear the nature of how rays travel and how normal mapping actually works.

There's a ppt file somewhere on my old tutorial page that deals with it, maybe you'll want to have a look at that and come back here with your findings? It's got illustrations, which is more than what I have time for right now.

As for intersection.. the position of each cage vert controls the end point of a ray range, so it should always extend past the geometry you're baking. I may have misunderstood you on that one though.

[JKMakowka]

Yeah that was a part of what I ment, but I was also wondering if relaxing the mesh slightly, or moving certain polys closer (or further away) to the highpoly mesh would help.
Sure the result is then slightly inconsistant, but it might be worth it in that particular area of the mesh.

[perna]

JKMakowka: I hope we get some illustrations up here, because what's going to help you the most is to be able to confidently visualize the rays on a per-case basis, much like Einstein famously did. When you understand the nature of how the trace rays move, you can predict the result.

I've moved away from cages since I tend to edit texture, lowpoly, uvmap and even hipoly simultaneously towards the end of the project, to get everything to match up, and because of this need to be able to move between any stage freely.

[perna]

Can anyone tell me whether their software has a ray limiter function? It would would be a mesh that determines the length of each ray by stopping traces upon collision with it. That way, it doesn't need to match the lowpoly vert count in any way.

I'm sure I've seen it quite a while ago, but can't remember in which app.

[Joseph Silverman]

I think he means when the cage intersects with itself. Which I don't imagine would be good, but would also appreciate the answer to. Specifically why/why not, exactly.

[Sage]

Okay, I consider myself a noob, why because I don't yet make a living just doing game art and have to work a shit job to support myself, and I have yet to have a published game under my belt. This is as far as I have gotten making normal maps.

Big problem number one. Failing to see the importance of how you orient your uv islands when baking your normal maps. It's important and solves most problems noobs have with normal maps. I can give a half assed answer and I will give what I think is going on so someone that knows the full story can educate me. You make a tank chassis for example and you unwrap it. Here is my cool tank. /images/graemlins/wink.gif as an example. I unwrapped considering the orientation geometry had and matched my uv islands to it because depending on the orientation the uv islands have is how the normal are generated. I generated two normal maps to illustrate what I mean. My question used to be does the Normal map generator consider the model itself or the uv island orientation.

http://apsentertainment.com/previews/ct_uv_n.jpg

rotated uv layout and rebaked normal mapped

Big problem number one. Failing to see the importance of how you orient your uv islands when baking your normal maps. It's important and solves most problems noobs have with normal maps. I can give a half assed answer and I will give what I think is going on so someone that knows the full story can educate me. You make a tank chassis for example and you unwrap it. Here is my cool tank. /images/graemlins/wink.gif as an example. I unwrapped considering the orientation geometry had and matched my uv islands to it because depending on the orientation the uv islands have is how the normal are generated. I generated two normal maps to illustrate what I mean. My question used to be does the Normal map generator consider the model itself or the uv island orientation.

http://apsentertainment.com/previews/ct_uv_nr.jpg


model shots

hi
http://apsentertainment.com/previews/c_tank_h.jpg

low
http://apsentertainment.com/previews/c_tank_l.jpg

low with normal map

http://apsentertainment.com/previews/c_tank_p.jpg

If my images are too big I'll shrink them.

My process:

1. Make low poly and unwrap to my liking. Optimize it so it's as efficient as possible.

2. Copy low poly before I remove quads for example, call it hi and add more detail if needed. I try and get a nice smooth result in the lighting with this since the low poly model will use the normals for shading. If there are areas that look wierd I'll change the smoothing groups, turn edges add quads. This model can be subd if needed.

3. Make all the floating geometry I want to finish the model.

Problem number two. What's the proper use for normal maps? If I wanted to make my tank chassis not look like it has those sharp angles should I bevel those angles for the low poly game model or should I try to fake it with the normal map? Is the normal map supposed to contain small details like pores, rust, dents or is a bump map still used for that?

This is it for now, I'll ask more later. Thanks.

Alex

[conte]

good thread, Per.

[JordanW]

I'm not entirely sure what your first question is, are you asking if you have to orient your UV sections a certain way? If so, then in my experience the answer would be no.

Question 2, It generally does help to have bevels on the model, it makes for a cleaner normal map and helps avoid bends in light. Plus you get rid of sharp angles which can hurt the illusion the normal map creates. As far as pores and dents go, you can go ahead and put those into the normal map (if the pipeline doesn't use bump maps).

[Daz]

[ QUOTE ]

I would like to ask a question now: For those of you who see any advantages to building and optimizing a game model before you start working on the hipoly, what are they? I see a lot of people discuss this subject without ever stating what the advantages would be of finishing the lowpoly work first.

[/ QUOTE ]

Circumstance has forced me into working this way a couple of times. Not many, just a couple. In an nutshell, we were a 3 man team consisting of character artist, character TD and animator, working against a hard deadline to complete a demo to show our venture capitalists that we hadn't been spending their money in Vegas.
Now, in that instance, with each team member having a very specific role and little time, it made infinitely more sense for me to nail the mass and proportions of the game resolution model in a day and hand it off for rigging and animation, than to have those guys twiddling their thumbs for days while I sculpted leisurely and merrily away in Z. So really, it's a time management issue. It's definitely a bit more scary, since there isn't too much scope for tweaking stuff at the sculpting stage if someone else is well into walk and run cycles for the creature. But yeah, where possible I'd start with the sculpt.

[perna]

Thanks for contributions!
Just a quick one before bed...
SupRore: Self intersection as I understand it would mean the rays are crossing at some point. Now, if the hipoly mesh is placed beyond that point, the end result on the normal map will be a mirror image of that area.

Again a ray-path visualization illustration thing would be super useful here. Basically draw a line from each vert to its corresponding cage vert. That's the path the ray is going to travel. All the rays between two verts will have angles that are interpolated between them. Wherever the ray intersects with the hipoly, is the are where the normal will be read and plotted back on the normal map.

For a cylinder, ideally you'd want all the top triangles to have normals that face upwards and the side triangles to have normals that face outwards, in a circle. That would give you the best result. However, when both top and sides are the same smoothing group, faces on the side and top share vertices, and since normal are per-vertex, you now have a 45 normal degree angle around the rim. For many cylinders, you'd want to grab the rim verts in cage and pull them down so they describe rays/paths that are perpendicular (stick out from) the cylinder sides. What will happen now is that you should get perfect cylinder sides.. the caps, on the other hand, will have rays that travel in a 180 degree arc on the extreme. In cases this may be ok, where the surface there is simple, or hidden by other geometry, like a tube is sticking out of it or something.

These things only tend to be worth playing around with only if you can't afford to add more faces to smooth out the normal transitions.

You can set the cap elements to a different smoothing group. You'll get a hard edge, which may not be too bad in some cases. Ok, this leads to another issue, which I'm going to describe just superquick now:

the render engine doesn't care for polygons as much as vertices. When your art lead gives you a poly budget, he's basically giving you an approximate vertex budget. When you use smoothing groups (I take it everyone's familiar with the term, even if it's max-centric), the engine breaks up vertices at that point, even though they seem connected in the 3d editor. This, of course increases the vertex count. Basically what this means is that instead of setting cylinder caps to another smoothing group, you might as well chamfer the whole ring there. The end vert count will be the same. The reality of performance is a hell of a lot more complex than polycount. Often by optimizing and triangulizing a mesh too much, you're creating something that is less optimal to render than if you actually ADDED geometry. One thing all this translates to is that once you've hit your 5000 poly budget for a model, you should in most cases be free to add a couple hundred tris to fix normal mapping errors, it's going to mean zilch for the render performance.
Well, better yet, always keep in mind that you're going to be adding geometry AFTER you've unwrapped and tested normal maps on your model. I always aim a little lower than my budget, then slightly exceed it after adding geo to fix shading. That's a lot better than being stuck at 5000 with no room to navigate since you've carefully balanced your tri usage so well that you can't remove a couple without the whole thing falling apart.

Phew, I'm gonna have to learn to be more concise

[Joseph Silverman]

Ah, thanks for the excellent post. /images/graemlins/smile.gif

The quick breakdown of verts/smoothing groups in engine helps a lot. I'd read before that separate smoothing groups would double the vert count on the edges, but for some reason it never clicked with me that this would mean chamfering the loop was pretty much the same performance-wise.

[Rob Galanakis]

Per, on the subject of chamfer/bevel/hard edges, I wrote up a somewhat brief article a month or two ago:
http://www.twcenter.net/wiki/Beveling

[Brice Vandemoortele]

hehe no per, glad somebody try to explain what lies behind /images/graemlins/smile.gif please don't be concise ^^

[ QUOTE ]
In realtime rendering, vertex data is generally linearly interpolated between vertices.

Now, in offline rendering the interpolation does not have to be linear
Non-linear shading can be performed in realtime shaders, though due to the calculations involved it would often be more beneficial to rendering speed if you simply add more geometry instead.
When you use world space normal maps, the problem goes away, since you're no longer relying on the existing, crude vertex normals of the mesh.
edit: oh, and this is an advanced topic, Brice is just hardcore and you won't be expected to know this stuff to work anywhere... though it can't hurt.

[/ QUOTE ]

thx per for your answers /images/graemlins/smile.gif I got your point about interpolation, but I still can't figure out why results vary from one software to another, both in realtime rendering. Maybe some do renormalize the interpolated vertex normals while some others don't? Is there different algorithms to generate normals?
For example max don't display seams on uvs borders most of the time, while maya does. I think it's because maya generates vertex's normal on the fly for cgfx rendering (highquality is basically a big cgfx), while max stores some kind of precalc normals. Since vertex are split on uvs borders as well as hardedges - as you mentioned above - the normals are slightly different, showing a seam.
What do you think? I do understand adding geo will help normal map covering a tighter angle, I just like to know hehe It will help me going more easily from one package to another.

[Gav]

[ QUOTE ]

Circumstance has forced me into working this way a couple of times. Not many, just a couple. In an nutshell, we were a 3 man team consisting of character artist, character TD and animator, working against a hard deadline to complete a demo to show our venture capitalists that we hadn't been spending their money in Vegas.
Now, in that instance, with each team member having a very specific role and little time, it made infinitely more sense for me to nail the mass and proportions of the game resolution model in a day and hand it off for rigging and animation, than to have those guys twiddling their thumbs for days while I sculpted leisurely and merrily away in Z. So really, it's a time management issue. It's definitely a bit more scary, since there isn't too much scope for tweaking stuff at the sculpting stage if someone else is well into walk and run cycles for the creature. But yeah, where possible I'd start with the sculpt.

[/ QUOTE ]

I've used this workflow before as well for more or less the same purposes. Getting work to the animator faster so that he could animate while I sculpted and we'd both finish for the deadline.

[bounchfx]

Okay, this thread is awesome, but I have a few (undoubtedly noobish) questions.

You say cage and low poly, I think I'm getting confused, and I think I'm about to answer this myself.. it just got confusing the way you guys were wording it..

CAGE is what you use to build the High Poly from, Right? and the low poly is obviously the model that will be used in game that the high poly is projected onto? I guess I just got confused with the term CAGE.

Ok, the other thing is you were talking about having intersections when you go to bake the normals in.. between the hi and low poly models.. and this is.. ok to do? having them intersect? Not sure I fully grasp that yet, but if that's true I guess you are trying to say that it shoots the rays out both ways and not just inside from the low to the high? (or whatever)

and here "Basically draw a line from each vert to its corresponding cage vert." I think I might be reading the context wrong but I believe you are talking about from the high to the low (vert coming from hi, cage vert being low?), how can there be corresponding verts because the high poly is going to have a shitload more than the low obviously

I hope I'm not getting too off-track or reading stuff the wrong way, any help is hugely appreciated, this info is gold for trying to learn and understand better.
Thanks!!

[Joseph Silverman]

Projection cage, which casts the rays that determine the normal map's rendering -- from Ben's tutorial --:

http://www.poopinmymouth.com/process/normal_workflow/normal_13.jpg

Doesn't theoretically have to be your lowpoly, as far as I understand, the uvs just need to line up.

[bounchfx]

dumb question answered

[Rob Galanakis]

Profanity on message boards is fine when its used with reason. Honestly, it makes you seem retarded when each sentence contains the f word, not to mention quite annoying, at least to me.

Cage is your projection cage, or a quaded-out low-res model that you sculpt from. Different contexts.

[bounchfx]

yeah, I'll cut the bombs, they are unnecessary, I was just getting flustered. I was thinking correctly when I was thinking about the 'cage' then, and wasn't even thinking about the fact that you can tweak the cage as much as you needed. d'oh. Thanks.

[StJoris]

[ QUOTE ]
Again a ray-path visualization illustration thing would be super useful here. Basically draw a line from each vert to its corresponding cage vert. That's the path the ray is going to travel. All the rays between two verts will have angles that are interpolated between them. Wherever the ray intersects with the hipoly, is the are where the normal will be read and plotted back on the normal map.

[/ QUOTE ]

Thanks for explaining that, that cleared up a lot:) You talk about adding temporary geometry, how would I go about using that? I've tried using tesselate with tension: 0, so it has the same uv's, but it doesn't make my normal maps any better.
And sorry for the many questions but another:
Sometimes parts of the mesh can have the same uv chunk because of similar geometry, but it would not look good because the normal map. How do I know which parts I can mirror fine and which totally don't work?

[perna]

Appreciate the questions and feedback, people. It's all good stuff.

I know it can be hard to go through all the info already in here and know what's relevant now. Call it brainstorming, we're just pouring out bits of info and discussing, it should all come together in the end.
Here's something from another thread:

Basically what happens is when drawing a new strip, the renderer only has to plot one new vert to describe an entire polygon.

The problem is.. it's not like you can spend time benchmarking every single model you make and tweak it until it has the optimal tri flow. Most of the time you'd be talking about such tiny performance improvements that it's not even worth considering.

There are so many other factors involved as well, when it comes to tweaking for performance, that you're better off just following the polybudget you're given fairly accurately.

The reason why geometry is split up and vertices doubled at UV and normal seams, is that the typically a vertex is stored on the graphics card as having only one uv coordinate and one normal.

[Eric Chadwick]

On the topic of vertex duplications, it should be mentioned that vertex count is more important than triangle count. I know I'm not going to change years of habit. But vertex count is really where the rubber meets the road, not triangle count.

Overuse of smoothing groups, over-splittage of UVs, too many material assignments (and too much misalignment of these three properties), all these lead to a very different and much larger vertex count. Which can stress the transform stages for the model, slowing performance.

FatAssasin made a great Maxscript awhile back that gives an accurate vertex count, might be useful.
http://boards.polycount.net/showflat.php?Cat=0&Number=9246&an=&page=0&vc=1

Kind of in the same ballpark, too many bones affecting each vert is bad (>4 per vert), and too many bones on one mesh is also generally bad (>30 or so. Better numbers here anyone?).

Cool thread Per2048.

[Whargoul]

Hah - just saw your posts about vert counts, after I posted about it in the tri-strip thread.

Anyways, just wanted to mention the way Maya uses's it's cage (called an envelope in Maya). It does NOT control the direction the rays are fired - it only limits them from passing (well... one option does that, the other chooses the intersection nearest the envelope) through. This is really what a cage should do - firing rays not along the surface normal is actually incorrect, but tends to look better visually in some cases. I think skewing the cast increases the parallax erros somewhat, but it's a sketchy area. A model will always look the best when viewing "down" the normals it was cast at. The old cyclinder with wobbly edges (a great test case) looks shitty when viewed from the side - but perfect when viewed at the 3/4 angle (where the smoothed normals are looking at you).

The one nice thing about Maya's envelope's are that they don't have to be the same model, shape, or anything. You can just throw a plane in between the character's legs and call it a day. You can edit the auto-created envelope (your pushed model), split edges to get around a tight crease, smooth the whole thing, whatever. Pretty handy.


Back to Eric's topic of vertex counts. UV splits, hard edges (smooth groups for you Maxians) inflate the vertex count. Material breaks & bones don't inflate the vertex count directly. Materials will cause a draw break, ie. even worse then adding extra verts. The renderer has to submit a new draw call, switch shaders, upload constants, etc. More draw calls per model = worse performance.

Adding more weights per vert kind of does the same thing (in our engine). A "chunk" of model can only have so many bones weighted to it, in total. This isn't as bad as a new draw call, as only the bone's matrices need to be uploaded, and can be streamed in with the vertex buffer streams. But it does add a small cost. The model gets broken down into mesh fragments, each using only a limited number of bones (I think ours splits at 40). A full human model can get split into 3 to 5 pieces if it's 1 whole model using 1 material. If it's already split into materials (shaders), sometimes only 1 or 2 of those needs to be split into a couple mesh primitives.

More bone weights per vert makes the problem above a little worse, as now there's a larger list of needed bones for each chunk of mesh, potentially making the chunks smaller (and greater in number). The vertex shader code also gets larger (an extra matrix mult and add per bone weight) and causes more data to be passed around per vert. 4 is usually enough per vert anyway - it's pretty rare to need more than that. The pipeline can auto reduce this as an optimization, and it's hard to spot the differnce. We tried limiting it to 3 bones in the pipe, and it was only a few spots that the person who weighted the mesh could even tell the difference. Pretty subtle.

Now, how I build my models. I usually do this:

1. Build proxy/cage/dummy model in Maya. Just a boxy thing with all quads, good layout for zBrush/Mudbox. Quick UVs, clean layout, no overlaps, good coverage. Helps if you want to extract displacements from other models to re-use, or for step 6.
2. Sculpt the shit out of it in Mudbox - get approval on this model from AD. Use lots of tricks like multiple meshes, floating bits, different rezzed sections, etc to make it manageable.
3. Bring the mid-rez version (usally anywhere from 50k to 300k - whatever hold all the detail I need to see) into Maya as a reference.
4. Build a new low poly model. Sometimes it starts from scratch, sometimes it start from a low level of the high rez model, and usually it's a combination of both. For a character (say an arm), I usally just create a cylinder, align it to the model, and shrink wrap it to the surface. Then I cut all my muscles in, add edges where I need them, cut all the folds & wrinkles in, etc. Optimize the inner areas (where silhouette doesn't matter), add any cuts I need for deformation, and stitch it all up. Really focus on the solhouette edges, and internal occlusion. Follow the surface as close as you can, I like to exaggerate the surface more than the high-rez (ie for wrinkles: deeper in the cracks, higher on the highs) to help with parallax and self-shadowing.
5. UV map - as few breaks as possible. Mirroring is OK depending on the engine/pipeline. I move all mirrored stuff over a unit in UV space to make the sampling easier.
6. Generate AO off the high-rez model. I sometimes do a few passes and blend as needed. Ie no floor, floor, arms up, arms down, etc. This help shape the model a bit. Place this as a colour map on your highest high-rez model. If no UVs, just autogenerate and bake a huge map.
7. Sample maps - grab normals and AO off the high rez.
8. Paint bump textures, Photoshop nVidia filter for fine details, overlay this normal map onto the sampled one. Paint other coulour maps, etc.
9. weight model, export, finish...

Sometimes I jump back and forth, ie I might paint a colour map between step 4-5, transfer that to the high-rez, to help place details on the high-rez model that align to a specific colour map.


(I can't believe PC still has the bug where if you take too long to write a response it gets lost - fucking hell I typed this up twice, excuse the typos but I'm tired!)

[perna]

Great post whargoul. So it was in max that I'd seen the envelope feature.
Eh, yeah the lost message thing happened to me too, kind of discouraging eh?

I'm gonna get around to older stuff in the thread when I have the time kids

[Eric Chadwick]

Whargoul, nice post. I like the sound of Maya's envelopes. Smart.

When PC tells me the post is invalid, usually the Back button gets me back to my text. Anyhow, I'm paranoid here, I always Ctrl-A Ctrl-C before hitting that Continue button.

[CrazyButcher]

hehe whargoul, I am trying to make (ctrl+a,ctrl+c) before posting big stuff a habit for that reason, or writing into notepad /images/graemlins/wink.gif (like this one), but thx for retyping!

about the vertex-bone-assignments. As whargoul suggested limits like 2-4 make sense, because anything beyond normally is not visible. Sometimes this weight reduction can be done in code (find the most dominant weights, and evenly spread weight of too subtle ones), but in general to have a true wysiwyg experience you can check for the limits yourself.

now concerning rendering performance, there are many "ifs" and "whens" when it comes to rendering. Engines might do things different, the hardware generations often are different as well. Here is just some general statements

------
short
------
Get it good looking with the least possible counts, but don't let some fixed counts prevent it from looking good (artefacts...).
And dont forget consistency. If your game enviro is fairly low (but mostly complete) it makes no sense to put some hi-res characters in it, eventhough the renderer can afford it.

Skip to end, probably redundant info for many of you...

------
long
------

memory-costs
------------
obvious, the textures used cost "most" in average. That is more true for characters than with their unique textures, then environment which reuses stuff, but still texture data will typically be the biggest videoram eater.

vertexdata is the other. Typical vertex-sizes are around 32 bytes, sometimes a bit fatter, sometimes less when not much attributes (normals,colors,uv channels) are used. Also skinned models, typically require a bit more (boneidx + boneweight) for each vertex-bone pair. 4 bytes thats a uncompressed RGBA pixel (compressed you can typically divide texture costs by 4). So to give you a comparison of costs, a 1024x1024 texture compressed would weigh as much as about 10 000 unique triangles (that is every triangle has its own 3 vertices, which is very unlikely, only particles have similar uniqueness of vertices).
As hardware likes 32-byte aligned stuff, coders pack as much in as possible, sometimes sacrifice accuracy and so on, just to get everything needed in. Now say they found the "perfect setup" for all needed attributes, and then some artist comes saying he needs a second UV channel, which would mean say a size of 40 bytes instead of 32, and that is "almost as bad as 64", not to mention the fact that the shaders involved need to take this into account, as well... Normally they will make different versions of vertexformats, like light,medium,fat. And different shaders, but maybe they wont have the one you would like, and I just want to hint that something rather simple, might create an avalanche internally, and therefore cannot be done.
In an ideal world communcation and exchange about information between artists and coders about engine capabilities and setups, will result less problems.

This doesnt mean you are save off throwing around with vertexcounts, but it shows that textures are more evil. I think the one important thing about textures is keeping consistent texel-density. That is the size of a texel (pixel of a texture) in your world. A) it looks better B) it performs better especially when at the end it is similar to screen resolution. It makes no sense to have hi-res textures of characters that are tiny on your screen at the end, or if their vertex count matches pixels...
Be aware that to minimize drawcalls sometimes meshes are "dynamically" batched to bigger ones. Think of a "copying" a mesh but "not instancing" (only newer hardware can do that easily). Then of course the copying process is faster with smaller vertexcounts. And when not copied dynamically but statically, the static costs will be higher too. Think about level geometry, it makes no sense to instance every "box brush", but generate one giant triangle mesh out of all boxes. Characters normally dont fall in this category.

Who else eats videoram?
your framebuffer window, (color+depth, that is 64 bytes per pixel), then all those new cool post processing fx also tend to have "render-to-texture" so those rendertargets reside in vram, too (think floating point for HDR stuff you got 64 or 128 bytes per pixel for color alone). And of course shaders (which is somewhat negligable so).

state-changes
-------------

Graphic Cards are stream processors, ie they are super at doing "the same thing, very very often". They dont like it so much if you change "the task" often. Hence material/shader changes result into more drawcalls, as state cannot be changed during a drawcall, and less drawcalls is good.
However coming back to the statement that multi-materials and so on,require a new drawcall, that is not always the case. Think about all surfaces using the same "shader", that is say 1 texture + 1 lightmap. If you can manage to put the textures used into a bigger atlas, you can manage to render them all (same shader) with the same setup, and they will just pick their "subtexture" of the big atlas, hence requiring no new drawcall. Some engines might do this automatically (the atlas generation), some not. If not you can help packing multiple textures that are likely to be used with others in a bigger one. (Think trashcan + park bank + mailbox +...). This works easily for "non-tiling" textures, once tiling is involved as used in terrain (big walls..), this very often has to be handled on the codeside, as the tiling itself needs to be done in pixelshader, and not all might support/do that.

Shader changes are very costly changes. That is why we see not very different shaders (just with different tweak values) within a game. It is also a reason why "hey lets do my own .fx shader", do not always translate well, because they are too specific, and if there is too many "unique" ones, it isnt worth it. Also what makes it hard is that you need subversions of the same thing, like shadowed, skinned, both...
Other changes are like blending,alpha masking and so on.

vertex/pixel-operations
-----------------------
Before cards got a unified architecture (that is xbox360 & gf8/ati r600), there were dedicated units for vertex and pixel operations. This is still true for majority of hardware around, and basically means that if you "imbalance" operations, you can pump more time in the other. New cards share the same chips for all (pixel & vertex) operation, and do auto-load balancing.
For old, eg. you have a very complex pixel shader (normalmapping,subsurface...), then you could add more vertices for "free", as the pixel shader will slow things down. However if you have very simple pixel operations (think lightmap+texture), then vertex will cost a bit more.

Of course pixel costs directly relate to the pixels on screen, if your model is tiny, it shouldnt have too many vertices, as vertexcount would be too close to pixel count.
Be aware that vertex count is "all vertices" of the model, not only the visible! While pixel is only the visible (and even more if Anti-Aliasing is used)

What this means that say you have a bit more complex shader going, then very likely the pixel costs are much higher than vertex (because say you sample 4-5 textures in that shader, do lighting...), then adding a few vertices doesnt hurt. If that will get you a smoother surface (better bake result..) then dont think of polylimits as the ultimate law, but as a guideline.

Profiling (measuring speed of what takes how long) saves the day, good engines will offer you lots of data about "what the current frame costs", how many drawcalls, texture memory... Hence optimizing from a scene works fairly easy. The problem is you need the models/assets before to make that scene /images/graemlins/wink.gif
Also think about following within production "oh that new cool shadowing technique came out and we want it". The shader changes and so on might shift the "vertex/pixel" balance before. Also different hardware generations will shift... That is why games will often see completely different codepaths depending on hardware capability. And especially shader versions. Now combine that with the "one shader for specific needs, like 1light,3lights,+skinned... and you will see that certain shaders explode to many more. And eventhough this is more true for "current/older" hardware, that is what the majority uses.


Both vertex and pixel operations have caches. Caches are needed, as graphics cards "never evaluate all vertices first, then all pixels", but each triangle on its own. The result of the vertex shader is interpolated linearly over the triangle (pixels within a triangle, get a mix of the 3 vertices' values) and passed to pixel shader.

Easiest to explain with a vertex. Say vertex A is part of 3 triangles, it would be very dumb to reevaluate the vertex with every new triangle. So cards will store results of like the last 32 vertices (or more/less depending on hardware). Coders normally resort polygon and vertex order of models to make best use of that (if not tell them to!!). However if we are passed that vertex cachesize, and come again with some triangle needing vertex A, we will have to reevaluate it fully again.

For Pixels there is such a cache for texture lookups. As fragments close to each other normally have similar UVs/mipmap and therefore similar texel.

end long
---------


---------
in context of normalmapping
---------

How complex is your game's normalmap shader, how many textures is it already "pulling from". Is you model residing "static" in memory, is it being "skinned by bones"... How big is the model typically on screen (ie how many pixels)... this somewhat influences how strict you have to look at vertexcounts.

When using tangent mapping, the "tangent space creation" is the key, if game's method doesnt match baker's, you are in trouble. Check with coders which tools they recommend for baking, how they create them... Even worse 3dsmax's viewport renderer version doesnt match the baker's (which is based on scanline renderer), so slight errors on extremas might occur in viewport, but not in renderer.

A "object normalmap"'s vertex shader is pretty simple, the "tangent" version, not, it needs to transform light vector to tangentspace, it needs normal/tangent (and sometimes binormal) as vertex attributes.

Texture compression might leave artefacts, make sure that you try your normalmaps without compression before, to avoid hunting "baking bugs" that are none.


As for texture pixel useage, Eric mentioned those special .dds textures, that come with differently colored mipmaps. Try substituting your "diffuse" with them, if you end up never seeing "toplevel", then you can resize your texture by a quarter...

PS: is that long-winded enough,Per /images/graemlins/wink.gif

edit: I mixed up my vertex/texture weight comparison by factor 8

[MoP]

Very awesome thread here. Nice stuff Per, Whargoul, Crazybutcher - thanks! /images/graemlins/smile.gif

[EarthQuake]

I'll add in a little bit on object/world space normal maps, because most people seem to have incorrect information on this topic, i've wrote it before but i'll do it again for the sake of this thread.

Things you can do with object space maps:

1. Get perfect results regardless of the smoothing on your lowres mesh, amount of geometry you have, etc. Works great for making LOD's and reusing the same texture because the normals/binormals dont matter. And also is very good for mechanical hard surface objects, no need to split model into smoothing groups to get good results, or add tons of extra polygons(polys that you can then use to add even more detail to your awesomely rendered model)

2. You can animate meshes with object space normals, as long as the mesh is rigged and translated by the engine, and as long as the engine supports it. Definately not only for static props as some people will tell you.

Things you CANT do:

1. Mirror any parts of your mesh.
2. Rotate your model after generating in your 3d app, if this is done in your level editor/game engine, or just with animations on a rigged model its fine.
3. Add additional bump map detail. Combining these in photoshop can be a pain, because the normal map is using the full color range, not simply the blueish color....


If any of your programmers come and tell you you can't use these maps, they're just being lazy and refuse to take the 15 minutes it will take to add support for this stuff.

[Rick Stirling]

[ QUOTE ]
As for texture pixel useage, Eric mentioned those special .dds textures, that come with differently colored mipmaps. Try substituting your "diffuse" with them, if you end up never seeing "toplevel", then you can resize your texture by a quarter...

[/ QUOTE ]

And sometimes, you don't want the mipmaps -you only want the hires texture/1st mip level (main character who is never seen at a distance for example). In that case NOT creating the mip levels will save you both memory and disk space. I think it's around 30%

[perna]

I'm on some random laptop in the middle of nowhere, just want to quickly suggest that it's important to describe what something is before detailing all the advantages of that something /images/graemlins/smile.gif

world space normal maps bake the normals from the hipoly model directly, while tangent-local space normal maps bake the hipoly normal relative to the lowpoly normal, which means that the model can be freely animated without messing up the lighting.

To animate a worldspace normalmapped model you have to treat the onmodel normals differently. Iæm sure someone else can get into details here, but eq please stay sober and objective, if worldspace normal maps could save the world, nobody would bother with tangent maps. There are many things that CAN work, but aren't necessarily viable, well performing and scalable solutions

[Eric Chadwick]

I think you're talking about object-space maps. World-space and object-space = same bitmap, different shaders.

[Rob Galanakis]

Let's break it down some more.

A "space" refers to the setup of the XYZ axes. As far as normal maps are concerned, we have World, Object, and Tangent space.

Consider also what a normal is. It is a vector made of 3 variables, XYZ, which is encoded by the RGB information on a texture.

So, let's take the same point in space, or vector, or whatever. It is different in each map space.

World and object space are similar, in that they use a relatively comprehensible space. World space uses the world's XYZ, while object space uses the object's XYZ axes to describe the normal. For this reason, world space mapped objects can't move, object space mapped objects can move and rotate and whatnot put cannot deform (since the normals are always relative to the object's axis; as long as this relationship doesn't change, you're fine, which means you cannot deform the object and you must rotate and translate it from the object's root, meaning any sort of movement must be application based (ie, you cannot have it break into pieces unless each piece is its own object, for example).

Its unusual to use world space maps because they are so restrictive, and the cost of putting an object space map into world space is low (and object space maps are more foolproof... if you need to rotate your model in your editor, you are screwed). I don't know why anyone would use World space maps, tbh, except in special cases (something with environmental mapping, maybe? I don't know...)

Tangent space is much harder to understand conceptually. It uses the normal as the Z axis, and the surface U and V as the X and Y (gah I hope I didn't mix that up). So, everything is relative to the normal of vertex... I know I've seen tutorials at polycount about it and it is a complex topic so I won't go into detail now.

[perna]

Eric: Then we'd be talking about object space shaders /images/graemlins/smile.gif Again, let's try not to bring stuff up without describing what it is, saving people from getting even more confused than they already are.

Object space gets its coordinate system from the object pivot point while world space gets its coordinates from the center of the world. Now, theoretically there's a difference, but I have to say I've never run into a case in game normal mapping where there was any point in distinguishing between the two, and so terminology gets muddled there. Of course, if there's a practical use, I'd love to know, otherwise I think it can only confuse those that are already struggling with this stuff. When we're talking about practical application, purely theoretical info I think has little to no value at all.

I'm pushing this mostly because I've seen mixed terminology in generation apps, which is going to throw people off if we're telling them there's any practical difference between world and object space maps.

Oh, furthermore, afaik most generation programs actually consider worldspace, not objectspace. That is, when you do something like export an OBJ file, it doesn't tend to consider the object pivot, which adds to why we use the term as we do. Or why I use it, eq is probably just high (luv)

[CrazyButcher]

yeah world-space, would suck, that would be like "trashcan rotated xyz" and one may not change rotation at all, which is something that I think is never done /images/graemlins/wink.gif
normally stuff is based on object space, ie the same space the "vertices" are stored in. hence you need no vertex normals, and can straight use the texture. As EQ said, those can be animated if "rigid" and the engine does the animation, cause then the engine can also transform "lightvector" back to original object-space and do lighting there.

the problem with world/object and those definitions is that in a modeller file the "world space" would be the full scene = single model, which in turn becomes a object in the "game world"...

---
the main issues with object/world-space I guess would be:
compression: in tangent space, you can normally ignore the blue channel and recreate in shader, and therefore compress more aggressively

mirroring: actually can work with a hack (storing the mirror-plane per vertex), but most won't do.

tiling: wont work, textures are unique to object, therefore far less reuse possible (actually none at all), which adds to higher texture memory usage. This is also the biggest problem with them. But depending on situation it might not be a problem. Because "character" textures are unique anyway... And if your character is "mechanical", then this might be a real good option.

so I am with EQ, praising their ease of use and especially as they have no tangentspace issues, and there is plenty. For tiled enviro stuff, like walls... you would still use tangentspace, which works equally solid on "flat" stuff /images/graemlins/wink.gif
--

Rick, regarding the mipmaps, normally graphics drivers create them automatically, and in many cases this is done anyway. MipMaps are not only used for "distance", but are also critical for "slope", higher mipmaps are used under extreme angles. Else you will get aliasing artefacts. Anisotropic filtering then makes the "blurry slopes" sharper again. From what I read, always using mipmapping is recommended.
Though the 33% extra costs, could be indeed an issue in cutscenes when everything is hi-res to the max. And maybe blurring things and so on will hide the aliasing artefacts a bit again.

[Eric Chadwick]

Relax Per, all the junk in this thread needs to get edited way down before it'd be useful to the newb. Way too wordy and contradictory.

[EarthQuake]

I'm fairly certain you can even deform verts if the engine keeps track of it, but we didnt really test this very thoroughly.

[edit]^^ purely speculation btw, i'll try to get more info on this from the guys who wrote our system, it might be something thats unique to our lighting system as well so i'm not sure.

[Rob Galanakis]

World and Object space are NOT the same. You can't use an object space map instead of a world space map, unless your object pivot is at 0 0 0 and aligned with the world.

EQ, I don't know how that would work... I suppose its possible but I would think you should just use Tangent Space, as you would need to do some sort of matrix calculations to adjust your object space map properly... it may also be application side stuff, I just don't see why not just use tangent space though...

Crazybutcher, even if your character is mechanical, if the arms or whatever are part of the same object and use the character's pivot, it wouldn't work. Its just rigid deformation, really. But if each piece was its own object, it could work, but you couldn't deform it with bones or any such thing. It would need to be done procedurally or through your application.

[CrazyButcher]

it would work by inversely rotate the "tolight" vector (per vertex), as long as all triangle's vertices are rotated the same way. which normally applies to single bone to element bindings.

and isnt your partial agreeing with EQ about the doability, a contradiction to telling me it doesnt work?

my "engine passes inverse tolight" statement was probably too unclear, I didnt mean to use the same tolight vector for all vertices (deformed or not), that wouldn't work. however the inversion would need to be done in vertex shader, where also the deformation happens

[monkeyboy_garth]

Yeah, I'm with EricChadwick... this thread is becoming less and less about helping out noobs with every single post.

Here's a true NOOB question...

I have heard that a low poly model must not intersect any of the high poly geo when baking normals in max.

This doesn't seem to make any sense, but sure enough, with the few 'experiments' I've done, where the low res model intersects with the high, those sections have errors. What am I doing wrong?

[bounchfx]

Yea an easy way to noobify what you were discussing would be to lay out each type of normal style and describe and define. a la

Tangent Space normals ARE :
Object Space..
World space... etc.

when to use them, when not to use them. I'm sure it's in the discussion as I'm pretty sure but I don't remember it all after reading through the rest of the posts.. there's so much I'll have to take notes.. =) but if you want it friendlier that would be an awesome thing to compile this stuff into, for ease of reading. Thanks!

[Rick Stirling]

If you guys want to bung the condensed goodness into a Wiki (Like Mr Chadwick suggested last week), I can set up the rsart wiki to do this. Not trying to hijack the information, just offerin' the search space.

[MoP]

[ QUOTE ]
I have heard that a low poly model must not intersect any of the high poly geo when baking normals in max.

[/ QUOTE ]

This is not true, you can intersect the low-poly model with the highpoly in max as much as you want. You just need to make sure that the Projection Cage (see Max Help on the Projection modifier if you're unsure what this is) is fully enclosing all the highpoly geometry, and not allowing any of it to clip through the cage (I find checking the "Shaded" option in the Cage rollout of the Projection modifier helps for this).

[JKMakowka]

Don't we have a polycount wiki somewhere?

[perna]

monkeyboy_garth: [ QUOTE ]
Yeah, I'm with EricChadwick... this thread is becoming less and less about helping out noobs with every single post.

[/ QUOTE ]

I don't know where Eric said that, but can’t you try to rectify the problem by explaining it instead of unproductively complaining about it? We’re only able to answer questions that are asked, so it’s up to the noobs more than us to get this thread on track.

monkeyboy_garth: [ QUOTE ]
I have heard that a low poly model must not intersect any of the high poly geo when baking normals in max.

This doesn't seem to make any sense, but sure enough, with the few 'experiments' I've done, where the low res model intersects with the high, those sections have errors. What am I doing wrong?

[/ QUOTE ]

Per128: [ QUOTE ]
I'm up to here with people trying to educate who have no idea what they're talking about and just make the situation worse, like saying that the low and hipoly models shouldn't intersect or some messed up stuff like that.

[/ QUOTE ]
/images/graemlins/smile.gif
Please show some examples of this problem. The rays sample angles, regardless of where they are in space. Again I see that some ray-path illustrations would be extremely helpful. I’ll see about getting around to that, if anyone doesn’t beat me to it. Like I said earlier though, I do believe the ppt in my tutorials section should have some relevant stuff there

Eric: I've already set and stated the intention of this thread. Now, on you telling me to relax, that's childish. I wrote that post during a get-together with my family, seeing our english cocker spaniel for the first time in long, enjoying delicious food and generally having a very pleasant time, and I was nothing if not relaxed. This thread is about discussing topics related to normal mapping, not psychoanalysis, my friend. If someone says something you don't agree with, discuss it, dismiss it, refute it, ignore it, but leave the little quips. I'm motivated to help people here, but not if someone is going to try to start unpleasantries.

To add a couple of suggestions to what MoP is touching on: I make a routine out of disabling the automatic cage update after adding a projection modifier. It's very slow and very useless. The shading thing is a good tip. All in all though I have to say that I try to use ray length setup whenever possible instead of the cage. Keep in mind that the ray length value in the render-to-texture dialog actually doesnt consider decimal point accuracy, so you won't be able to get sub 1-unit rays out of it. That's true for max8 at least.

bounchfx and rick: Good suggestions indeed, just a matter of waiting until we've taken this thread as far as it can be reasonably expected to go.

[monkeyboy_garth]

Ah, MoP, you're a legend, thanks heaps!

Per128: No worries mate - thanks for elaborating.

[StJoris]

Hmm a question on practical application of using tangent space and object space normal maps:
I've read that shader changes cost a lot of resource. So would it be benificial to use object space normal maps on some stuff, like environemental unique parts that don't need to deform. And to use tangent space for tiling and deforming meshes? I bet that object space normal map and tangent space normal map involves a shader change, so that makes it hard to see wether using both is benificial.

[CrazyButcher]

say you have only 2-3 objects being "one type" (tangent or object) and 100s of others being the other type, then it would be indeed a bit of waste to do stuff specifically for those few.

unless say those 2-3 objects are "huge", lots of vertices, lots of pixels.. then the pay-off using the "cheaper" shaders is there again.

engines normally sort by shaders, so all that use the same shader will be rendered after another, to minimize shader changes.

I'd say it is beneficial using both, if you have a good mix of the two kinds. When you think about what is being rendered, a great deal of shader changes are normally happening (say fonts, GUI, characters, particles..) one more or less will not break everything.

[Eric Chadwick]

I said to relax to help make a point, I guess not very well, that this thread is really not useful to the layman as it stands right now. If you're taking that as an offense, then you really do need to relax.

What you need to do, if you really want to help new uninitiated artists, is to condense all the wordiness and contradictions in this thread down into a single clear concise resource.

Rick's offer is great, wikis are perfect for editing and refining. Or you could edit your first post. Or you could use your own site.

If you allow the rest of the thread to continue on its natural course, as an open fairly-focussed discussion, more questions will be asked, and more answers will be contributed. But it ultimately needs to be edited down somewhere.

[Ruz]

Is it true that as you cross the equator,the green channel in your normal maps changes direction:)

[Rick Stirling]

Created a section

http://www.rsart.co.uk/mediawiki/index.php?title=Games_industry_technical_notes


Edit -Server seems to be having bother tonight.

[Eric Chadwick]

Awesome Rick, thanks for doing this. I registered, and was able to add Per's answer to Brice's smoothing question. No problems, the wiki works great so far.

[Mark Dygert]

[ 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...

[IronHawk]

Great thread so far! I am enjoying learning about the technical aspects of normal mapping. These discussions will really be good for me going forward when I need to make adjustments and tweaks since I'll have a better understanding of how everything is working together.

Thanks all.

[Rick Stirling]

Since good normal maps can be useless without good specular maps, I thought I'd throw this in for consideration:

==Falloff/Glossiness==
The falloff or glossiness describes how tight or wide the specular highlight it, and works in conjunction with the intensity to describe the material. They are especially useful when you are using 1 texture to describe multiple material types, like a character model for example.

A wet eyeball has a tight (and high intensity) highlight, whereas denim will have a wide and dull highlight.

Falloff maps are usually grayscale, with white being a tiny sharp highlight and black being a wide soft highlight.


I've got a 50 or 60 page partially written book stagnating on my hard disk, so I may as well pull some useful information out of it.

[Eric Chadwick]

Bring it on!

I wonder if someone could talk about integration of the normalmap raycaster into their own game engine, exporting the tangent bases (stored in the verts at casting time) out to your game format. How are people doing this, and with which raycaster? Any problems getting it to work?

[fritz]

i honestly think this thread is MEGA informative. but at the same time i totally agree w/eric. if this is going to help "noobs", then peeps popping in need to think about what they are saying and lay down a description at the same time.

as far as noob stuff goes i think it's appropriate to lay down things such as this:

1) the advantages and disadvantages of using a cage.
2) preparing a mesh for normal mapping ie: use of bevels,
overlapping problems, how to lowpoly keeping the
highpoly in mind for bake.
3) how to use the nvidia filter and using photoshop in
general with your normal maps(very important i think).
4) what the "other" progs out there do for your normal
mapping tidbits. "other" progs such as: xnormal,
crazybump, etc.
5) how to normal map something fast for beginners and not
be consumed with some overwhelming thoughts on how
"challenging" it is to generate normal maps.
5a) AND SOME WAY TO LET PEEPS KNOW IT'S NOT THAT SCARY! i
i know lots of peeps that struggle with normals and
think it's the end of the world.
6) and how to not drink too much two-hearted ale. cause
that beer is dangerous.

you know....i think it's about time we also had a thread like this that deals w/all facets of next(this) gen map generation. but...not here.

[D4V1DC]

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.

[CrazyButcher]

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.

[bearkub]

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...

[Eric Chadwick]

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.

[IronHawk]

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

[achmedthesnake]

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.

[emerge]

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

this is the map
http://img510.imageshack.us/img510/6996/normalsmapnb4.th.jpg (http://img510.imageshack.us/my.php?image=normalsmapnb4.jpg)

here's how it turns out
http://img451.imageshack.us/img451/4724/normal3cv1.th.png (http://img451.imageshack.us/my.php?image=normal3cv1.png)
http://img257.imageshack.us/img257/4852/normal2pc6.th.png (http://img257.imageshack.us/my.php?image=normal2pc6.png)

wires
http://img510.imageshack.us/img510/2085/wires1ob0.th.png (http://img510.imageshack.us/my.php?image=wires1ob0.png)
http://img510.imageshack.us/img510/254/wires2du8.th.png (http://img510.imageshack.us/my.php?image=wires2du8.png)

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. /images/graemlins/frown.gif

[Eric Chadwick]

[ 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/showthreaded.php?Cat=0&Number=207639&an=&page=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 (http://developer.nvidia.com/object/photoshop_dds_plugins.html) for Photoshop.

[JordanW]

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.

[MoP]

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.

[EarthQuake]

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.

[achmedthesnake]

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?

[adam]

[ 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.

[Joshua Stubbles]

[ 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.

[adam]

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>

[Jesse Moody]

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.

[CrazyButcher]

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.

[Sage]

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. /images/graemlins/wink.gif 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. /images/graemlins/smile.gif 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

[EarthQuake]

[ 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.

[adam]

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?

[CrazyButcher]

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.

[EarthQuake]

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

[adam]

Anyone mind explaining these..?


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

[Ghostscape]

[ 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.

[IronHawk]

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.

[Ganemi]

So...if I have this straight, adding more images to a material file (.mtr for d3) causes more drawcalls and passes that the engine has to make when rendering the model. So when an engine like doom 3 separates height maps and normal maps, it is essentially making the high detail texture work easier for the artist, but making the engine strain itself more by having it call on 1.33 times as many textures per model, and having to calculate/merge the height into the normal at render time.

Did I get that right?

Would it cost less to simply use the Nvidia plugin?

[EarthQuake]

[ QUOTE ]
So...if I have this straight, adding more images to a material file (.mtr for d3) causes more drawcalls and passes that the engine has to make when rendering the model. So when an engine like doom 3 separates height maps and normal maps, it is essentially making the high detail texture work easier for the artist, but making the engine strain itself more by having it call on 1.33 times as many textures per model, and having to calculate/merge the height into the normal at render time.

Did I get that right?

Would it cost less to simply use the Nvidia plugin?

[/ QUOTE ]

Yes more draw calls are worse, but no, thats not how d3 handles it. It combines these maps at *level* load, only having to do this once.

[Eric Chadwick]

Here's an old summary, I'll try to update it.

http://www.ericchadwick.com/examples/images/normalmap_worldspace.jpg
World-space normal map
1. Rainbow colors.
2. Object cannot rotate from original orientation that the normal map was created from nor can the vertices be deformed, otherwise shading is wrong.
3. Usually only a single-use bitmap, not easy to tile. When tiling it, the surface must be flat.
4. Can only use for completely-static game elements (buildings, etc.). Surface must face same direction that it was when the normalmap cast.
5. Fastest computation time.
6. Almost never used any more. Local-space is nearly as fast to render, but doesn't require World-space's static orientation.

http://www.ericchadwick.com/examples/images/normalmap_worldspace.jpg
Local-space normal map (also called Object-space)
1. Same map as World-space, just uses slightly different game code.
2. Object can rotate away from original orientation, but cannot deform. Can only rotate the object in the game editor, not in another 3D program before importing it. The game has to store the orientation difference so it can shade the surface correctly.
3. Same single-use/tiling issues as World-space.
4. Good for rotatable game elements (doors, vehicles, bridges, etc.).
5. Next-fastest computation time.
6. Used often, whenever a surface isn't being deformed. Environment props, building pieces, etc.

http://www.ericchadwick.com/examples/images/normalmap_tangentspace.jpg
Tangent-space normal map
1. Different bitmap style, predominantly-blue base color.
2. Object can rotate and deform.
3. Easy to re-use texture for tiling purposes.
4. Good for deforming meshes (characters, water, flags, etc.)
5. Slowest computation time (but not by much).
7. Used the most often, since it is the most flexible format.


I'll edit this with whatever people want to add, corrections/refinements/additions/etc. Hopefully this can go into the Polycount wiki someday.

[Rob Galanakis]

This post is inference, so please tell me if I'm wrong:

Generally you'd want to store a heightmap or any greyscale map in an alpha channel, which would actually not add to draw calls (since you are only calling one texture and then using the channels differently in the pixel shader).

Regardless, I never actually understood the point of a bumpmap in addition to a normal map.

[Eric Chadwick]

[ QUOTE ]
World-space maps:
-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
...
Object-space map:
-Object can be 1 smoothing group because the hard-edge info is collected in the normal map. Can someone elaborate on this for me? Is this correct?.

[/ QUOTE ]
I never use smoothing groups for normalmapping. The game mesh is always a single smoothing group. Hard edges break the normals along the edge, which can cause normalmap-casting errors (each normal sees a different part of the high-res mesh).

Smoothing groups can only make an extremely-hard edge, something rarely seen in the real world. Most edges have some roundness, which can reflect the specularity nicely.

I use edge loops instead of smoothing groups, as IronHawk described (http://boards.polycount.net/showpost.php?p=729555&postcount=100). Same transform cost as smoothing groups, without the downside.

If you change the UV layout you should re-cast a tangent-space normalmap, because rotating UV islands will cause the existing tangent space to become invalid.

[ QUOTE ]
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?

[/ QUOTE ]Identical. Normal info is not stored in the vertices at all for World-/Local-space maps (although the normals are used when casting the normalmap itself, to cast the high-poly normals into the low-poly UVs).

The only real difference between world- and local-space is that the game has to store a rotation offset for the local-space material, and use that at render time to transform the light vector from world-space down into the local rotation angle that the mesh is using. If using a world-space material, no translation needed.

[Eric Chadwick]

[ QUOTE ]
Generally you'd want to store a heightmap or any greyscale map in an alpha channel, which would actually not add to draw calls (since you are only calling one texture and then using the channels differently in the pixel shader).

Regardless, I never actually understood the point of a bumpmap in addition to a normal map.

[/ QUOTE ]Correct, no additional draw call, since it is reusing the same bitmap asset. Some games go so far as to use each of the four channels (red,green,blue,alpha) for four different grayscale-type effects (specular power, heightmap, shadowmap, etc.).

I haven't used this type of heightmap/normalmap combo, but it sounds like the heightmap is used as a detail map... tiled across the surface and faded in when you get close so you see high-frequency bumpage instead of a blurry mess.

You could also use, as we do, the alpha for parallax mapping's heightmap. RGB normalmap for the main detailed bumpage, Alpha heightmap for the larger/softer parallax offset (using a high-frequency bitmap for parallax looks horrible).

[Ganemi]

[ QUOTE ]
Since good normal maps can be useless without good specular maps, I thought I'd throw this in for consideration:

==Falloff/Glossiness==
The falloff or glossiness describes how tight or wide the specular highlight it, and works in conjunction with the intensity to describe the material. They are especially useful when you are using 1 texture to describe multiple material types, like a character model for example.

A wet eyeball has a tight (and high intensity) highlight, whereas denim will have a wide and dull highlight.

Falloff maps are usually grayscale, with white being a tiny sharp highlight and black being a wide soft highlight.


I've got a 50 or 60 page partially written book stagnating on my hard disk, so I may as well pull some useful information out of it.

[/ QUOTE ]Dude, do you know how to implement this knowledge in, say, the Doom3/Quake 4 engine? I noticed this fall off graph in bodypaint, but I never considered that it could possibly be used in game.

Is there any way to like...describe how wide/narrow and hard/soft of a range the specular area of an object will be lit in engine through materials/shaders?

[Rob Galanakis]

[ QUOTE ]
Correct, no additional draw call, since it is reusing the same bitmap asset. Some games go so far as to use each of the four channels (red,green,blue,alpha) for four different grayscale-type effects (specular power, heightmap, shadowmap, etc.)

[/ QUOTE ]
Ha, you should check out my skin shaders... I have maps like that, one is RGB and masks the different types of pores on a micronormal map, another is an RGB that is sss level/ambient occlusion/specular level. As long as your pipeline is strong, and your reasoning makes sense, I don't think there's a problem working that way... can be quite efficient until it gets too confusing.

[ QUOTE ]
I haven't used this type of heightmap/normalmap combo, but it sounds like the heightmap is used as a detail map... tiled across the surface and faded in when you get close so you see high-frequency bumpage instead of a blurry mess.

[/ QUOTE ]
Well the article I saw on a D3 or Q4 asset had the bump map as literally a bump map... but it may still only be used close up to show pore and vein detail, etc., stuff that could get messy or grainy further away, not sure.

[ QUOTE ]
You could also use, as we do, the alpha for parallax mapping's heightmap. RGB normalmap for the main detailed bumpage, Alpha heightmap for the larger/softer parallax offset (using a high-frequency bitmap for parallax looks horrible).

[/ QUOTE ]
Yeah's that generally what I do... I have a pretty good pipeline when I work, that if I know the material types (regular, opacity, specular, parallax, etc), I know what goes where... for example, I always put my heightmaps with normal maps, and opacity with diffuse maps, reflection level goes with a specular map, etc.

[ QUOTE ]
Dude, do you know how to implement this knowledge in, say, the Doom3/Quake 4 engine? I noticed this fall off graph in bodypaint, but I never considered that it could possibly be used in game.

Is there any way to like...describe how wide/narrow and hard/soft of a range the specular area of an object will be lit in engine through materials/shaders?

[/ QUOTE ]
Falloff just refers to any gradient controlled exponentially... falloff in bodypaint, zbrush, etc., is just the brush profile. You can read towards the end of my Shaders Overview article from http://www.robg3d.com/tutorials_and_articles.html for exactly what falloff does in terms of a specular highlight.

[EarthQuake]

[ QUOTE ]
[ QUOTE ]
Since good normal maps can be useless without good specular maps, I thought I'd throw this in for consideration:

==Falloff/Glossiness==
The falloff or glossiness describes how tight or wide the specular highlight it, and works in conjunction with the intensity to describe the material. They are especially useful when you are using 1 texture to describe multiple material types, like a character model for example.

A wet eyeball has a tight (and high intensity) highlight, whereas denim will have a wide and dull highlight.

Falloff maps are usually grayscale, with white being a tiny sharp highlight and black being a wide soft highlight.


I've got a 50 or 60 page partially written book stagnating on my hard disk, so I may as well pull some useful information out of it.

[/ QUOTE ]Dude, do you know how to implement this knowledge in, say, the Doom3/Quake 4 engine? I noticed this fall off graph in bodypaint, but I never considered that it could possibly be used in game.

Is there any way to like...describe how wide/narrow and hard/soft of a range the specular area of an object will be lit in engine through materials/shaders?

[/ QUOTE ]

One of the biggest fuckups of this engine imo, pretty much every asset is forced to use the same shader, with the same glossiness. So no matter what you do everything just ends up looking plastic. You can only set the value of the spec, not the glossiness.

[Ganemi]

[ QUOTE ]
[ QUOTE ]
[ QUOTE ]
Since good normal maps can be useless without good specular maps, I thought I'd throw this in for consideration:

==Falloff/Glossiness==
The falloff or glossiness describes how tight or wide the specular highlight it, and works in conjunction with the intensity to describe the material. They are especially useful when you are using 1 texture to describe multiple material types, like a character model for example.

A wet eyeball has a tight (and high intensity) highlight, whereas denim will have a wide and dull highlight.

Falloff maps are usually grayscale, with white being a tiny sharp highlight and black being a wide soft highlight.

I've got a 50 or 60 page partially written book stagnating on my hard disk, so I may as well pull some useful information out of it.

[/ QUOTE ]Dude, do you know how to implement this knowledge in, say, the Doom3/Quake 4 engine? I noticed this fall off graph in bodypaint, but I never considered that it could possibly be used in game.

Is there any way to like...describe how wide/narrow and hard/soft of a range the specular area of an object will be lit in engine through materials/shaders?

[/ QUOTE ]

One of the biggest fuckups of this engine imo, pretty much every asset is forced to use the same shader, with the same glossiness. So no matter what you do everything just ends up looking plastic. You can only set the value of the spec, not the glossiness.

[/ QUOTE ]

http://img338.imageshack.us/img338/5551/jathrs1.th.jpg (http://img338.imageshack.us/my.php?image=jathrs1.jpg)

After reading that dude's post I realized what that graph in bodypaint was, and how it worked.

So you're saying there's no possible way to implement that kind of thing in the Quake 4 engine? That would really suck.

[EarthQuake]

Not unless someone has made some sort of mod for it(read: writen a different material shader), perhaps the ET:QW engine has that sort of functionality, but i doubt it looking at the screenshots.

[Ganemi]

I'm thinking about making a post on ESR about it, since problems with Quake 4 usually get fixed if complained about on that site.

Quake 4 is the only engine I've gotten a model to work in game before, but the first thing I really wondered about it was how I could get the specular to be light, dull, and flow throughout much of the model under most lighting situations. I guess if a newb could bring up that question it is sort of a problem.

[Rick Stirling]

Yup, the shader must support the maps. The thing is, you don't necessarily need a map for this, this is only needed when you have multiple material types on the same texture sheet, e.g. characters.

We've used the alpha channel of the spec map as a falloff map, where black = transparent = wide + dull, white = opaque = tight and bright. I think our value range is 0 to 1, not 0 to 255, as it acts as a multiplier to the falloff value we specify.

[Ganemi]

So, other games don't use spec maps? They just use shaders for each object? Could there be a situation where you wanted to have every part of an object be lit the same way, but within a very tight margin? If you made it a certain shade of grey, Quake 4 would make the width/intensity of the spec the same all across the model, I think. Any way around that?

[Rick Stirling]

Yes, other games use spec maps. Other games use spec map AND gloss maps.

If you have a material however that has one level of glossiness across the entire surface, you don't necessarily then need a gloss map, you can just use the glossiness level if you engine supports it.

In the two engines that I have worked with, we've had 2 settings

Numerical value
Map

The numerical value is a baseline mulitplier form bump/normal/alpha/spec/gloss.

The map is a per pixel controller.

[CrazyButcher]

about RGB=normal, Alpha=height/detail. This is not to save drawcalls, but space &amp; texture fetch mostly. Since GeForce3 we can have 4 textures at the same time with a single drawcall. Modern cards can have up to 16 textures they can sample from. (the less the better of course). Be aware that new drawcall = multipass, doesnt allow you to use previous pass results other than color output. So in most cases you need a couple of textures bound the same time to get your shader to work (typically three, diffuse, normal,spec). There is a huge variation how engines deal with lighting in terms of passes needed. Some might do all stuff in a single pass with only few lights affecting, some may do additive passes for each light, and then mix color at the end on top. Ideally the engine you work with should tell you the extra passes in a scene.

we are in the age of programmable gpus, so be very careful to not think that stuff has to be "x's engines" way. I think part of the confusion among newcomers to this topic is, that they think there is only few ways of doing things, but there are multiple solutions, and each engine/game might do things slightly different to maximize efficiency for their needs. So one might allow per-pixel glossiness, another might not. This doesnt mean it's illegal for all, or cannot be later added to the same engine.

[poopinmymouth]

On a single object, it's better to use a map for glossiness, then several cloned shaders applied per face with the values changed. Using a map is only one draw call, using multiple shaders with different values is however many draw calls you separate the object into.

http://www.mr-chompers.com/images/poop.gif (http://www.poopinmymouth.com)

[Rick Stirling]

[ QUOTE ]
On a single object, it's better to use a map for glossiness, then several cloned shaders applied per face with the values changed. Using a map is only one draw call, using multiple shaders with different values is however many draw calls you separate the object into.



[/ QUOTE ]

Oh yes, don't split your model into separate objects, or clone shaders, just use a gloss map. You only get away with it when it is one object with one level of gloss - like a simple prop (brick, ball).

[EarthQuake]

Our engine uses a material setting for glossiness, because of the way our lighting system works(HDR environment lit) we cant "blend" between multiple hdr cubemaps on one object in realtime, so if we have multiple types per mesh we just use a different mesh chunk with a different shader. But most engines will let you use a seperate map for this.

[Eric Chadwick]

Another way I've seen multi-cubemap per-pixel glossiness is for the shader to call different mip levels of cubemap... the white pixels of the bitmap pull in the top mip (sharp highlights), gray pixels get middle mips (softer reflection), and black pixels get the lower mips (super-blurry).

Can be expensive though, depending on the hardware. IIRC someone told me it's multiple passes on all but a couple consumer cards.

Has anybody done this? It sounds cool.

Also requires the cubemap mips to be carefully processed to avoid adding seams between the 6 faces. Cool tool from ATI...
http://ati.amd.com/developer/cubemapgen/index.html

This is a really cool thread, love hearing all the tidbits.

[Rick Stirling]

I've also worked before with tech where we baked the glossiness into the vertex illumination channel of the model itself. It's obviously not as accurate as a map, but it was fine for environments where each 'material' was already bounded by edges to begin with.

I have no idea why we tried it that way.

[EarthQuake]

I think we do that essentially, but not using different levels per material. Our "duller" spec cube maps are just lower-res hdr goodness, while the "Sharper" ones are just higher-res.

Looking at that site, that seems to be EXACTLY what we do. And even with only one setting per material, you can in most cases get much better results than your standard pointlighting setup, no matter how complicated the glossiness is in the shader. AFAIK its actually quite fast too, atleast on decent cards it seems like barely any hit at all(gf 6 series) compared to a more traditional lighting setup.

[monkeyscience]

Dull spec cubes aren't exactly low res versions of shiny ones but close enough. Lowest spec is equivalent to a diffuse cube, which is pretty blurry. You could use low mip levels for dull spec fairly safely I'd think. I wouldn't go down to 1x1 to store anything. This is a really cool idea actually, and if you're computing your own spec cubes at the right resolutions, the seam thing won't be a problem either. I want to play with this now!

[mikebart]

Does doom3/quake4 use object space normalmaps? I remember you saying something about that a while ago EQ, I cant find a single normalmap in the game data that looks like an object space normalmap though, can someone confirm that? I could really use them for what im working on atm.

[EarthQuake]

[ QUOTE ]
Does doom3/quake4 use object space normalmaps? I remember you saying something about that a while ago EQ, I cant find a single normalmap in the game data that looks like an object space normalmap though, can someone confirm that? I could really use them for what im working on atm.

[/ QUOTE ]

No sir, but our engine can use either tangent or object space. So thats most likely what i was talking about.

[mikebart]

ah well, cheers anyway.

btw; this is a great thread guys, very helpful.

[Ganemi]

Does anyone know how to edit the direction of vertex normals?
I was trying to make a normal map for a telephone pole, but I think that by what I read, the top of it has normals pointing up and out by a 45 degree angle, and whenever Max makes a normal map, the map looks round. : [ It's pretty annoying.

[Eric Chadwick]

edit... oops, I misread the post. Professor420 has it right. I thought you were talking about what Ben shows at the bottom of this page:
http://www.poopinmymouth.com/tutorial/normal_workflow_2.htm

[Rob Galanakis]

Bevel the top edge of the telephone pole cylinder, to help you.

[JordanW]

Ganemi: An easy way to think about this problem/solution is that if you look at your low poly mesh without any normal map on it and it looks really "soft" then your normal map will look round or soft, the reason for this is the normal map is having to counteract that softness in the low poly mesh.

When you chamfer an edge it's helping make those LP normals less soft. The reason I went ahead and gave the above explanation is because there'll be situations where chamfering doesn't really help and so it's good to know what to look for when trying to fix that softness.

[RAMOS]

Hello Normal map Masters,
I had a workflow question, My normal workflow when making my Hi poly source consists of using a copy of my lo poly model in Max and adding Nurms from the edit poly-Subdivision surfaces panel and editing the cage. Well I'm working on a very square'ish piece Here (http://www.esr3d.com/Extruded Window Piece.jpg) . If I use the same workflow I have to add all these edges or tessellate the crap out of it to get it to be square. So my question is Does my Hi-poly source have to be a "Smoothed" object in order to get the best results? Or can I just keep the low poly copy w/o "smooth" and just add my detail as needed?

Thanks in Advance

[FatAssasin]

Just add the detail you need. Creating a normal map doesn't automatically mean that you need a super high-res mesh, it just means that you need a mesh with details in it that would be too expensive to add in the low-res mesh. The only reason you'd need to up-res the lower cage using Turbosmooth or whatever, is if you did want the more rounded corners you'd get from that. But then you would need to chamfer the edges like you mentioned.

And one thing to watch out for when dupping the low-res mesh to create your high-res version is coincindent faces (faces that lie right on top of each other). It'll mess up your normal rip, so just add a push modifier to the high-res mesh and set it to .001 or something really small just to move the faces on the two models away from each other.

[FatAssasin]

I've been meaning to post this, but keep getting sidetracked. Here's a script for you maxScript savy folks that will pop selected uv's into and out of the 0-1 box by exactly 1 unit. So you can select your mirrored uv's that you want to move away for normal ripping purposes, run the script, and they will pop over to the right by 1 unit. Run it again and they'll pop back to the left.

It's a macroscript so you can make a hotkey or quad menu item out of it.

<font class="small">Code:</font><hr /><pre>macroScript toggleUVOffset
category:"HaywoodTools"
tooltip:"Toggle UV Offset"
buttonText:"toggleUVOffset"
(
-- get the uvwrap modifier
uvMod = modPanel.getCurrentObject()
-- make sure it's really an unwrap mod
if classOf uvMod == unwrap_uvw then
(
-- get snap state
snap = uvMod.getSnap()
gSnap = uvMod.getGridSnap()
-- turn off snap
if snap do uvMod.setSnap false
if gSnap do uvMod.setGridSnap false
-- select the associated verts if in face or edge mode
case subObjectLevel of
(
3: uvMod.faceToVertSelect()
2: uvMod.edgeToVertSelect()
)
-- set the offset amount
val = 1
-- if the first vert in the array is outside of the UV box, change the offset amount to -1
-- this makes this script a toggle to move uv's in and out of the box
selVerts = (uvMod.getSelectedVertices()) as array
if (uvMod.getVertexPosition sliderTime selVerts[1]).x &gt; 1 then val = -1
-- offset the verts
uvMod.moveSelectedVertices [val,0,0]
-- set the snap back to what it was
if snap do uvMod.setSnap snap
if gSnap do uvMod.setGridSnap gSnap
)
else
(
messagebox "You need to have an Unwrap UVW modifier selected"
)
)</pre><hr />

[Eric Chadwick]

Nice one James.

But I just leave the mirrored bits offset +1, all the way through to export. I'm curious if anyone is required to un-offset before export, like they need to keep all their bits inside the 0-1 box? Maybe there's a precision issue or something.

[FatAssasin]

Yeah, I just included the option for the hell of it. I also leave the uv's out of the box. But it's still a nice little speed boost when doing a lot of uv work to just hit a hotkey and pop your uv's over +1.

[EarthQuake]

[ QUOTE ]
Nice one James.

But I just leave the mirrored bits offset +1, all the way through to export. I'm curious if anyone is required to un-offset before export, like they need to keep all their bits inside the 0-1 box? Maybe there's a precision issue or something.

[/ QUOTE ]

I could see posibly compressing the uv data and needing it to be 0-1, or not wanting to use a floating point number on it as reason for this, but really i doubt you'de see much if any performance saving from it.

[RAMOS]

Hey just a quick Thanks to -Fat Assasin- for the advice, I appreciate it I will take your expertise advice and thanks to the polycount community. That advice is worth alot to "us" trying to better our selves in this industry. Thanks

[rooster]

sorry if this has been answered I didnt find it skim reading through.. the moving by 1 unit uv stuff, how do you do that in maya? the type in just moves all my uvs to that position so they're all in a squished line

[Eric Chadwick]

I'm not a Maya guy, but I bet someone's written a MEL script for it.

I have a question... are there any tricks for tiling a tangentspace normalmap across a character and avoiding seams?

AFAIK a tiled map can't really use the tangent/bitangent data that the regular un-tiled character map uses, because the UVs are quite different.

I have this character with a squirming-worms animated normalmap tiled across the body, using a second UV and being masked out to certain areas. But where it tiles across the UV seams of the regular normalmap it shows lighting discontinuities.

My guess is people don't run into this problem. In most cases tiled tangentspace normalmaps are only used for environment meshes, where the UV is mostly contiguous, unlike the typical fragmented character UV.

Or maybe I just need to use the same UV as the regular normalmap, tiling it in the shader?

[rube]

no need for a script for that one. it's in the UV editor already... the last button on the top right will switch to relative translations... then just push w and you can type a number in the box to move all the selected uvs.. also works with rotate and scale

[rooster]

ace! howd I miss that button /images/graemlins/tongue.gif cheers

[Brice Vandemoortele]

Great Thx /images/graemlins/smile.gif I miss that button too ^^
I used the edit mesh &gt; transform tool (former move component) to do it. I allows more complex operation tough, like uniform scale, setting a pivot etc /images/graemlins/smile.gif

[foreverendering]

Firstly I'll just talk about what I've observed.

Normal map colors differ dependant on the orientation of your UV shells. I ran a test where I baked a normal map off a hi poly boot, then rotated the UV's of the lowpoly mesh by 15 degree increments (15, 30, 45, 60, 75, 90) and then compared the maps. Each one had a slightly different bake. By the time I had reached the full 90 degree rotation, I had achieved a complete inversion of the Red and Green channels of the maps. (Swapping the R for the G and the G for the R in photoshop produced two identically colored normal maps).

So, now to my problem :

If I were to UV a character, bake all the normal maps, paint the diffuse and specular maps, and then decide AFTER the work is completed to change my UV layout, I can't simply re-layout the UV's and render to texture from the old maps to my new UV's. It will work for the diffuse and specular maps, but my normal maps will not be correct.

My only work arounds (at the moment):

For one thing, I can limit my re-UVing to mirrorX or mirrorY per UV shell (I can invert the red or green channels of that shell after the rebake), or rotating in 90 degree increments (I can swap out the Red and Green channels), but it's limiting to re layout my UV's in that manner. Plus it's kind of a pain to sit there editing channels per UV shell then checking everything to make sure it's correct.

Or, I can do a brand new bake from the high-res, which I'd like to avoid in this particular case because the high res object is really, really high. The bake was bad enough the first time.

The solution?

I dunno - anyone have any ideas? I wish there was a script or something I could run that would automatically edit the channels accordingly if i rotated my UV's to a new layout and rebaked from the old normal map. Has anyone heard of anything like that?

Any info would be welcomed..

[EarthQuake]

I think rebaking is always the best solution in that situation, i mean really, what if you happen to scale a certain section up? then you absolutely need to rebake.... How high res are you talking, and waht are you using to generate your maps? Maybe you can find something that is less of a pain to use on super-highres stuff.

[foreverendering]

[ QUOTE ]
i mean really, what if you happen to scale a certain section up?

[/ QUOTE ]

I normally create my source textures at a higher res than my final, published textures (ie - 2048x2048 for what ends up being a 1024x1024), so I can scale up and rebake from the source textures if necessary.

Obviously I'm leery about doing this kind of thing cause I lose all my PSD layers, but that's going outside the realm of the question. I probably will end up going the route of a new bake.

Btw, I'm generating the normal maps in Max9 (along with ambient occlusion)

[IronHawk]

Seems like everything even cardboard box gets a normal map these days. Are there situations where a normal map would not be used and would just be a waste?

Since the normal map determines the shading and vertex shading can be ass it seems like a map would be used for most everything in current/next gen games.

[Eric Chadwick]

@ foreverendering, you can't just re-bake a normalmap like a diffuse, you need the tangents/bitangents if you're using tangent-space normalmaps. AFAIK, these are only created when you bake a normalmap.

I'm in the process of adding this info to the CGWiki. Hopefully I can put some more time into it, or someone else can correct flaws.
http://wiki.cgsociety.org/index.php/Normal_Bump#Tangents_and_Bitangents

[Eric Chadwick]

Thinking this through some more, I think you could workaround this by doing a "fake" re-bake of the normalmap with your new UVs, using whatever mesh to bake from, and just ignoring the normalmap it spits out. Render To Texture should recreate your tangents &amp; bitangents to match your new UVs, and if you rotated/inverted your original normalmap correctly, it should be lit correctly by the new tangents. I think. You still need to make sure your renderer (realtime or offline) exports/reads Max's RTT-generated tangents.

@ IronHawk, whenever I can get away with not using bump or specular or diffuse or any other ingredient, I'm generally better off because ingredients all tend to have a cost, either in performance or in memory or HD space or production time, etc.

If shaders are built right according to the gaming hardware, many ingredients can be used for "free" without performance cost (fillrate, and hence framerate). But I'm still wasting production time, if I never see the effect when I play the game.

Some examples... glows, muzzle flashes, most particle effects, neon signs, UI, cubemaps.

[IronHawk]

Thanks Eric.

[foreverendering]

Eric,

Interesting!

I was originally using RenderToTexture with the normal map in the diffuse slot, and rendering a new diffuse map. So basically it was just sampling the colors of the map and adjusting their placement to the new locations per the new UV map. (Obviously wrong).

But I just tried it with the normal map applied to the original model (the NM set in the normal bump channel) and increased the multiplier by 3.5 (1.0 was making the normal map really muted). I also had to check Swap X for some reason, but the end result is it was baking out a new normal map with the correct RGB values based on the UV rotation!

Well, it seems correct from the first test anyway. I only tested it on a 90 degree rotation (which I verified by inverting the R and G channels on the original), and a 25 degree rotation which also produced a differently colored normal map that I haven't verified yet... Need to test a clean bake from the hi res with a 25 degree rotation as well.

Going to run a few more tests but it looks like this might be the solution I was looking for (or a really big tease)

[Eric Chadwick]

Quick way to test... apply the new normalmap to your low-res mesh (the one you selected before invoking RTT) using a Standard material and a Normal Bump, then render with Max's scanline. If the lighting is good, then it worked.

[StJoris]

[ QUOTE ]
increased the multiplier by 3.5 (1.0 was making the normal map really muted).

[/ QUOTE ]

I don't know much about the rest, but I suppose you needed to multiply because the spinner before bump is by default set to 30 instead of 100. If you make that spinner 100, it will be fine to leave the multiplier at 1.0 I think. I'm sorry if this was not the case, just a possibility.

[Jeremy Lindstrom]

Here's a quick suggestion, is there any tuts out there, I know chris holden had a couple, and poop has one for max is it as simple as those though?

Here's my dilemma.

My model: pay no attention to the armor, i removed it.
http://www.jeremytoons.com/images/stories/3d/gunslinger2.jpg

The normal: (looks great in zbrush)
http://www.jeremytoons.com/images/badnormal2.jpg (exported out of zbrush)

On Model in Maya:
http://www.jeremytoons.com/images/badnormal.jpg

I'm thinking maybe possibly a tutorial on something a little easier then a character normal mapping might be easier to get a handle on.

Isn't the biggest problem with normal maps especially for noobs is their UV layouts? Or in my case /images/graemlins/laugh.gif

Any help would be greatly appreciated. I got how I want it in zbrush, I just can't make the jump to my lowpoly. :/

Also one of the reasons you can still see some poly action in the normal is because when I imported it into zbrush, I didn't smooth it when I uprezzed because it was rounding out my armor. /images/graemlins/laugh.gif

[Rob Galanakis]

The mesh piece at the seam is flipped. You should check your UV's with a checker map with numbers or letters so they are all reading correctly to make sure you don't have "flipped" UV's accidentally.

You can also invert the Red channel for that one leg piece of the map in Photoshop. The same for any piece that is "flipped" incorrectly.

[Noren]

Rendering a new normalmap with new uv's from the original normalmapped lowpoly should not be a problem at all. Besides a slightly blurry texture, that is. However you should leave filtering on or you will get some slight warping in your texture.
It should not be neccessary to change the bump or normalmap amount/output.
As far as I recall, the percent spinner of the bump-slot does nothing for the normalmap.

[fr0gg1e]

Hello,

Something I have in the back of my head for a while...how would you do to bake really complex geometry? here is a (lame) example...sorry bout that, 2 mins job to illustrate the point)
click me (http://img370.imageshack.us/my.php?image=blehrb9.jpg)
Imagine the blue stuff to be wires, loads of wires...how would anyone do a lowpoly cage for this object...also imagine the pipes areall bended around the main big tube...this way, mapping the object would be a pain. I guess doing a separated object for the pipes would be worth it (rather than try to map something with lots of overlapping 2edges)...but for the wires? Would you guys use 2 baking passes and composite in PS? Also, what happens if the wires enter the boxes and I do separate objects for those boxes?
Anyway if anyone have a good solution for that... would I rather conform all my wires to the main object to not allow volume (even worse if the wires are passing above the boxes and stuff).

That takes me to the 2nd part of my question I always have problems with baking round objects. It get deformed whatever I do to compensate it. Would anyone have any tips to not have any wave effect other than playing with the cage, as Poop notified in his great tutorial (wich work on simple objects but not on objects with weird profiles...not sure if I'm clear)

Cheers!

[Eric Chadwick]

Hi fr0gg1e. Actually this situation is not very complex, it's easy to bake.

Your low-res geometry would basically be a cylinder, best with some small extrusions for the biggest items, to help the silhouette of the model. Here's a quickie paintover.
http://www.ericchadwick.com/examples/images/fr0gg1e_paintover.jpg

The normalmap baker (Xnormal, Maya, 3ds Max, etc.) can easily solve the intersections/overlaps of the wires... all they do is basically choose the outer-most surface for each pixel, so only the top view of the wires would be baked down.

If you wanted the wires to "float" over the surface of the cylinder to get some parallax, you could add an extra floating flat plane for the wires themselves, and bake them separately into that surface. But that's more than you would usually need.

The curvature problem is a tough one. People usually solve only for the angle that the object is most viewed from, and let the distortion happen from other angles. Or you can add more edges/triangles for that area to reduce the problem. But you can't really get rid of it.

[ChaosEidolon]

Man, this thread is pure gold. Hope it keeps up it's pace.

I have a question that is less technical and more art/pipeline related.

What have you guys found to be the best workflow for intricate mechanical/hard-edged/inorganic surfaces. I have seen some examples of characters with things like armor plating and intricate mechanics done in Zbrush but is this good practice? It seems you can work some magic with the right alphas but the program can only be so precise, so perhaps its better to stick to organics.

The alternative is to use sub-D modeling, which can look great but seems to me (perhaps only because i am admittedly inexperienced with it) that it would take significantly longer to accomplish the same effect, especially if you're talking about very fine detailing.

So in summary, which of these, if any, is the preferred technique? Combination of both perhaps? Is there any other method that I am unaware of?

thanks!

[Sage]

ChaosEidolon subd is pretty quick once you get the hang of it. The only tip I can give you on it is make a cube and try to make indents in it by cutting edges into and get this to go however you want to flow. If you have access to Max you can quickly drag loops with edge constraint on. The benefit of having this one is that you can drag your newly made edge loop to another and when it stops against the other and you let the mouse button go it assumes the exact shape of the edge loop you dragged it to. Then if you can slide the selected edge loop it retains this shape. The benefit of this when it works, is that it makes clean sharp edges where you need them. I'll show an example later. The benefit of learning how to get your edges to flow however you want once smooth is that you'll have no problems when making floating geometry for your high poly.

Alex

[NeoShroomish]

Chaos - My workflow for hard surfaces is to do the subd model in max but don't collapse the modifier, and then use zbrush to add in some micro detail, such as texture and the like. Then extract the low from the subd model without the modifiers, and bake in xnormal.

[Eric Chadwick]

Some good sub-division modeling resources.
http://www.subdivisionmodeling.com/page1.htm
http://www.per128.com/pages_tutorials/index.html

Some good sub-division modeling threads from the past.
http://boards.polycount.net/showflat.php?Cat=0&Number=189524&an=0&page=0&vc=1
http://boards.polycount.net/showflat.php?Cat=0&Number=45506&an=0&page=0&vc=1
http://boards.polycount.net/showflat.php?Cat=0&Number=116294&an=&page=0&vc=1
http://boards.polycount.net/showflat.php?Cat=0&Number=56131&an=&page=0&vc=1

[Joseph Silverman]

Hey, this is a really little question, but:

When working with object/world space normal maps, how can I effectively add heightmap detail? I usually just dump stuff in crazybump and go, but it seems to only support tangent, so...

[Eric Chadwick]

I don't do those types myself, maybe Earthquake or someone else could chime in, but AFAIK you would need to bake the detail map(s) in the same space as your high-res mesh, otherwise you won't get the right gradients.

I would guess that would require mapping the details into the high-res mesh. I can't see how you could extract painted detail independently from modeled detail, since the micro will be world-space-shaded by the macro. Anyhow, there wouldn't be a way to sample it on like you can with Overlaying tangent-space details... Overlay wouldn't work because the base value isn't uniform.

[CrazyButcher]

couldnt you apply a normal map to your lowpoly + add the heightmap stuff as regular bump map in max (combined with the previously rendered normal map) and then rtt the normalmap of the low again ? just thinking out loud

[ChaosEidolon]

Sage, Neo: Nice, thanks guys. getting insight to other people's workflow is a big help.

Eric: Awesome man, thanks. I got a ton reading through those.

I think ive got a pretty good grasp on the concept now. I think one thing that ive taken from this is that you have to have a pretty clear direction of what you want to accomplish when youre working with Sub-Ds. It's somewhat less forgiving to the kind of endless tweaking youre able to do in low-poly. Keeping things simple until you can commit to your basic shapes seems like the way to go (art school 101 all over)

So, planning seems key, or you run the risk of falling into the endless noodling loop.

thanks guys, this stuff is certainly less daunting when you break it all down.

[rooster]

crazybutcher: ive done that, and as far as I could tell the results looked fine- I rendered the initial normal map at a high rez and baked to a lower rez combined with a bump on the same model- the resulting map appeared to have correctly oriented normals (iirc I think I baked to new uvs too)

[EarthQuake]

[ QUOTE ]
Hey, this is a really little question, but:

When working with object/world space normal maps, how can I effectively add heightmap detail? I usually just dump stuff in crazybump and go, but it seems to only support tangent, so...

[/ QUOTE ]

There is no real easy way to do this, we have a util in our model viewer that lets us load a model, and then combine a tangent with a object space map(it needs the model for the orientation of everything)... The results are dependant on a few things, if you take the time to set up smoothing groups on your mesh before you do it works well, otherwise it tends to warp/or oddly wrap things around if blended too much.

[Joseph Silverman]

[ QUOTE ]

There is no real easy way to do this, we have a util in our model viewer that lets us load a model, and then combine a tangent with a object space map(it needs the model for the orientation of everything)... The results are dependant on a few things, if you take the time to set up smoothing groups on your mesh before you do it works well, otherwise it tends to warp/or oddly wrap things around if blended too much.

[/ QUOTE ]

Ack, ok. Thanks for the help.

I guess I'll plan ahead next time, and use floating bits or zbrush or something to add tiny details, if possible. /images/graemlins/smile.gif

[CrazyButcher]

actually my comment on baking with combined pre-rendered normalmap and heightmap was supposed to be an answer to
SupRore.

[rooster]

I know, but it sounded like you hadn't tried it and so I was saying it works.. must have misread /images/graemlins/smile.gif

[CrazyButcher]

nono rooster, you did read it right, and it's good you said it actually works.

[fr0gg1e]

thanks EricChadwick. i finally used Xnormals and it worked almost flawlessly (without a cage tho cause with it it was pooptacular in max) . I m gonna post some screens of the results when i ll be able to...

Edit: as i had some times here is the screenshot (still really a wip thing as i have still lots to do, like exagerating even more the high res details for the normal map edges). Click me too (http://img409.imageshack.us/my.php?image=reaktorvd3.jpg)

[Eric Chadwick]

Hmm, I see the subdivisionmodeling.com link has been hacked. Crashes my browser if I let it. No way to edit the link in my post though. Here's a better link until they fix the wiki...

http://www.subdivisionmodeling.com/page1.htm

[MoP]

Edited it for you, Eric.

[SomberResplendence]

Hello!! I have a question I hope can be answered. I created a high poly and normal map by using Mudbox. I then opened the low poly in Max9, applied the normal, diffuse, and specular map to the low poly to make it look awesome. Yet in our game, we will not be using normal mapping. So I tried to bake all these details down into one simple diffuse map. I seem to be having problems getting my normal map to show details in this diffuse map. Any help would be appreciated!

[Eric Chadwick]

Why not bake lighting into the diffuse then, using the normalmap as bumpage?

[SomberResplendence]

Well our models for our game only use one material and one texture. So we use either jpgs or pngs (for alpha). I'm trying to bake the details from the diffuse, normal, and spec down into one file, except the details from the normal map are not showing. I'm using Max's render to texture dialogue and creating a complete map. I would just like to know why the normal details are not baking out.

[rooster]

hi, i don't have max installed so I can't play around with it.. Im sure what you're wanting to do is possible though. Have you opened up the baked maps? sometimes the render view doesn't actually show you what the map is coming out like

[SomberResplendence]

I have opened them up in Photoshop and saw the diffuse with some lighting, but was lacking the definition of the normal map details. I even tried increasing the bump amount to 500 and saw weird artifacting that seems to be caused by the normals. I can't really play around with it over the weekend, finals are coming up. Any responses by next week would be great. Thanks Polycount!

[Eric Chadwick]

Render each pass separately in RTT (diffuse, specular, lighting), then tweak and combine in Photoshop. Be prepared to do some liberal hand-painting to make things pop.

b1ll (http://benregimbal.com/) has some nice pics on his site, showing step-by-step kick-ass hand-painted lighting. Worth a look. Just one example:
http://www.benregimbal.com/army_kid_stepICON.jpg (http://www.benregimbal.com/army_kid_step.jpg)

[SomberResplendence]

Ok, I guess that's what I'll need to do. Thanks for the help EricChadwick!

[monkeyboy_garth]

Mr Kite (andy nisbet) has a cool photoshop action that takes a normal map and turns it into a b+w map that can be overlaid on a diffuse to add detail. It's a good place to start!

[Eric Chadwick]

Where can I find the action? Seems like Mr Kite has zero posts.

[MoP]

he's called kite (http://boards.polycount.net/showprofile.php?Cat=0&amp;User=2912&amp;page=7&amp;what=showme mbers) on this site

[Eric Chadwick]

Ok, but where's the action file? Guess I don't hang out in P&amp;P enough.

[monkeyboy_garth]

Hey, sorry about that, I found it here:

http://adventuresincommuting.com/stuff/cavmap.atn

Cheerio and thanks again, Mr Kite!

[Eric Chadwick]

Hmm, interesting. Nice trick, might be useful. Thanks for the link.

[Gav]

Somber, this might help out as well...maybe...

http://www.pioroberson.com/tuts/tut_texturing_tricks.htm

[Pedro Amorim]

is there a way to make scracthes in phothsop and overlay them to a object space normal map?
i only know the overlay trick in photoshop to work in tanget maps. any idea?

[Eric Chadwick]

I don't use object-space maps, but I imagine you would have to map the scratches onto the high- or low-poly mesh and bake it out.

You might be able to use a 3d paint program like Body Paint 3D, or any one that lets you paint bump maps "live". Then bake the results into object-space colors.

But combining the layers, I dunno, Overlay trick won't work.

[Rob Galanakis]

Doesn't xNormal have an OS &lt;-&gt; TS converter?

[Sage]

I was wondering about something, in the render to texture in Max for example bi tangents and tangents are calculated from the low poly model and hi using the unwrap to read the the normals correctly when they get baked? Then why do tileable normal maps work on models? It seems to work correctly on any model I have tried and I'm not talking just walls here. I'm wondering how the normal map once generated from the cage mesh works on the final low poly game asset if it's different than the cage mesh that was used to generate the map? I was getting the impression from reading some tutorials that they are dependent on the low poly topology used to create them or does it not matter after the normals get baked? Thanks in advance.

Alex

[Eric Chadwick]

Hi Sage. The UV shells in non-tiled layouts are usually oriented at different angles across the mesh. When you look at a normalmap from a character, you typically see different colors along seams. The normalmap is being twisted for the different orientations of the UV shells.

This requires tangents &amp; bitangents so the lighting can be reoriented (twisted) as it comes into the surface's local space. Then the lighting will look uniform across the normalmapped mesh.

A normalmap grabbed from tilable 0-1 UV layout doesn't have those directional gradients because it uses a uniform direction in tangent space.

Or at least that's how I understand it.

[Sage]

Thanks Eric for the feedback. I read in a book can't remember the name /images/graemlins/frown.gif I think last year, been looking for without any luck, that the less gradients the normal map had the better it would be. The author stated that the closer to blue the normal map the better. So I wondering what you guys thought about that. The book showed how to normal map a gun for a FPS game, if it rings a bell it be nice to know the name of the book.

I did a test with a cylinder here is a screenshot left to right hi res, then cage mesh with 18 sides I believe, and low poly with ten sides. I noticed that at certain angles if I have the cage to compare the low poly model looks a bit wierd. does have more gradients help with this or is having it closer to blue (128,128,256)color better?

http://apsentertainment.com/previews/nmex01.jpg


Alex

[Eric Chadwick]

It's always better to reduce those gradients when you can (mostly by using more verts/bevels) because the tangent space can only do so much to correct the lighting orientations.

Less gradients are better if your game/engine doesn't use the tangent data (or doesn't make its own properly). If the engine uses the tangents from your normalmap baker then make sure to preserve the gradients you do have, they're there for a reason, they're compensating for the extreme changes between the vertex normals on the low-poly mesh. Either way though, reducing them gives better results.

About your cylinder, you can only go so low. Normalmapping gives you a normal for every pixel, but doesn't change topology. If you have a chunky silhouette, you're gonna have problems, especially on tubes/pipes/columns. Also the top there looks like it isn't getting mapped, should be getting a bevel from the normalmap around that top edge.

[Sage]

Eric thanks for the feedback.

I didn't bother much with the top on the low poly and painted it normal map blue because I didn't like how it looked. How many sides are you guys giving your cylinders? I used to think 10 was enough but they look a bit too chunky. I know this kind of depends, just wondering how other approached this. Thanks.

Alex

[Eric Chadwick]

Sorry, it totally depends. What hardware is it running on, what's the vertex budget, how close does the player get, what angle do they see it from, etc. why triangle optimization is not always king (http://boards.polycount.net/showflat.php?Cat=0&amp;Number=249534)

[Sage]

I found this tonight and decided to share since i thought it was interesting. I always like this number for cylinders, so when I read that there was math that helps explain eyes like I decided to share this.

http://www.letterboxanimationstudios.com/Encore/Magic12.php

Alex

[Joao Sapiro]

thanks sage !

[Eric Chadwick]

What a load of BS.

"The points to have the same tangency at every point." /images/graemlins/laugh.gif

An 8-sided cylinder doesn't? And how does the graph have anything to do with subdivision? Which also has nothing to do with game graphics.

Yeah, makes total sense. http://boards.polycount.net/images/icons/poly142.gif

[Rob Galanakis]

While I don't doubt the verity of what he says, it is entirely non-applicable to games, as we don't use smoothing... I doubt it will have any effect in normal maps either.

[Eric Chadwick]

Well to be fair, Sage is really talking about the silhouette. I don't mean to be contrarian Sage, your post is in good spirit. I just dislike misinformation.

Besides the dubious math justifications (compare (http://www.gamasutra.com/features/20000411/sharp_pfv.htm)), the graph itself looked inaccurate from the start. Here's a quickie test in Max, 12.5-diameter cylinders on top of 25-across planes.

http://www.ericchadwick.com/examples/images/12grid.gif

Whatever. An even number of sides is still a good idea... if you're building modular assets then your cylinder can be rotated in easy increments without breaking your level.

The number of sides though totally depends on how the model is going to be seen. RTS or FPS, etc.

[Sage]

No offense taken man, /images/graemlins/wink.gif I don't do the whole math thing myself, I just do the what my eyes say. /images/graemlins/wink.gif At any rate it good to hear other opinions. One of the reasons I use primitives is because for the most part from my observation all the points are the same distance from each other and are made with perfect angles. Whatever that means cause I don't know where I'm going with the comment. I have read books where the artists like odd sided primitives but I guess it's a matter of taste and habits. I like even numbers although for rts type units it can be useful at times to have an odd sided shape for unwrapping. Oh I really wasn't thinking game specific when I posted the link, I mostly found it interesting and decided to share.

Alex

[dolemite]

Hi guys!

Does anyone know of an easier way to attach multiple small detail objects to the main object, other than collapsing it all down to editable poly and clicking attach?

FOr example, It's easier to work with the mesh later if I just group everything together, but I dont think 3DS Max will treat that as one object, so baking the normals map won't work.

Also, does anyone know if baking Normals works any better with 3DS Max 2008? I know they improved the texture baking, doesn't give off those ugly artifacts anymore.

thanks a million!

[Eric Chadwick]

We've done some bakes where the in-game mesh has been "exploded" outwards so that the UV elements are distant from one another in model space. And the high-res bits are placed in the same layout. This way they don't capture overlaps from other areas, just the mesh we want to bake. Only works for mechanical things AFAIK, where you have natural seams.

[Saidin311]

Eric, is it possible to trouble you for a better explanation on whats going on there? I'm not sure what you mean by model-space and placing the high-res bits in the same layout.


I also have a couple of questions, and sadly I don't have an example thus far of it.

1) What would be the general preferred workflow for an object that can't be sculpted. IE an object comprised of multiple floating bits. For some reason looking at ultra high-poly models of guns and vehicles and sci-fi stuff boggles my mind when it comes to baking the proper normal. Every time I try to do it my normal map has weird pinches and bad seams, inaccurate lines etc. Does that just improve from model quality? Or is there something that I might be missing when everything gets "attached" on that high poly model. The biggest thing I have a problem with is that my mind thinks in high-poly and then thinks in low-poly. I can't seem to wrap my head around where and when the cage should come in. Especially when an object is comprised of multiple objects. Do I make a cage for every object?

2) Ultra-noob question here, the Projection Cage from my low poly, can I mess with the verts and polys on that cage without screwing anything up? Sometimes with my models, I have to push my projection out SO Far just to get one little detail. May be no that far, but far enough to be excessive in one spot and bang on in another. Is there any way I can just push "part" of the projection cage?


Thanks for this thread guys, I just read it top to bottom and it answered a lot!

[Eric Chadwick]

Here's a pic of the exploded idea.

http://www.ericchadwick.com/examples/images/nte_bake.jpg

The gray mesh is the final in-game model. The white wireframe is the same mesh except the elements have been moved outwards away from each other, so we can bake the normalmap. The colored meshes are the high-res pieces, I moved them over a bit so you could see them but for baking they have to be in the same position as the white wireframe.

I know there are better images of how to use the cage, including floating bits. I'll try to dig something up.

Edit... the mesh was made by James Ku, here you can see the finished asset:
http://forums.cgsociety.org/showthread.php?f=39&t=274096

[Eric Chadwick]

The cage can be adjusted by moving around individual vertices if you want, just make sure not to add or subtract from the vertex count, has to be the same as the original mesh.

Did you read Ben's great tut?
http://www.poopinmymouth.com/tutorial/normal_workflow.htm

Another good one by Joao Costa that covers baking mechanical meshes.
http://www.acetylenegames.com/artbymasa/tuts.shtml

[Jonathan]

Just two quick questions,

(1) Before baking the normal map, just use smoothing groups on the low-poly where you want a hard edge, correct? *or* do you assign ONE smoothing group with a large numer, like 100 degrees or so, I've seen others do this before.

(2) After baking the normal maps, if the engine supports smoothing groups, is it better to use them or manually break up the model? However, if you break up the model, doesn't that increase vertex count, or do smoothing groups basically do the same thing?

Thanks. /images/graemlins/smile.gif

[Eric Chadwick]

re 1: Smoothing groups cause baking problems. See the Joao Costa link above.

Avoid smoothing groups at all costs, use bevels instead. Some people like smoothing groups, I prefer a bevel because I can make the edge as soft or hard as I like. Whereas a smoothing change is always a sharp edge.

re 2: don't change the mesh after baking, will cause shading seams. A bevel made of two edge-loops is the same cost in-game as a smoothing group edge, which is the same cost as breaking the edge apart.

An old article that might help you.
http://www.ericchadwick.com/examples/provost/byf2.html

[Jonathan]

Thanks. /images/graemlins/smile.gif

[Saidin311]

[ QUOTE ]
Here's a pic of the exploded idea.

[/ QUOTE ]

Thanks for that, just to make sure I got things right. The in-game object was unwrapped prior to exploding it? Or I suppose that probably doesn't matter, but each of these pieces looks like it was given proper space on the unwrap.

And doing this gives the space needed on the projection to get a crisp/clean normal for this particular case? Seems to me this could be a very effective technique for getting into the cracks and creases of a high-poly model.

And Yeah, I've read Ben's Tuts. I think I just need more experience with it, especially unwrapping. I've made objects using most of the standard techniques. But my normal maps just never seem to come out as clean. I will press on. Thanks again!

[Eric Chadwick]

The gray "master" is unwrapped, then a copy is exploded. If I unwrapped the exploded one, I'd have to copy the UVs back to the master.

Yeah, the point is to simply to avoid intersections during the bake.

Similarly, you can also float meshes overtop others. See Poopinmymouth's first post here:
http://boards.polycount.net/showthread.php?t=37457 (http://boards.polycount.net/showflat.php?Cat=0&amp;Number=45506&amp;an=0&amp;page=0&amp;vc=1)

[Jonathan]

Ok, quick question, if I bake a normal map from a high-poly character to a low, and then need to create another normal map based on my diffuse for scratches (using Photoshop+Crazybump), am I correct in assuming the CrazyBump map will be tangent space normal since it's from a photo, and the high poly one (assuming I leave the default setting of tangent in Max) is tangent, so the normal map will work fine on a deformable mesh, except for a few details from the picture/mixed normal map?

Sorry if that questions is a little verbose. /images/graemlins/smile.gif

[Vredesbyrd]

HELLO , i have problem.

when I mirror my mesh with normals applied , it tends to give smoothing errors .
http://img352.imageshack.us/img352/9913/32152542lr9.jpg

one side with normals applied doesn't give smoothing probs , but the mirrored mesh with normals applied give smoothing probs.

[Eric Chadwick]

Jonathan, yes you can combine two tangent-space normalmaps. CrazyBump has a nice Mixer tool that really helps with this, better than mixing in Photoshop (since in PS you have to manually halve the Blue channel values, and set the layer to Overlay).

Vredesbyrd, need more info. Where exactly are the problems? I can't tell what's messed up in your image. Also what shader are you using... DX Display of a Standard material, or a FX file, or something else? Does the model shade correctly without the normalmap?

[Armanguy]

hey guys i am getting little black dots and jagged lines on my normal map i used to get them along time ago but it stopped happening but it came back with my tank model,how do i get rid of them also i haven't adjusted the cage to fit some of the model so that why the normal looks so bad. but i never get jagged lines an dots? heres a pick:

http://img.photobucket.com/albums/v92/armanguy/tanknormalmapcopy.jpg

[Vredesbyrd]

armanguy : you need to reset your xform of your realtime , low poly mesh before you generate the normals using cage to fit method.

[Armanguy]

how do i reset the xform?

[Xenobond]

Utilities Panel &gt; 'Reset XForm'
If it's not in there you can find it in More...

[Vredesbyrd]

EricChadwick

The problem has been fixed after I resetted the xform of the mirrored realtime mesh.

[Eric Chadwick]

Cool, glad it worked!

[BassAckwards]

Hey i am rather new with zbrush, and i have a problem that a can seem to figure out.

I sculpted a model i recently did for practice and went to project the normals and got a low poly cage with a really crappy projected normal as shown below...and i used the morph uv tool to see why the map projected so bad and if found out that some quads are folding over on each other(also shwon below.) If someone could give me some advice that would be great and much appriciated !
http://i228.photobucket.com/albums/ee78/auerbeckt/Untitled-1.jpg
http://i228.photobucket.com/albums/ee78/auerbeckt/Untitled-3.jpg
http://i228.photobucket.com/albums/ee78/auerbeckt/Untitled-2-1.jpg

[arrangemonk]

a few days ago i found out a cool technique to have mirrowed uvspace without getting a seam in the middle of the model
dont know if anybody had that idea already but
its pretty easy tough
http://img408.imageshack.us/img408/6152/shotex6.jpg (http://imageshack.us)
as you can see the middle seam is not neccesary for the model because the part in the middle is flat, but the normalmap shows up correctly, because the normals in the middle are the same left and right (of course, you can do this with edit normals too, but not every engine supports custom normals)

[Keg]

BassAckwards: using 3dsmax? obj files?

Try this exporter instead: http://www.guruware.at/main/objio/index.html

3dsmax has a horrible obj plugin that is quite bugged.

[Eric Chadwick]

arrangemonk, that's a cool idea. Here's another solution that doesn't require a change to the mesh...
tutorial: fixing mirrored normal map seams (http://boards.polycount.net/showflat.php?Cat=0&Number=258332&an=0&page=7)

[Neox]

but it requires a horizontal or vertical uv seam to work, right?

[arrangemonk]

i like my solution more, removing a seam and adding a new one takes me less time than gambling around in ps /images/graemlins/laugh.gif
edit:
maybe when you're setting up the uvs to mirror in the middle without that seam it could work too, but that will distort your uvs to look ugly and i dont know woh to mirrot them without having a seam, (read a tut and didn't get it right ^^)

[Eric Chadwick]

I always like having more than one method available.

I don't like the flatness you get with your modeling method, could be trouble especially in an area like the shoulder or the crotch. Haven't tried it though. Where is that mesh being rendered arrangemonk? Is that realtime, or rendered?

Yeah the paint method does require horizontal or vertical UV seams. If your game engine has it together in the tools dept, they can auto-solve the horizontal/vertical seams for you.

Always good to have more tricks.

[Neox]

well if they can solve the horizontal seams they should be able to solve any seam right? I worked with 2 selfmade engines before working with U3 and those could handle mirrored seams very well, be it on horizontal or bent seams.
Also most shaders for max can handle it, so why is it that hard to fix that stuff?

[Illusions]

I might have yet another alternate solution. I tried it out on something really simple and it worked, I don't know how useful or well it would work on something more complicated, but here are the steps. As for programs used, normal/diffuse maps generated in Maya, and I viewed it in xNormal to verify.

1) Do everything as normal.
2) Before you bake your normal maps, create a duplicate of anything that is going to have mirrored uvs, but that you do not want a seam on (like the character's head).
3) Normal Bake only the non-mirrored geo.
4) On the duplicates, move the mirrored uvs, and re-assemble them to look as they would without seams. Do not scale the uvs, and do not move, rotate, etc individual uvs, deal only with the shell as a whole. Weld the seam uvs when done. Try to do this without distorting either.
5) Bake your normal maps to the duplicates.
6) Apply your normal maps as a diffuse/color texture to each duplicate individually as a seperate surface shader.
7) Diffuse bake the duplicates as your source to the originals as the target.
8) Use the resulting baked diffuse as your normal maps, and composite in with the rest in photoshop.

The idea was that you are preserving the surface normals as they were on the original map, normal baking those with seamless uvs, and then transfering the resulting map using a diffuse bake to the actual uvs you wish to use.

[arrangemonk]

it was a render here a screen shader prevs
i figured out, that the bigger the polies better the better the result hrrhrr
http://img225.imageshack.us/img225/7546/shotnn4.jpg (http://imageshack.us)


edit: darn, im just too confused^^

[BassAckwards]

Keg: Thanks a lot for the feedback I am in class now and will give the exporter a try when i get home... I had heard 3dsmax had a bugged exporter a little after I posted my help request. Thanks again for the help dude much appreciated... I heard xnormal was another good open source normals program any comments?

[deibling]

OK, so I glossed over most of the posts, so if this is touched on earlier, let me know and I double back.

I just finished an art test for a co, and they wanted me to provide normal and spec maps. As I just finished school recently, I know OF these things, why they are cool, what they are for, etc. But I don't know how to APPLY any of it in Maya.

I have my dandy little texture, and I have the Nvidia plug in for Photoshop so I can make pretty little Normal maps,...but now what?
I tossed the normal into the Bump map slot into my materials attribute editor, and something happens- but we are not going to discuss how awful that looked. Is it just a settings thing?
-What about Spec maps..where to I apply those?
-Is it a separate material slot with an alpha attached to it?
-Are there any good tutorials that really spell out what has to be done to get a normal/spec from Photoshop into Maya and onto your model?

Many tutorials gloss over the actual application of the texture in Maya/Max/whatever. They are all helpful as far as making the texture, and then the screen/page fades to white, and the next thing I know the tutorial maker is smoking a ciggarette in a velvet smoking jacket and slippers talking about how now that Ive gotten both the normal and spec maps applied and can move on to the next step.....

WHAT!?!

Hence since I don't know any of this, I'm concerned about the life expectancy of my Art Test. /images/graemlins/frown.gif sniff.

Any help at all would be awesome. Thanks

[rooster]

dunno what tuts you've been looking at but the ones i watched mention you need to put the normal map in the bump slot and change the type to tangent space in the drop down menu of the bump settings. bear in mind you might need to invert the green channel depending on the way the normal maps were generated

edit: and don't forget unless you have jsnormalmapper plugin default maya renderer can't render normal maps, you need to use mental ray. default renderer will just apply them as straight bump

[Eric Chadwick]

deibling, google to the rescue.
http://www.google.com/search?hl=en&amp;q=normal+map+maya

[t4paN]

Guys, I'm creating two normal mapped characters for my dissertation at uni, and I have a question that might sound lazy, because I don't have time to mess around with settings and try new things. /disclaimer

Here goes: Is there a way to render a normal mapped model with the shader being displayed in the end result, eg for a beauty shot, or can I only create real time screenshots?

Also, do you guys think its a good idea to use Ben Clowards shaders and then include them in my hand in disk for the professors to use in order to see my stuff or is it too much hastle for them?

How would you guys present a normal mapped model if you had to give it in both in printed hardcopy and also as a max file on a disk?

Thanks

[Eric Chadwick]

Put the shader and the textures and the Max file all in the same folder. Strip all map paths (Utilities panel, Bitmap Path Somethingsomething tool), so when your prof loads the model it will simply look in the same folder as the Max file to load the textures.

Screenshots of the shader for your prints.

[t4paN]

[ QUOTE ]
Put the shader and the textures and the Max file all in the same folder. Strip all map paths (Utilities panel, Bitmap Path Somethingsomething tool), so when your prof loads the model it will simply look in the same folder as the Max file to load the textures.

Screenshots of the shader for your prints.

[/ QUOTE ]

Thanks for that man. Just one quick question, when the model is opened, then I suppose the shader will be run automatically, the way the maps load?

[Eric Chadwick]

Try it and see. You need to test anyway, to make sure the professor will be able to see your model.

[t4paN]

Will do man, thank you very much for your help. /images/graemlins/smile.gif

[Sam Hatami]

Alright, I'v gone through most of the pages here and also done a couple of searches but haven't found my "problem statement" anywhere. No matter, I am grateful for any help/suggestion that are presented.

(3ds max 9)
The issue here is anti-aliasing, on the edges of a normal map. Maybe this picture will make it more clear(ignore the other errors :P)
http://img147.imageshack.us/img147/5486/jaggylinesml8.jpg
When I look at a lot of your normal maps, neither of yours has these jaggy lines.

1. I'm not even sure if they actually affect the end product?

2. Is there a way around this if the answer to the question above is yes?

Thank you very much

[rooster]

if bit that's bothering you is the edge of the uv island, i believe max has a padding value you can set to get it to render just beyond the uv borders

[Sam Hatami]

The only setting I didn't bother to change.
Thank you very much, rooster!

[Eric Chadwick]

Also, if you're baking any meshes that have overlaps, like rivets or pipes going across a panel, then you'll also see jagged edges where they meet. If you turn on Global Supersampling in the Render Settings, it takes a bit longer to render but you get anti-aliasing. Also helps when resampling textures from one UV set to another, you get a smoother end result.

[Jonathan]

I normally use Hammersly at 0.5 or sometimes 1.0 if I'm feeling brave. :)

[odium]

With regards to smoothing, when you bake a normal map from a high poly model over a lower poly one, whats the best way to smooth the low poly mesh? Doom 3 uses an all over smooth (Which is what our model is for, Doom engine style). With relation to both hard and soft edges on both organic and metalic objects?

[thatnumpty]

is possible to bake an object-space normal map in 'max?

[Eric Chadwick]

@ odium: 1 smoothing group (all soft edges). Where there are hard edges, the normals will be split, thus the raycasting for the normalmap will be split, thus it will create missing gaps in the map. Use a tight bevel/chamfer instead of smoothing groups, same cost in-game as a hard edge.

@thatnumpty: yes, easily. Render To Texture > Projection Options.

[Jonathan]

is possible to bake an object-space normal map in 'max?

Yes, it's in the render to texture options. :)