another object space vs. tangent space question

In Vertex space the normal map assume a very low spatial frequence so the compression of the texture is more easier (in fact if you see the color of the normal map it is very similar from one pixel to another).

The main drawback of normalmapping in object space is that the various polygons of the object cannot share dot3 data even though they use the same material. Consider a regular stone box with 6 sides. With object-space normalmapping each side would require its own section of the dot3 texture because each side has different normals in object space. With tangent-space normalmapping the sides could share the same section of a dot3 texture because their normals in tangent space are the same.

- Kasper Fauerby

(PS. Sorry for the poor english from my side.. I just cant seem to get the phrasings right just now :)

I just thought of a short follow-up to my previous post in this thread...

Actually more and more people are starting to use ZBrush to generate extremely high-detailed normal maps for stuff like characters. And even though ZBrush can also output its dot3-maps in tangent-space you could say that it actually works with object-space bumpmapping, since it *will* generate a region in the dot3 map for each polygon (as far as I know). So even though object-space bumpmapping can be quite demanding on texture resources it still has its uses...

- Kasper Fauerby

Quote:

Original post by Kasper Fauerby I just thought of a short follow-up to my previous post in this thread... Actually more and more people are starting to use ZBrush to generate extremely high-detailed normal maps for stuff like characters. And even though ZBrush can also output its dot3-maps in tangent-space you could say that it actually works with object-space bumpmapping, since it *will* generate a region in the dot3 map for each polygon (as far as I know). So even though object-space bumpmapping can be quite demanding on texture resources it still has its uses... - Kasper Fauerby

When I wrote the shaders I had indeed models like characters in mind where most faces would need unique normal maps anyway. So the only "problem" with object space bump mapping is that the normal maps cannot be reused for different faces?

Edit:
As I already experienced before posting here gives me a +10 to my google skills and I found an interesting atricle about the topic:

http://www.3dkingdoms.com/tutorial.htm

[Edited by - muhkuh on January 14, 2005 12:26:58 PM]

Tangent space has some other benefits.

One is filtering, you can perform screen-space effects on a tangent space normal map. Object space doesn't work for this. For similar reasons, mip-mapping object space normal maps doesn't work well.

What normal do you use for the 1x1 mip-map for an object space texture? For tangent space, you choose [0,0,1]

Also, you can blend in decals more easily on top of a tangent space normal map.

Quote:

Original post by SimmerD Tangent space has some other benefits. One is filtering, you can perform screen-space effects on a tangent space normal map. Object space doesn't work for this. For similar reasons, mip-mapping object space normal maps doesn't work well. What normal do you use for the 1x1 mip-map for an object space texture? For tangent space, you choose [0,0,1] Also, you can blend in decals more easily on top of a tangent space normal map.

I just tested the results of my two shaders and the object space version give me better results because all vectors can be renormalized per pixel so even with low tesselation things look good. The drawback are some filtering artefacts of the normal map what fits to your comment.

Is there a way to use tangent space AND renormalize all required vectors for diffuse and specular lighting (L, N, H, possibly V, R) per pixel with a GF4 when using a specular function stored in a texture? Or is the way to go to leave the models reasonably tesselated?

That's quite a nice shader, but the downside of texdp3tex is you cannot renormalize one of your vectors (in this case t2). You're doing about all you can in a ps1.x shader! I've written very similar shaders in ps2.0, but computing the half-angle in the pixel shader. The resulting specular highlights are near perfect, even on surfaces with quite low tesselation.

joe
image space

Although this doesn't really fit well to the threads topic anymore I got another idea for good per pixel specular lighting on GF4:

tex t0                      //N in tangent spacetexm3x3pad t1, t0_bx2       // transform N to light space andtexm3x3pad t2, t0_bx2       // reflect light space eye vector (t1.w,t2.w,t3.w)texm3x3vspec t3, t0_bx2     // by N and look up R in cube texture

In t3 is a cube map with a function that returns a specular value for R. This would require a seperate specular pass but may be this gives better results.


Edit: It works. The results are much better with low tesselation. The specular highlight is stable. As a bonus this even runs with ps_1_1 instead of ps_1_3. Yeah!

Thanks

Markus

[Edited by - muhkuh on January 16, 2005 12:40:55 PM]

Another advantage of tangent space normal maps is they're better when you compress them with DXT5 (where shader moves alpha back into red component) because the normals are clustered around (0,0,1). That might be one reason why the tools that map high-poly models to low-poly+normalmap output to tangent space as an option.

I've tried calculating cos^n in ps1.1 shader on gf4 using arithmetic and there's too much banding.

