No, bump maps do not disturb the normal on Y. They disturb the virtual position, which is also going to move a point in 3 dimensions. They indicate the virtual position of a displaced surface with respect to the original surface along the original surface normal. Then the gradient of this new virtual surface is calculated, producing new normals, which are substituted back to the original surface.

In both cases, 3 values are altered. For bump, it is position, which results in new XYZ vector components for the normal.

The math is straightforward, even if not everybody here believes me. I got an 800 on my Physics SAT, and got an A in calculus at MIT, if that helps anybody trust my word on this.

Okay, here's an example that really shows a true advantage for normal maps:
http://www.taron.de/Neckling.htm

Pretty sure you can't get this kind of effect with just a bump map, like how the ears and nostrils have a very convincing appearance of depth. 

That says displacement dude. Look at the words on the top.

Quote - Bagginsbill you'd like this thread, there is math in it.
http://boards.polycount.net/showthread.php?t=36160

OK. I read that, and the guys that know what they're talking about said the same as me. The only thing that slightly sounds funny there is somebody mentioned a degree of accuracy possible with normal maps that he claimed isn't possible with bump maps. He's wrong. The expression of a vector using 3 8-bit vector components is no more accurate than the displacement, especially if the displacement is a 16-bit grayscale map. There are certain slopes that cannot be expressed in either, but in practice these are variations that cannot be seen by any human.

Anyway, I'm not interested in convincing others of the math. Prove me wrong with a visual and I will acknowledge it. I want to see a properly made normal map do something visually identifiable as "better" than a properly made bump map. Improperly made maps of either kind won't count.

Quote - That says displacement dude. Look at the words on the top.

So it does, I didn't read the text on the image because the cool factor of the image itself was making my eyes bug out.  I blame it on the forum that directed me there.  While I've read a lot of documentation that says normal maps have an advantage, that is only on paper (or LCD emitters really), and I agree I haven't really seen anything that I don't think could be done with a bump map.  You still can't alter the base geometry in profile or modify non-self shadows with either method.

Quote - > Quote - I personally don't believe there is a right or wrong answer to this question...it is, what it is.

You do or you don't.

Nonsense, there's either a real technical advantage, or using normal maps is quite a bit more work for no purpose (at least if you're really doing a proper x/y/z normal map).

Pjz99,
The reason for the way I worded my statement was I didn't want to get into a war of words. I use normal maps and like how they work. Nuff' said.

The Andy materials for the Mannequin use a normal map. At settings above1.5 black artifacts begin to show up. The maps actually work best when set to Gradient Bump, and negative values are used.

LMK

Quote - When you say "not from a grayscale image", now the words are being twisted. Forget the term grayscale image. Instead, think "topology delta matrix". Given a topology delta matrix, i.e. the difference between two meshes as measured along the surface normal vector from one to the other, you end up with exactly the data found in a bump map.

See what I mean? From that, you can construct all the normals.

Yeah, you know what Bill?
After I posted the few comments above and started planning how I could go about illustrating what I meant, I went back and re-read what you had written. I did that because I thought to myself there's no way BB is going to give such a simplistic answer and expect it to be taken as fact. So I figured something was up. ;-)
I realized I had read it wrong and I now see what you meant. Sorry about that, I didn't mean to take you out of context. I should have edited my reply, but I was already involved in something else. Got a nice fresh bottle of Jack Daniels here too. ;-)

Quote -

If you are going to use NormalMaps I would encourage you to create and use them with TangentSpace.

Hope this helps

Yeah, I read the Poser Pro normal pdf file.
The normal map tests I've done in Poser Pro (zBrush) have resulted in "bumps" that were seemingly largely inverted. I don't know if that's because of Poser, or because I passed the object through LW first and on to ZB as OBJ.
I use "Maya Tangent Space" for LW though - seems to yield the best results.

Jack Daniels here too, Mike, no kidding!! Great minds drink alike.

Ice and Coke or straight? ;-)

Dear lord straight man, straight, why ruin a decent drink

Quote - > Quote -

If you are going to use NormalMaps I would encourage you to create and use them with TangentSpace.

