Faceted tangent space problem

I can understand people not wanting to trawl through my other post again, looking for my latest problem - so I thought I’d start a new thread…

I’ve got another problem.
I’ve uploaded another image, showing the problem - it’s the top image in grey scale… http://www.geocities.com/pixelshaderman/
Can anyone suggest to me why the facets are so obvious?
This is how I calculate the tangents (same goes for binormals):-

for (every vertex)
set each vertex’s tangent vector to zero

for (every triangle)
calculate surface tangent
add this surface tangent to each of the 3 vertices tangent vector

for (every vertex)
normalise tangent vector

This should give me a tangent vector for every vertex which is the average of all the triangles that share that vertex.

I generate all 3 tangent space axis this way (normal/tangent/binormal)

Am I doing something wrong?

Sounds right. How do you interpolate values across the polygons during rasterization?
This is critically important and I’d guess that’s what is going wrong.

I’ve been thinking about this one - I use the col0 and col1 to interpolate the light and halfangle vectors across the triangles.
Having never seen this approach used in other demos, I decided to swallow my pride, abandon the col0/col1 approach, and use a normalisation cube map in 2 texture units (what a waste, but there you go).
Anyway, now things look much smoother - and I mean MUCH smoother, but my frame rate has dropped significantly.
Is there no way I can get smooth perpixel lighting using the col0/col1 interpolation approach?

I’d have expected your color interpolation to work. The problem must be the way you’re transforming them at the vertices. Are you sure you have fully shared coordinate frames at the vertices? You need to share normal and binormal vectors as well as the tangent vectors.

If one of these is unshared I expect the tangent space positions after the transformation would differ leaving you with the faceted artifacts.

Also make sure that your glShadeModel is set to smooth, but that’s a bit obvious.

Finally if you still have problems turn off the DOT3 and draw the vectors as colors directly, there should be no faceting artifacts in the vectors, if you see some it will help you isolate the problem to a specific vector or component.

[This message has been edited by dorbie (edited 11-24-2002).]

Is there no way I can get smooth perpixel lighting using the col0/col1 interpolation approach?

The problem with using the primary and secondary color interpolators, is that they get clamped to the range [0, 1]. So they’re a bit crap for interpolating vectors with. You can’t have negative values.

Thats why you need to use the texture coordinate interpolators, as these aren’t clamped before interpolating.

Thats my understanding of it anyway.


Yes you can get negative vectors - you colour compress them to the 0-1 range before outputting them to the colour stream. Then, in the register combiners, you expand the interpolated version, then normalise it.
You just have a reduced precision (8bit rather than 32bit, as far as I know), but this shouldn’t really be a problem for smallish polys.
And, as a big plus, you can do diffuse + specular perpixel lighting using zero texture units. And bumpmapping diff+spec perpixel using 1 texture unit. And bumpmapping diff+spec and decal texture and rough environment mapping in 3 texture units. This is in one pass. And of course, this is on a gf3 or above (requiring a lot of general combiner stages).

Mind you, ark at me - I can’t even get simple specular working properly with the norm cube maps…

[This message has been edited by inept (edited 11-24-2002).]

Yep ofcourse you can get this working. The range of color values is not the problem in this case. You can adjust it back to -1 to +1 just as you would an unsigned bump texture for example.

Just a thought: at which point in the lighting calculation are you normalizing your view and half-angle vectors ( and as extension, the view vector ) ?

Your B, T, N vector normalization is already clear from your pseudocode.