For specular highlighting on gf4 I've used this (it's the blinn version of what you've got - I found that texm3x3vspec was quite slow on gf4 so I avoid it) and it worked quite well (this is second pass - diffuse/cutout was done in first pass)...

// NOTE: must set c0.rgb to sun colour.
const char pixelShaderSrc[] =
"ps_1_1\n"
"def c1, 1,1,1,1\n"
"tex t0\n" // Uncompressed normal(rgb)/Gloss(a).
"texm3x3pad t1,t0_bx2\n"
"texm3x3pad t2,t0_bx2\n"
"texm3x3tex t3,t0_bx2\n" // (H.N)^n
#ifdef SURFACE_SHADOW_SPECULAR_BUMPS
"mul r1.rgb, t3, t0.a\n" // (H.N)^n * gloss
// clamp(0, 1, 8*Lz) - fade out bumps that are shadowed by mesh surface.
"+add_x4_sat r1.a, v0_bx2.b, v0_bx2.b\n"
"mul r0.a, r1.a, r1.b\n" // clamp(0, 1, 8*Lz) * (H.N)^n * gloss
"mul r0.rgb, r0.a, c0\n" // clamp(0, 1, 8*Lz) * (H.N)^n * gloss * sunColour
#else
"mul r0.a, t3.b, t0.a\n" // (H.N)^n * gloss
"mul r0.rgb, r0.a, c0\n" // (H.N)^n * gloss * sunColour
#endif
// r0.a used by alpha-test to reduce alpha-blending where there's no specular.
;

...the texm3x3 transforms the tangent-space normal from normal map into a coord system that has the tangent-space half-vector as local z-axis and then looks up a cube map that contains cos^n blinn specular function (the advantage being that you don't need to normalise H and arithmetic of 3x3 transform is done by high-precision texture registers. The x-axis of 3x3 is B = normalize(cross(tangent_space_H,(0,1,0))) and y-axis is T = normalize(cross(tangent_space_H,B)). The self-shadowing bit of shader helps avoid artifacts when tangent_space_H gets near (0,1,0) and causes cross-product in vertex shader to fail (register v0 contains tangent-space light direction).

Thank you for that. I didn't know texm3x3vspec was that much slower. The self shadowing looks different from what I had too but I remeber to have seen that saturate(light.z*8) thing in some nVidia paper and it makes sense. It worries me a bit that v0 is not renormalized per pixel but I think the light.z*8 will take care of that.


A last question is about transparency. When the alpha channel of the base texture contains the transparency of an object it cannot be accessed in the specular pass. Should the former pass write it to framebuffer alpha? But this is used to store attenuation when a point light or something is used (at least I did it this way). Or is it just unnaccessary for specular hightlights to be transparent? Please shed some light onto this ;-)

Edit: I did a quality comparison of my shader to yours using a sphere with 10*10 segments. The image quality of my shader seems slightly better to me. The highlight is always perfectly stable while in your version they "wobble" a bit (just a little bit, really). When using the same lookup cube texture my shader's highlights seem to be smaller though. I guess the reason for all this is that N.H is just an approximation of R.L. Unfortunatly I don't have a reference image. On the other hand I just want to produce something that looks good while running at good frame rates so your shader will probably be the better choice.

[Edited by - muhkuh on January 17, 2005 6:13:27 AM]

Quote:

Thank you for that. I didn't know texm3x3vspec was that much slower.

I remember using it for water which, when covering the whole screen-space, ran at around 70fps on gf4ti4200 with vsync disabled.

Quote:

The self shadowing looks different from what I had too but I remeber to have seen that saturate(light.z*8) thing in some nVidia paper and it makes sense.

Yeah, I got it from some bump-mapping nvidia paper by Kilgard I think. "Practical bump-mapping" IIRC.

Quote:

It worries me a bit that v0 is not renormalized per pixel but I think the light.z*8 will take care of that.

Since it's only used for the mesh shadowing the bumps I'm not too concerned about it.

Quote:

A last question is about transparency. When the alpha channel of the base texture contains the transparency of an object it cannot be accessed in the specular pass. Should the former pass write it to framebuffer alpha? But this is used to store attenuation when a point light or something is used (at least I did it this way). Or is it just unnaccessary for specular hightlights to be transparent? Please shed some light onto this ;-)