Hope this helps

Yeah, I read the Poser Pro normal pdf file.
The normal map tests I've done in Poser Pro (zBrush) have resulted in "bumps" that were seemingly largely inverted. I don't know if that's because of Poser, or because I passed the object through LW first and on to ZB as OBJ.
I use "Maya Tangent Space" for LW though - seems to yield the best results.

I know why they're inverted. And I know how to fix it in Poser, if you want to.

The XYZ components of the normals are stored in red, green blue. However, there is some disagreement among applications as to which direction each goes. Poser (as usual) disagrees with most other applications in the green (Y) channel, although it agrees in red (X) and blue (Z).

This is not entirely Poser's fault, though. It has to do with whether you are in a right-handed coordinate space or a left-handed coordinate space. Neither is more correct, and some apps are left, others right. I have even seen some apps that generate normal maps offer an option that you toggle, something like "Y is Up or Down?".

You have to invert the green component, using Color_Math nodes. Once you do that, you can directly use normal maps made in other applications that are opposite handed. Do you want me to show how?

Sorry, Ice and Coke. However, give me scotch and it's straight.

Quote - Mike I don't get what you're saying.

You said they calculate the difference of the sculpted detail on the high res mesh from the unsculpted detail of the low res mesh. What do you mean by "detail"?

In the renders I did above, the low res mesh was just one polygon. It doesn't get any more low res than that. What looks un-detailed to you there?

Oh I missed this post earlier.
That was a ZBrush reference which I didn't make clear. In ZB you typically crank up the polygon count of a model into the millions and then sculpt extreme detail into it. But you have to go back to your lowest subdivision level before generating a normal (or displacement) map for the model, so it can read the difference. The difference being the detail sculpted into the high res version.

honestly, it's best suited for apps that are able to render subdivision surfaces where you can control the render sub-d level.

Quote - Sorry, Ice and Coke. However, give me scotch and it's straight.

That's fine.
I do straight, but only when I'm partying with my friends. Getting old, you know. Coke and ice creates a nice buffer, reduces the potential for the embarassing passout reflex. ;-)

I know how it works. I thought maybe your use of the word "detail" was implying that bump maps cannot produce detail as well as normal maps. That is the crux of the question - why use normal maps? The only answer so far is "because that's what I have" (not a bad answer) or "because I read somewhere that they're better but I can't prove it". :-)

You know, to tell you honestly Bill, I'm not sure.
I do know I've read that normal maps are more powerful and versatile than bump maps. I do know that my own tests have proved that.
Then again, I never made my own bump maps (aside from procedural), and only started using normal maps when it became.... errmm... "normal" to do so in place of bump maps.

I won't say it is almost the same thing, considering the sheer popularity of normal maps and the number of pros who advocate them, but I also can't say (and prove) that they're better than bump maps either.

Maybe it's just a huge scam, far as I know, created by Pixologic and Autodesk.. but, when it comes to sculpting something in a sculpting app and exporting the textures and expecting to see in your rendering app what you see in your sculpting app, normal maps are at least far easier to deal with and to get results with. :-)

I edited my reply above due to a major typo where I said that I can't prove, yadayadyada....
The JD has won tonight's round. ;-)

But I want to continue this, because I'm intrigued - not just what Poser 8 can do with normal maps, but normal maps vs. bump maps in general.

But it's time to sign off... will continue this tomorrow....

For those wondering about the advantage of normal maps over bump maps, go to the link provided by pjz99 here, and take a look at the first two examples (bump and normal/parallax). Especially notice the two details on the left (the spherical protrusion and the truncated cone). Notice how the normal map actually looks right given the viewing angle, whereas the bump map just looks wrong.

Nod, the big question is really "will Poser render them any different".

Now you're talking about parallax mapping.

http://en.wikipedia.org/wiki/Parallax_mapping

Of course the truncated cone looks better - but that's not an endorsement of normal maps. It's an endorsement of parallax maps. Poser doesn't do parallax mapping. It could, but if it did, it could do it with bump maps too.

Start over - show me the difference between bump mapping and normal mapping.

