Oh gawd Justin, we don't seriously need to explain why floats have
precision problems do we?
I'm more interested and concerned about how these techniques can lead to
really bizarre images. Take your explanation for example, if we have
one large polygon that has each of it's vertices obscured by small
polygons then we make the decision that it is "not visible" however
we've failed to account for the HUGE gap between the obscuring little
polygons.
Hence we are either at risk for some really ugly effects or we need a
more sophisticated method for determining if an entire polygon is not
visible or not. In my opinion the moral of the story is that if your
scene is made up of lots of large polygons you'll have worse Zbuffer
problems than small polygon objects.
- John
Justin Couch wrote:
>
> 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".
===========================================================================
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".