My shader above is for no cutout. For cutout I pass gloss into framebuffer alpha like this...
I had the diffuse pass (first pass) use 2 textures - one had diffuse in rgb and gloss in alpha, the other had normal in rgb and cutout in alpha. The shader outputs ((cutout>0.5)?gloss:0) to alpha in first pass using 'cnd' instruction (with alpha test set to >0). For second pass alpha blend mode is set to dest_alpha * src + 1 * dst and texture0 has normal in rgb and cutout in alpha and shader outputs ((cutout>0.5) ? (H.N)^n : 0) and alpha test set to >0. So if cutout < 0.5 then both passes are rejected by alpha-test (the 2nd pass alpha-test also has advantage that it cuts alpha-blending fill-rate for pixels where (H.N)^n is zero). Though for this to work gloss can never be exactly zero.

Quote:

Edit: I did a quality comparison of my shader to yours using a sphere with 10*10 segments. The image quality of my shader seems slightly better to me. The highlight is always perfectly stable while in your version they "wobble" a bit (just a little bit, really). When using the same lookup cube texture my shader's highlights seem to be smaller though. I guess the reason for all this is that N.H is just an approximation of R.L. Unfortunately I don't have a reference image. On the other hand I just want to produce something that looks good while running at good frame rates so your shader will probably be the better choice.

Carmack prefers R.L too for that reason (wobbly). Some say H.N is more physically plausible from micro-facet theory (the distribution of normals on micro-scale, which is one scale smaller than bump-map scale). For me it's faster and my world is tessellated enough that I haven't noticed any wobble except if I'm really looking for it.

Its great to see others pushing the shaders on ps.1.1 hardware. I had quite a few challenges getting good looking specular effects myself.

What I did was to completely cheat!

I wanted all lighting ( diffuse & specular normal mapped ) in a single pass, b/c I'm doing shadows and may have many lights in a scene.

So, I couldn't do real specular powers, instead I used the old trick of rescaling the eye vector by a bumpiness factor in the vertex shader, then pass this into a cubemap. I use the eye vector instead of n.h or r.l because it's linear ( no wobbles ), and the highlight always shows up on flat floors.

I use a cubemap to renormalize the eye vector, then use math to combine the diffuse + "specular" terms.

By varying the bumpheight you can make the highlight grow or shrink, but it does have other effects on the bump mapping by making it more or less prominent...

Quote:

Original post by SimmerD Its great to see others pushing the shaders on ps.1.1 hardware. I had quite a few challenges getting good looking specular effects myself. What I did was to completely cheat! I wanted all lighting ( diffuse & specular normal mapped ) in a single pass, b/c I'm doing shadows and may have many lights in a scene. So, I couldn't do real specular powers, instead I used the old trick of rescaling the eye vector by a bumpiness factor in the vertex shader, then pass this into a cubemap. I use the eye vector instead of n.h or r.l because it's linear ( no wobbles ), and the highlight always shows up on flat floors. I use a cubemap to renormalize the eye vector, then use math to combine the diffuse + "specular" terms. By varying the bumpheight you can make the highlight grow or shrink, but it does have other effects on the bump mapping by making it more or less prominent...

As I'm new to all this I don't know that "old cheat" :-) . Could you explain this a bit more detailed please? You multiply the eye vector by a scaling factor in the vertex shader and renormalize it by a cube map in the pixel shader after that? This cannot be what you meant.

That's exactly what I meant.

The idea is that once the light vector is moved into tangent space, you then multiply it by [ 1 1 0.5 ]. The cubemap renormalizes for you.

This distorts the light vector so it is more flat. This effectively makes the light look like its coming more 'from the side'. On a mainly flat surface, it also makes the highlight area smaller, as the angular attenuation falls off more sharply as the light moves from directly above the surface off to one side.

Alternately, you can multiply by [ 2.0 2.0 1 ] and get the same effect - either scale x & y up or z down to make things bumpier and the highlight tighter, or the other way to make things less bumpy and the highlight broader.

In the limit, if your bump height is [ 1 1 0.0001 ] then the bumps pretty much disappear completely.

You can use this trick to animate the amount of bump mapping on a surface in real-time.

I have separate scaling factors for the diffuse L vector and the 'specular' E vector so that you can play with them separately. This way the surface still looks bumpy from the diffuse lighting, and only the specular bumpiness is changed.

Quote:

Original post by SimmerD That's exactly what I meant. The idea is that once the light vector is moved into tangent space, you then multiply it by [ 1 1 0.5 ]. The cubemap renormalizes for you. This distorts the light vector so it is more flat. This effectively makes the light look like its coming more 'from the side'. On a mainly flat surface, it also makes the highlight area smaller, as the angular attenuation falls off more sharply as the light moves from directly above the surface off to one side. Alternately, you can multiply by [ 2.0 2.0 1 ] and get the same effect - either scale x & y up or z down to make things bumpier and the highlight tighter, or the other way to make things less bumpy and the highlight broader. In the limit, if your bump height is [ 1 1 0.0001 ] then the bumps pretty much disappear completely. You can use this trick to animate the amount of bump mapping on a surface in real-time. I have separate scaling factors for the diffuse L vector and the 'specular' E vector so that you can play with them separately. This way the surface still looks bumpy from the diffuse lighting, and only the specular bumpiness is changed.

Oh, so you use different scaling factors for different vector components. I thought you scaled all components by the same factor and renormalize then (wouldn't make much sense).

I understand that shortening a vector's z component in tangent will lower it's angle to the tangent plane. That this controls the size of specular highlights computed from this vector sounds logical to mee too.

So you have L and E renormalized in tangent space and compute diffuse by N.L. How do you compute specular from E? May be I would reflect E by N to get R and use R.L then but you said that you did't do that. I only read in a tutorial how to do some approximation of a specular function in the pixel shader but this created some very ugly banding.

[Edited by - muhkuh on January 18, 2005 6:28:41 PM]

Object spaced bump mapping is used in alot of applications, because in some cases it is easier.

Tangent space bump mapping is more powerful however. Many people transform object space into tangent space when they are using a package like zbrush. Filtering problems are easier, and you save an eneroumous amount of memory. Not just becuase you can tile, but also because you can store the only the x, y and compute the z, AND because the precision of doing this gives you more precise normals pointing straight up, which is where you want higher precision. This combines to give you much more effective use of memory.

Additionally, with tangent space, you can store the x,y of the normal in the r,g channels of the texture, Ks in the z, and the power in w component. Varying the power and Ks usually have more impact then changing the normal...

Quote:

Original post by EvilDecl81 Object spaced bump mapping is used in alot of applications, because in some cases it is easier. Tangent space bump mapping is more powerful however. Many people transform object space into tangent space when they are using a package like zbrush. Filtering problems are easier, and you save an eneroumous amount of memory. Not just becuase you can tile, but also because you can store the only the x, y and compute the z, AND because the precision of doing this gives you more precise normals pointing straight up, which is where you want higher precision. This combines to give you much more effective use of memory. Additionally, with tangent space, you can store the x,y of the normal in the r,g channels of the texture, Ks in the z, and the power in w component. Varying the power and Ks usually have more impact then changing the normal...

Mmmm. I think this applies only to ps 2.0 hardware doesn't it? I don't think my GF4 can do z=sqrt(1- x² - y²) per pixel except using a texture lookup but this would burn another texture unit. What do you mean by power and Ks? Is power the specular power value so it can change per pixel?

I just use (E.N)^2 for the specular effect. Works pretty well for me so far.

There is a way to rederive z given a guess ( based on newton-raphson ).

If you pass in specular in oD0, for example, you can do a renormalize in the pixel shader in two instructions on ps.1.1. It only works if the vector is normalized in the vertex shader ( which is not correct for H ), because if the value is too small, the approximation breaks down.

You could pass in just E.z in oD0.a from the vertex shader, then grab x,y,0 from a normal map, add in the z from diffuse alpha, and then do the renormalization trick.

From the NVIDIA GPU Programming Guide :

assuming the unnormalized vector is in v0,

dp3_sat r1, v0_bx2, v0_bx2
mad r1, v0_bias, 1-r1, v0_bx2

This will approximately renormalize v0 into r1.

Quote:

Original post by SimmerD I just use (E.N)^2 for the specular effect. Works pretty well for me so far.

Mmmm. So this is independent from L? This will only give specular highlights when looking directlyat the surface! But you actually wrote that it's fake. Maybe I should just implement it and see what it looks like.

Quote:

There is a way to rederive z given a guess ( based on newton-raphson ). If you pass in specular in oD0, for example, you can do a renormalize in the pixel shader in two instructions on ps.1.1. It only works if the vector is normalized in the vertex shader ( which is not correct for H ), because if the value is too small, the approximation breaks down. You could pass in just E.z in oD0.a from the vertex shader, then grab x,y,0 from a normal map, add in the z from diffuse alpha, and then do the renormalization trick. From the NVIDIA GPU Programming Guide : assuming the unnormalized vector is in v0, dp3_sat r1, v0_bx2, v0_bx2 mad r1, v0_bias, 1-r1, v0_bx2 This will approximately renormalize v0 into r1.

I'm a little bit confused now. Is this the answer to my post where I quoted EvilDecl81 and asked about how to calculate z of the normal from x and y?