In case you miss it in the wikipedia article:

Parallax mapping (also called offset mapping or virtual displacement mapping) is an enhancement of the bump mapping or normal mapping techniques.

Also, I'm mystified as to why this is even of interest, when in Poser we have not just virtual displacement mapping, but REAL displacement mapping.

Quote -
Also, I'm mystified as to why this is even of interest, when in Poser we have not just virtual displacement mapping, but REAL displacement mapping.

Sorry, man, I'd have to disagree with that.
"REAL" displacement mapping involves micro-poly displacement of a subdivided model; the displacement map imitates huge displacements of a polygon model in the millions, while using only thousands, in subpatch, at render time.
Poser can't subdivide a mesh, at render time or at any other time. Yet.
Is one of my UberPoser wishes. ;-)

from what i undertand normal maps give you a more accurate 3D look like displacements but as fast as bump maps.

i think i saw some examples where a low polygon model with normal maps looks detailed and even more smooth.

can bump do this? a low poly model that has a sharp mesh? and then make it more round and smooth? 

I think what you're seeing, at least in the top row, is either displacement maps, or normal maps showing the evolution from low res geometry to finished product.
Like bump maps, normal maps cannot physically alter the geometry - only displacement maps can do that, but also only when the geometry shape is close to the shape of the displacement (optimal), and is a subdivision surface that allows micro-poly displacement at render time - where the polygons are physically subdivded by the render engine in order to be able to show more detail.
Kinda like half a morph vertex map, in that it doesn't need the same point count to approximate the shape.

The bottom row looks more like normal maps, but it still looks like there's some subdivision going on.

the example of the monster.

1. high res mesh
2. low res mesh
   3: low res mesh with normal map

I'm not sure about that. There are at least two places on the low res mesh with normal map (far right) where the geometry in the silhouette definitely looks altered, perturbed, as with a displacement map.

Could be the POV though, could be that I've been up for almost 48 hours with no sleep. ;-)

On closer look, it does look like only a normal map.
But that's definitely a sub-d geometry.

Quote -
can bump do this? a low poly model that has a sharp mesh? and then make it more round and smooth? 

I didn't notice this question earlier, but no, a bump map can't make the geometry more round or smooth, but then again neither can a normal map.
All the biggie 3D apps (far as I know) allow for subdividing geometry at render time and/or in OpenGL (or DirectX) display to customizable levels. That's probably where that figure gets the smoothing look, although some programs such as Maya allow for actual normal smoothing, which isn't the same as surface smoothing or subdividing.
The normal map is just icing on the cake, for the sake of detail.  A high res 32 bit displacement map over a highly subdivided object would look a lot better.

But I suspect you know all that and it's just a rhetorical question.

I made a quickie model (excuse the texture) this morning.  From left to right

No Bump or Normal Map
Bump Only
Normal Only

The model was made in 3d coat, which auto generated the Normal and Bump map at the same time.

I rendered with the default bump value of 0.08 but the bump map hardly showed up, this one is with a value of 1, which shows up some details as well as the Normal Map (also value 1) but distorts other parts too much.

As I said I don't know the full mechanics of it, but I am very happy with the results with the Normal Map :)

John

Quote - from what i undertand normal maps give you a more accurate 3D look like displacements but as fast as bump maps.

i think i saw some examples where a low polygon model with normal maps looks detailed and even more smooth.

... [ pictures ]

can bump do this? a low poly model that has a sharp mesh? and then make it more round and smooth? 

Yes it can do this.

Guys, because you keep saying the same non-responsive things, I'm forced to keep repeating myself and sounding more and more peeved. Please don't interpret what I'm saying here as being pissed off. I have to explain again in ever more excruciating detail what I'm saying because it's not getting through.

