View Full Version : holy grail bump mapping

okapota

04-01-2002, 10:50 PM

well, eventually, i will have a geforce4 in a few days. so i decided to start learning about the tex shaders. i understand it i think, but one little thing i dont. i the holy grail bump mapping, the shaders compute N*H, N*L and use it as tex coords in an illumination map. how does this map looks like? how is it created?

Moshe Nissim

04-02-2002, 12:30 AM

I guess you are talking about Blinn bump mapping, since you mentioned the half vector H.

You may consider doing Phong bump mapping. It has advantage in interpolation of specular lighting (best to see in large flat areas), but disadvantage in performance, and need for two passes if you need color texture as well. A good guide can be found of all places in the NV_texture_shader spec itself. Look under the question: " Does this extension support so-called "bump environment mapping"?"

To your question, N o L and N o H are computed by the second and third, and fed to a 2d 'lighting' map bound to the third texture unit. (The first texture unit fetches the normals in standard 2d texturing). This map is really a composition of two 1d maps which can be though of as look-up-tables. The first table takes the N o H which is the specular angle cosine, and does the exponentiation. The second table takes the N o L which is the diffuse angle cosine and simply gives it back. In addition, the texture uses clamping in both coordinates (both 1d 'tables') so the texture lookup also performs the negative clamping (obtuse angles don't light).

The texture format is intensity-alpha -- a two component texture. This is because it needs to 'combine' the output of two 'tables'

The map contents are therefore simply:

Image [ s , t ] = { s ^ e , t }

where e is the specular exponent

intensity = s ^ e , alpha = t

This intensity and alpha are then available to the register combiners , which perform the lighting equation calculation -- combining 'material+lightSource' properties such as ambient color diffuse color, emission color, specular color (or intensity), texture color ( you can use the fourth texture unit for color texture lookup).

I managed to do it in two regsiter combiner stages (plus the final stage)

okapota

04-02-2002, 02:45 AM

so this way we can use any exponent we want for the specular. i mean, s^e, any e we want, unlike in geforce2 or 1 where must multiply s by itself in the reg combiners, so muximum is 4. right?

[This message has been edited by okapota (edited 04-02-2002).]

Yes, you can use any specular exponent you like with the DOT_PRODUCT_TEXTURE_2D texture shader style bump mapping. You can get a higher exponent than 4 with register combiners, but the artifacts begin to be bothersome above 8.

Also, you should be aware that the specular is somewhat sensitive to vector interpolation artifacts. Higher specular exponents will require more dense meshes to reduce the impact of denormalization of the interpolated H vector.

Thanks -

Cass

davepermen

04-02-2002, 04:48 AM

you can have a nice exponent of 32 if you want, and it does not look too artefacted..

http://tyrannen.starcraft3d.net/PerPixelLighting

just press 'n' in the demo to switch between approx ^32 and real ^32 (2passes)

Moshe Nissim

04-02-2002, 05:08 AM

yes, you can go to high exponents if you like.

You won't get the banding artifacts that appear with the successive squaring-truncating method (exponentiation in register combiners), since you compute the exponent when creating the table (texture) in float accuracty, and then truncate once.

It may be also possible to use the HILO texture format that outputs two 16-bit values, though I didn't look into how this output goes into the register combiners.Those are fundamentally 9-bit, so you'll have to do mighty tricks there..

Anyway, from my experience, I don't think the extra precision is necessary, and high exponents look nice and smooth (if you like your materials that way...)

okapota

04-02-2002, 05:41 AM

so the main difference between phong and blinn lighting, is that phong is using a refletion vector from somewhere to compute the specular, and is not tesselation dependent because it is possibile to compute reflection vectors per pixel with the texture shaders, and blinn uses half vector which is supplied per vertex and makes the method tesselation dependent. am i right?

Moshe Nissim

04-02-2002, 05:52 AM

Yes, you are basically correct.

To put it in a short sentence, Blinn has the half vector, and Phong has the reflected vector.

But there are many differences that come from that in the actual implementation.

The implementation we are discussing here (call it 'H'), does the vector math in local surface space.

The Phong implementation discussed in NV_texture_shader (call it 'P') implements transform from local surface space to 'light' space per pixel, using three texture stages doing dot3 op.

'B' uses one 2d texture object

'P' uses two cubemap texture objects

'B' is more sensative to vector shortening due to interpolation (Cass's point)

'P' is less sensative to that

'B' needs a vertex program to transform the H and L vectors into local surface basis (by the 3 basis vectors given for each vertex)

'P' needs a vertex program to transform the 3 basis vectors of the surface-local space to light-space (so the per-pixel transform takes the fetched normals from surface space directly to light space, where the cubemaps are built)

okapota,

The tessellation dependence of Blinn style specular comes from _what_ you interpolate, not because the vectors are supplied per vertex. I tried to implement tessellation independent Blinn specular on GeForce3 but it lacked just a little bit of flexibility. I'm pretty sure it can be implemented artifact-free on the GF4 TI ( and Radeon 8500 ). I just ordered a Radeon8500 exclusively for experimenting with specular ( and new lighting models in general ).

There's a thread that about the tessellation dependence here,

http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/003519.html

Moshe Nissim

04-02-2002, 06:26 AM

I think the basic visual problem with Blinn interpolation is not the normalization, but the following fact:

Assume a flat area or the bump map on the a triangle.

Assume an infinite viewer and infinite light lighting model.

The maximum of the specular cosine in Blinn is never inside the triangle. It is always on one on the vertices.

The maximum of the specular cosine in Phong, can be inside the triangle.

To see why: the H vector is the same for all three vertices (because light and viewer are infinite -- just directions). The three normals on the three vertices are N0 N1 and N2. Any point inside the triangle has three interpolation coefficients, a0,a1 and a2, a0+a1+a2=1

The interpolated normal is a0*N0 + a1*N1 + a2*N2 and the specular cosine will be

H o (a0*N0 + a1*N1 + a2*N2)

('o' is inner product)

whish is equal to

a0 * (N0 o H) + a1 * (N1 o H) + a2 * (N2 o H)

This epression attains maximum over a0,a1,a2 always at extermal values of (a0,a1,a2) , where two are zero and one is 1.-- at the vertices

On the other hand, the expression

ReflectVector( E, a0*N0 + a1*N1 + a2*N2) o L

(where ReflectVector(X,Y) reflects X around Y, E is the eye direction vector, and L is the light direction vector)

can attain maximum anywhere.

This is why Phong can have a nice circular specular highlight inside a triangle

The problem is that it's incorrect to linearly interpolate the H vector. You need to interpolate displacement-to-light and displacement-to-eye, then compute the H vector ( there are other correct ways, such as interpolating angles ).

Personally, I prefer Blinn style to Phong. Blinn highlights look more real as they move across surfaces.

Moshe Nissim

04-02-2002, 11:00 AM

PH, when the light source is infinite, and the viewer is infinite, the H vector is the same for all the vertices. Such lighting model is also supported (and fastest, and default (the infinite viewer)) in the fixed function OpenGL lighting

I agree, it's certainly valid http://www.opengl.org/discussion_boards/ubb/smile.gif.

davepermen

04-02-2002, 11:18 AM

yeah, its that often true, that, when i walk around, i'm infinite far away of the stuff i'm watching. and the lightsources i use to enlighten the objects are very often infinite far away, too http://www.opengl.org/discussion_boards/ubb/smile.gif thats why i can hold them in my hand or they hang infinite far away on my ceiling.. or i reed my new mail on my infinite far screen illuminating my infinite far from the screen around the screen placed room where i sit in infinite far away from it.. haha http://www.opengl.org/discussion_boards/ubb/smile.gif

Moshe Nissim

04-02-2002, 11:53 AM

Seriously, its not so easy to visually tell the difference between local viewer andinfinite viewer lighting models.

And look at the performance numbers of infinite vs. local light, you'll want to stick to infinite ...

davepermen

04-02-2002, 12:00 PM

never http://www.opengl.org/discussion_boards/ubb/smile.gif i know the speed-differences but who cares? me does, i don't want crappy unlogical stuff as a base in my engine http://www.opengl.org/discussion_boards/ubb/wink.gif and as i'll use vertex-programs probably, who cares? http://www.opengl.org/discussion_boards/ubb/wink.gif

Yes, vertex programs offer a huge performance increase when implementing per-pixel specular. In any case, vertex programs will likely not be the bottleneck.

Using an infinite viewer is really not a good idea ( unless you like the chrome effect in Half-Life ). When looking around by moving the mouse, the highlights should remain fixed on the objects, this requires a local viewer.

Anyway, my point about the interpolation artifacts was aimed at local lights and viewer. If you use an infinite viewer and infinite lights, there won't be any interpolation artifacts.

davepermen

04-02-2002, 08:36 PM

yes sure, but its theoretical stuff.. http://www.opengl.org/discussion_boards/ubb/smile.gif

Moshe Nissim

04-02-2002, 10:36 PM

Originally posted by PH:

. If you use an infinite viewer and infinite lights, there won't be any interpolation artifacts.

Yes there will be. That was exactly my point in the long post with the little math. Interpolation in Blinn will not produce specular highlights (maxima) inside triangles, whereas Phong will.

okapota

04-03-2002, 03:55 AM

well well, i lost you. anyway i got my answare. before i start philosifying about these methods, and go into the depth of all this math, i think ill better just code a few apps, and see if they work. maybe than ill have a clearer understanding.

PH, you ordered a radeon just for expirimenting? where do you have the money to buy such an expensive card just for expirimenting?

anyway, where is this phong shading described? in what presentation? i have them all, but i probably missed it.

Originally posted by Moshe Nissim:

That was exactly my point in the long post with the little math. Interpolation in Blinn will not produce specular highlights (maxima) inside triangles, whereas Phong will.

You also pointed out that the H vector would be the same at all vertices ( hence constant across the polygon ). Therefore the artifacts are not caused by interpolation. You're probably talking about per-vertex lighting ( if you supply the normals per vertex then you are correct, but we are talking about per-pixel lighting - the H vector supplied per-vertex, normals supplied via a 2D texture ).

Originally posted by okapota:

well well, i lost you. anyway i got my answare. before i start philosifying about these methods, and go into the depth of all this math, i think ill better just code a few apps, and see if they work. maybe than ill have a clearer understanding.

PH, you ordered a radeon just for expirimenting? where do you have the money to buy such an expensive card just for expirimenting?

anyway, where is this phong shading described? in what presentation? i have them all, but i probably missed it.

The Radeon 8500 is really not that expensive ( I paid almost twice that for my GeForce3 ). But that also means that my system is lacking in other areas http://www.opengl.org/discussion_boards/ubb/smile.gif.

Here's a thread on Phong specular ( Cass posted some code too ). That's probably the only infomation available,

http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/004436.html

davepermen

04-03-2002, 08:11 AM

ati radeon 8500 for 130$ found once in some american online shop..

thats not that expensive.. http://www.opengl.org/discussion_boards/ubb/smile.gif (compare with gf4ti http://www.opengl.org/discussion_boards/ubb/wink.gif)

okapota

04-03-2002, 09:06 AM

ok thanks. in israel everything is much more expensive, so it seems expencive to buy two new cards.

okapota

04-03-2002, 09:22 AM

i think i understand this phong style specular. but if we use the combiners to compute R, why cant we somehow use a tex shader operation that computes a reflection vector R for us, and than use this as a texture coordinate in a normcubemap, to normelize it, or, if it is allready normeliized just pass this vector to the combiners to compute R*L, or even compute that in the shaders, and use a texture lookup table, it is possibile right?

You're right, it is possible. The NVIDIA demo bump_reflect_local_light ( along those lines ) does just that. However, there's an error in the construction of the H matrix ( you'll notice it if you move the light around near the torus ). I don't think it has been fixed yet. I implemented it a while back but didn't come up with a solution ( I do plan on taking another look at it sometime ).

Paul

okapota

04-03-2002, 11:46 AM

so right now there is no perfect method, like in shadow volumes until recntly, right?

Moshe Nissim

04-03-2002, 02:06 PM

Originally posted by PH:

You also pointed out that the H vector would be the same at all vertices ( hence constant across the polygon ). Therefore the artifacts are not caused by interpolation.

They are caused by interpolation, the interpolation of the normals. (and also tangent and binormal

You're probably talking about per-vertex lighting ( if you supply the normals per vertex then you are correct, but we are talking about per-pixel lighting - the H vector supplied per-vertex, normals supplied via a 2D texture ).

per-pixel lighting doesn't necessarily mean bump mapping. You can have the first without the second. And bump maps also can have large flat areas, and this is where you see (or expect to see..) the nice specular highlight

Moshe Nissim

04-03-2002, 02:10 PM

Originally posted by okapota:

i think i understand this phong style specular. but if we use the combiners to compute R, why cant we somehow use a tex shader operation that computes a reflection vector R for us, and than use this as a texture coordinate in a normcubemap, to normelize it, or, if it is allready normeliized just pass this vector to the combiners to compute R*L, or even compute that in the shaders, and use a texture lookup table, it is possibile right?

This is what almost what I meant. You can be more efficient by letting the cubemap 'compute' (look up) (R*L)^e directly, not just normalizing.

okapota

04-03-2002, 11:19 PM

i think thats what i meant. is it?

davepermen

04-03-2002, 11:26 PM

right now there is a perfect solution: use ati radeon 8500 http://www.opengl.org/discussion_boards/ubb/smile.gif there you can do all the stuff incl perpixel variable exponent without bigger problems.. Can't wait for the next gpu from nvidia wich will try to top that.. (not like the gf4, the bugfix and speedup of a normal gf3.. http://www.opengl.org/discussion_boards/ubb/smile.gif)

Originally posted by Moshe Nissim:

They are caused by interpolation, the interpolation of the normals. (and also tangent and binormal

Yes, if you use per-vertex normals then obviously you're right. But why would anyone use per-vertex normals in per-pixel lighting ? The problem with per-vertex normals is that they don't correspond to the actual surface normal. There's no need to introduce additional artifacts by using interpolated normals.

In your original math post above ( infinite viewer and infinite lights, flat surface ), the interpolation artifacts can be solve quite easily using a 2D lookup table ( normals are implicit if you don't want bump mapping ).

per-pixel lighting doesn't necessarily mean bump mapping. You can have the first without the second. And bump maps also can have large flat areas, and this is where you see (or expect to see..) the nice specular highlight.

And this is possible with Blinn style specular too ( it's just more difficult with bump mapping but it's not a limitation of the lighting model ). It does require an approximate solution on most hardware ( except if using infinite viewer and infinite lights, in which case it works artifact-free on even very old hardware ).

Dave, I got my Radeon 8500 yesterday and currently trying out ATI's fragment shaders - very interesting stuff. This is a seriously impressive card. I'm even pleased with the drivers ( one possible minor bug discovered, wglSwapInterval doesn't work in windowed mode Win2000 ) but other than that the drivers appear to be great ( so far ).

I, too, am looking forward to NVIDIA's next card http://www.opengl.org/discussion_boards/ubb/smile.gif.

[This message has been edited by PH (edited 04-04-2002).]

Powered by vBulletin® Version 4.2.2 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.