André Pouliot wrote:
The logic already handle correctly when the operation go over infinite
and clearly under zero, it's more the case near zero, multiply an
unnormalized and normalized, multiply by zero and multiply by infinity
that are not well supported. Multiply by zero and infinity will be
resolved for the next version.
Just treat unnormalized as zero. Anything * zero = zero, anything else
* infinity = infinity. The graphics card needs to accept unnormalized
or infinite values as input and not crash, because it would slow down
the driver a lot if it had to explicitly check each coord before
sending. But it doesn't need to handle them perfectly, it's accepted
among graphics programmers that if you pass really small or really
big values into the graphics pipeline, wierd stuff will happen.
To remove the support for unnormalized number for the small value in the
beginning of the pipeline could affect the result 20 operations later
and produce artifact in the image. It would surprise me if it happen,
but I don't know if it's something we need to take into account or just
don't care.
Don't care. The graphics pipeline is short and doesn't suffer from
accumulated errors like scientific number crunching. Even if you
split the projection and modelview transformations, there's just
two multiply and add operations then a divide (or multiply by
reciprocal) to get device coords - which have to be rounded to int
anyway. Texture coords just have one multiply/add and then a scale
to power of 2 in the most complex case (texture matrix), and then
rounded to int.
--
Hugh Fisher
DCS, ANU
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