When the renderer processes a bump map (procedural or image based, doesn't matter), the final result is that normals are altered, exactly the same result as a normal map. The bump map represents the starting information in a different way, but the result is the same. Surface normals are varied from their original direction. The variation can be smooth and rounded or sharp. It can change a sharp edged thing to smoothly rounded, and it can change a smoothly rounded thing to sharp edged. IN APPEARANCE ONLY. The sillhouette (spelling?) remains unchanged.

Showing pictures of beautiful results via normal mapping does not demostrate a DIFFERENCE between bump maps and normal maps. It is flawed logic to present a nice normal-mapped render and claim that endorses or proves that normal maps are different from bump maps in outcome.

It's like I asked you what's the difference between a Ford and a Chevy truck, and you keep saying "Well the Chevy let's you haul things and pull a trailer." That's not a difference, because the Ford also hauls things and pulls trailers. Is that clear?

Do not keep saying that normal maps can make flat things rounded. Bump maps also can make flat things rounded. Do not say that normal maps can capture the normals of a high poly mech and make a low poly mesh look like a high poly mesh. I agree, that is what normal maps do. I do not agree that that is the difference. Bump maps ALSO make a low poly mehs look like a high poly mesh.

I'm responding to ice-boy here, but there are more posts after that one that I haven't read yet. So if somebody said something interesting between ice-boy's pictures and my response here, give me a few minutes to read the rest.

Quote - OK here is my lil test.

I made a quickie model (excuse the texture) this morning.  From left to right

No Bump or Normal Map
Bump Only
Normal Only

The model was made in 3d coat, which auto generated the Normal and Bump map at the same time.

I rendered with the default bump value of 0.08 but the bump map hardly showed up, this one is with a value of 1, which shows up some details as well as the Normal Map (also value 1) but distorts other parts too much.

As I said I don't know the full mechanics of it, but I am very happy with the results with the Normal Map :)

John

In addition to "properly made" I should have also required "properly used".

When you plug in the bump map, you have to correctly specify the depth to interpret it. When you say you used a "value of 1", without specifying units, I don't even know what depth you dialed in. But the point it that unless you enter the matching depth that the modeler used, it will not evaluate to the same virtual surface.

Which actually shows an advantage in USE, not in capability, now that I think about it.

Fugazi gets a point for accidentally showing a useful difference.

Because of how the bump map is encoded, I argued that it is better and more powerful because you can change the bump depth at will to vary the strength of the effect. But having done so, he has inadvertantly demonstrated that the bump map does not result in the smooth transformation of normals to the exact desired target virtual shape, UNLESS he correctly enters the key information - what is the correct depth? 

So this is interesting. When using a bump map for specific SHAPING, you probably will not know what exact depth to use. The normal map, being that it doesn't ALLOW you to change the depth and has it hard-coded, does not vary from the desired virtual shape.

Fugazi gets 1 point, but only because he doesn't know the correct value to type in to Bump depth. If he knew, then it would look the same.

So I'm going to say this from now on, because clearly this is a benefit for normal maps.

Here's the benefit - you do not need to specify the correct depth to achieve a specific shape that you were using in the modeling tool.

That's good.

The downside is that is the ONLY shape you can get with the normal map you have. If you want any variation of that, you have to get a new normal map. With a bump map, you don't.

Thinking about that some more, there is a variation on that benefit that is likely even more important.

If you have a prop with a bump map for the purpose of altering the virtual shape, and you SCALE the prop, you have to scale the bump depth as well, or you end up with a new virtual shape!

WIth a normal map, you do NOT have to adjust anything - the virtual shape will automatically be scaled as well. That's a very good point and I'm glad to see it.

For that reason, and that reason alone, I now believe that normal maps are better than bump maps for some things. For other things, like my virtual tiles on a single polygon, the bump map is better.

Fugazi gets the full prize, guys.

Quote - > Quote -

Also, I'm mystified as to why this is even of interest, when in Poser we have not just virtual displacement mapping, but REAL displacement mapping.

Sorry, man, I'd have to disagree with that.
"REAL" displacement mapping involves micro-poly displacement of a subdivided model; the displacement map imitates huge displacements of a polygon model in the millions, while using only thousands, in subpatch, at render time.
Poser can't subdivide a mesh, at render time or at any other time. Yet.
Is one of my UberPoser wishes. ;-)

