Mike Bandy wrote:
>
> Until you fix your FAQ, can you tell us what Z-buffer tearing is?
>
> Thanks.
Imagine a rubber ruler, 1 meter in length without stretching. The (32
bit) ruler has 4294967296 markings on it. Now you can only use these
markings to measure the distance objects are away from each other, and
cannot look up .5 or anything else, so you always round to the nearest
marking.
If you don't stretch the ruler, you can only see objects 1 meter away,
because you have no way of knowing how far the other objects are away
from the view.
If you want to only see 1 meter in front, then your objects should be
fine, as long as none of the surfaces are < 2,3283064365386962890625e-13
mm wide, and are touching other surfaces in the same measurement
bracket. This is good enough for most applications.
But if you stretch the ruler very far , from here to the moon, then many
objects being measured will appear the same distance from the view,
because each measurement gap or bucket is larger. Now if those objects
are slanted away from the view, the following happens
<ascii-mation>
Object|A
| | | v | << Measurements on ruler
//
- //
X //
- //
| //|
air // object B
//
- //
X //
- //| |
//
//
//
</ascii-mation>
Object A is a very thin object directly over object B, as you can see,
the areas marked X clearly shows that object A is in front of object B,
however, where the cross sections of the objects reside in the same
measurement, there is no way of knowing which is closest, so the abject
behind is drawn in front of the object covering it, only at the points
where they reside in the same zbuffer group.
Sorry if I over simplified it.
Perhaps "Z tearing is when the front of one object appears in the same
zbuffer region as another object, which would lead the other object
being drawn in front because the Z values would be the same, java3d
wouldn't redraw over the same pixel" would have been sufficient.
=)
Moral of the story, make everything wider than your ZBuffer bucket, and
make sure your ZBuffer bounds are only as big as necessary.
Hope it helps, and take the math with a pinch of salt.
Chris
>
> > > What is the cause? And what is the best way to insure it
> > doesn't happen?
> >
> > Classic case of Z-buffer tearing.
> >
> > I thought I had a question about this in the FAQ, but can't
> > seem to find
> > it. Must fix....
> >
>
> ===========================================================================
> 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".
--
----------------------------------------------------------------
Christopher Davies levigo software gmbh
Java Software Developer Max-Eyth-Strasse 35
E-Mail: [EMAIL PROTECTED] D-71088 Holzgerlingen
Tel: +49 7031 4161 358 ein unternehmen der levigo gruppe
aus cogito und BMS wurde levigo - mehr infos unter www.levigo.de
===========================================================================
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".
