June 2001
Incremental
Tessellation -- Cont'd page 4
by Alex
Macris
Normal generation
It’s clear that if
dynamic lighting is not essential in your game, try to
do without because generating vertices normals is very
expensive. We can turn it from very expensive to just
expensive just by reusing what we’ve done.
The traditional way to generate normals is to
interpolate the two tangents (u and v) for
each vertex generated then to compute the cross product
of those two tangents and to normalize the result:
Now the full trivial
implementation in Listing
4.
The most evident
optimization is to leave both tangents independent and
to keep the cross product as is. We just have to replace
the dots products needed to obtain the tangents by the
incremental system as we’ve seen earlier. This is done
in listing 5.
There is a more
attractive choice. Cross product and normalization are
two operations that are not very SIMD friendly. Let’s
try to eliminate them. What do you think of a vector
containing the X,Y,Z values of the normal (before
normalization) and the square length of the vector in
the W field :
Don’t worry about
inverse square root. It has become a quite cheap
operation in up to date hardware.
Let’s start considering
the cross product:
That’s a big calculus
but unfortunately we can’t deal without it.
What have we learned? We
know now that we can calculate the non normalized normal
just by making the dot product of two 5D vectors:
Here we are. But
unfortunately we’ve reached the limit of this solution
here. And I have no alternative…
First disappointment: the
calculation of W (square length of the non normalized
normal vector). This calculation needs the evaluation of
an order 10 polynomial:
It’s difficult to
justify the extra cost of such a calculation that is of
5 adds (plus 5 adds for the calculation of the normal)
using the incremental method.
Second disappointment,
the incremental computation of G in the outer loops is a
pure headache. Even if the solution were accessible, it
would introduce 30 adds in the outer loop and a very
huge amount of setup calculation. Quite difficult to
recoup the cost to itself…
Finally, letting the
calculation of G inside the outer loop costs
about 12 cross products. This means that it is
profitable only if you subdivide your patch at least 12
times (i.e. NumberOfUVertices > 12 ).
My personal conviction is
that we are in a dead-end. I don’t know any way to
refine this solution. Perhaps you do.
One could interpolate the
normals instead of the tangents. Of course, this doesn’t
give you an exact mathematical result but it could be
sufficient for your needs.
Texture coordinates
generation
Some good news now:
Texture coordinates generation is cheap. And double
texturing is even cheaper.
Texturing a patch is
quite simple. A texture coordinate (textureU,textureV)
is associated to each one of the four corners of a
patch. A simple linear interpolation between those four
points gives you the texture coordinates anywhere on the
surface. The words linear interpolation should
remind you something. Remember the early times of
software rendering… Triangle texturing was done by
interpolating linearly the texture coordinates. Nothing
different here.
<<<Back
Continue >>>
|
