Triangle setup

Well, it seems like most games aren't using triangle strips. In a study we made of OGL and D3D games only Oblivion seemed to masively use triangle strips (75% of the benchmarked geometry).
Yeah, an alternative that would also work for indexed geometry is to keep a small cache of cross product coefficients from vertex pairs forming edges. These can then be used to compute the matrix inverse the classical way. In the best case, when the cross products for two edges are already in the cache, it would be even faster than the approach above.

But that's just theoretical... :D
 
Yeah, an alternative that would also work for indexed geometry is to keep a small cache of cross product coefficients from vertex pairs forming edges. These can then be used to compute the matrix inverse the classical way. In the best case, when the cross products for two edges are already in the cache, it would be even faster than the approach above.
You also get to the situation where the storage costs for the computed edge values are greater than the hardware needed to recompute those values.
 
You also get to the situation where the storage costs for the computed edge values are greater than the hardware needed to recompute those values.
That's exactly why I added that it's just theoretical. ;)

I think I did find a more practical result though: To compute the classical matrix inverse, a division by the deteminant is required. This takes 1 reciproke, 12 multiplications and 2 addtions. I believe this can be eliminated altogether. Without dividing by the determinant d, instead of computing u/w and 1/w we'd be computing d*u/w and d/w. Per pixel we're computing (d*u/w)/(d/w) = u.

Looks like a win-win to me...
 
That's exactly why I added that it's just theoretical. ;)

I think I did find a more practical result though: To compute the classical matrix inverse, a division by the deteminant is required. This takes 1 reciproke, 12 multiplications and 2 addtions. I believe this can be eliminated altogether. Without dividing by the determinant d, instead of computing u/w and 1/w we'd be computing d*u/w and d/w. Per pixel we're computing (d*u/w)/(d/w) = u.

Looks like a win-win to me...
What about back-face culling? You still have to compute most of it.
 
What about back-face culling? You still have to compute most of it.
Not "most", it only takes three multiplications and two additions, but yes I forgot to include it. So in total we can save 1 reciproke and 9 multiplications. Still not bad in my opinion, and it's beneficial for precision as well.
 
Back
Top