Uh - Mike, Poser (REYES) displacement is precisely and specifically called micro-polygon displacement. Sub-D has nothing to do with it. There's no need to conflate Sub-D with micro-poly displacement.

Let me ask you this. If I showed you a cube (six polygons) that with Poser displacement looks in all ways exactly like a sphere, would that prove to you that displacement in Poser is real and complete and capable of transforming a low poly shape to look just like a high poly shape, or no?

Quote - Thinking about that some more, there is a variation on that benefit that is likely even more important.

If you have a prop with a bump map for the purpose of altering the virtual shape, and you SCALE the prop, you have to scale the bump depth as well, or you end up with a new virtual shape!

WIth a normal map, you do NOT have to adjust anything - the virtual shape will automatically be scaled as well. That's a very good point and I'm glad to see it.

For that reason, and that reason alone, I now believe that normal maps are better than bump maps for some things. For other things, like my virtual tiles on a single polygon, the bump map is better.

Fugazi gets the full prize, guys.

A prize how marvelous :) though I have a small question.  I did try a range of values for the bump map, without magically stumbling on the right value.  Is there any way of calculating the correct bump value, or is it educated guesswork? John

Given how confusing "units" transfer from one application to another, especially with Poser and its funny Native Unit, I'd say the only hope is guesswork. All the more reason why the normal map is better when exporting from one app to another.

Quote -
The downside is that is the ONLY shape you can get with the normal map you have. If you want any variation of that, you have to get a new normal map. With a bump map, you don't.

I don't see that as a downside though. Every map I ever make, textures, displacements, or normals, I make for a specific purpose, a specific model in a specific setting. It's fun. ;-)

But in other words, I agree normal maps are what they are - WYSIWYG, and I make them with no intention of altering them.
Mostly for furniture and houses and walls and shit, since I mostly do arch-viz.

Oops, are we allowed to say shit here? ;-)
Gotta forgive me, I'm delirious from lack of sleep. Big project that needs to be done... last week.

Quote - Given how confusing "units" transfer from one application to another, especially with Poser and its funny Native Unit, I'd say the only hope is guesswork. All the more reason why the normal map is better when exporting from one app to another.

As with so many things in Poser :) gotta love it though.

Normals seem the way to go, I shall have to experiment on a poser figure now :)

John.

Quote -
Uh - Mike, Poser (REYES) displacement is precisely and specifically called micro-polygon displacement. Sub-D has nothing to do with it. There's no need to conflate Sub-D with micro-poly displacement.

Let me ask you this. If I showed you a cube (six polygons) that with Poser displacement looks in all ways exactly like a sphere, would that prove to you that displacement in Poser is real and complete and capable of transforming a low poly shape to look just like a high poly shape, or no?

I really wasn't aware of that. I guess I have to rethink what "subdivision" really means. Apparently it has connotations beyond the obvious.
I know what you mean about the box-to-sphere thing. That's easy enough with typical sub-d in any modeler. I believe you, of course, but I'd like to see it in Poser and know how it's done if you have the time.

I imported a welded 6-polygon box. I enabled smoothing, and set the crease angle to 95 degrees, so all the edges would be smooth. I duplicated it and rotated the second one so a corner is facing us.

It's not exactly a sphere, but it demonstrates micropolygon displacement.

If I were to carefully craft a displacement map (would not be easy - lots of math) I could force it to be a perfect sphere. I don't have time right now to do that.

Smoothing in Poser is basically the same as displacement, except not driven by a map image, but by analyzing the geometry itself.

The flaw is revealed by the ray-traced shadows. Ray tracing is a bag on the side of the REYES renderer, and for ray-traced shadows (or reflection or refraction) the displacement is not implemented except on the vertices. Thus, the true geometry (boxes) are revealed by the shadows. With a higher poly model, this problem is not so obvious. With depth-mapped shadows, this problem doesn't exist - the shadows are round.

Very interesting Bill, thanks for that. That's geometry smoothing, not just surface smoothing. I never noticed that since when I import things with edges I want to stay sharp I unweld them before exporting.

Quote - The flaw is revealed by the ray-traced shadows.

Still?  That's disappointing.