holy grail bump mapping

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 .

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

ati radeon 8500 for 130$ found once in some american online shop…
thats not that expensive… (compare with gf4ti )

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

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

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

Originally posted by PH:
[b] 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.

[/b]
They are caused by interpolation, the interpolation of the normals. (and also tangent and binormal

[b]
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 ).

[/b]
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

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.

i think thats what i meant. is it?

right now there is a perfect solution: use ati radeon 8500 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… )

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 .

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