John Wright wrote:
>
> Excellent explanation Justin! That was clear and understandable.
Ah, good. Maybe that should go in the FAQ then? - Oh, boys, put it in
the FAQ will ya! :) Actually, what would be good is to put in it with a
picture.
> My guess is that some of the weird effects that we see are because of
> the first part, "Is the entire polygon visible or not". With a little
> bit of float precision error as you turn the view, a vertex of a large
> polygon may flicker between visible or not visible.
This is a fairly good summary. There is also one extra part to add to
the explanation - and that is "why are floats inaccurate?".
There was a really good research paper by the MERL folks [1] a few years
ago dealing with high resolution, large-scale virtual environments, this
had some really nice pictures in it that illustrated the problem quite
well. I'd love to have those pics now, but I'll try to paint word
pictures instead.
Floating point numbers are really good at representing high-accuracy
values that are near 0, but are very poor as you get closer to infinity
or really close to zero. Floats are represented as a certain number of
bits of the actual number (called the mantisa) and a certain number of
bits that represent a power of 10 that the number is raised to (called
the exponent). Also add to this are two bits set aside for the sign of
the mantisa and exponent. Thus, for a 4 byte float, we have 22 bits of
mantisa, 8 bits of exponent and 2 sign bits (IIRC my IEEE specification
right).
As you can see we have one number raised to a power of another number.
There is always a fixed accuracy of the mantisa part. No matter how many
bits we place in the mantisa, the number of values that we can represent
with it is always fixed to the actual number of bits it uses (ie total
accuracy is 2 ^ #mantisa_bits). Now, when the exponenet is around zero,
you can see that we really have a very accurate system[2]. However, as
this accuracy is limited, the exponent becomes a multiplication factor.
Regardless of how we look at it, the mantisa is still an approximation.
The multiplication that the exponent performs also mutliplies the
approximation too. Therefore at really large exponent values, instead of
having a difference between real values of .0000000000.....1, it becomes
a value of 10000....0.0. Thus, even integer values get rounded up or
down by some accuracy amount. What this ends up doing is producing a
stepped value where a really large (or really small) value gets
represented by something approximately close.
The visual picture that MERL used was a bunch of objects placed at
regular intervals. When we have a small exponent, these objects always
stay at regular separation. As the exponent increases to large values,
even though the mantisa stays the same, the objects start to bunch
together. We still have the same number of objects, but the inaccuracy
of the representation means that we end up bunching them together. The
technical term is called jitter.
So, why does this effect 3D graphics rendering? Well, for every frame we
have an absolute shitload of floating point calculations. Each time we
do floating points calcs, we stuff around with both the mantisa and
exponent values. The cumulative effects of these get to us -
particularly when we start getting really, really small or large
numbers. When the numbers get really small, this clustering effect takes
place.
The visual effects of tearing are what happens when we try to determine
if two polygons are crossing or not - in particular when looking for
boundary conditions like intersecting polygons as the approach being
parallel . Which one is deeper? We need to a pile of matrix math here
that starts to look for intersection values. We obviously can't do this
with integer math, and as items become closer to parallel we start
working with smaller and smaller numbers (ie closer and closer to zero
with increasingly larger exponent values (negative signed)). The closer
to zero you get, the worse the problem becomes and the more likely you
are to end up with inaccurate results.
The end product - crap looking 3D graphics.
The moral to the story - don't have a lot of intersecting polygons.
Deliberately go around and break them up into individual ones. Where you
see two polys intersecting, break them into 4 (or more) separate ones.
This will guarantee a much better looking picture.
[1] Mitsubishi Electronics Research Labs
[2] Still less than an int using the same total number of bits though.
It allows better representation of fractional numbers, but the actual
accuracy of the representation of a given integer value (ie no
fractional component) is worse.
--
Justin Couch http://www.vlc.com.au/~justin/
Freelance Java Consultant http://www.yumetech.com/
Author, Java 3D FAQ Maintainer http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
- Greg Bear, Slant
-------------------------------------------------------------------
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
