{laugh} Well Dave, we are here to entertain you. {grin}
Justin... sigh... I guess we all show the bias of our backgrounds.
Having been taught to program by a mathematician father over thirty
years ago the issue of float precision is old news to me. Float issues
were one of the first issues I dealt with in my career when I wrote
payroll programs that used integers to maintain precise dollar amounts
while other fools were busy watching strange results because of float
round off. It never occurred to me that anyone on this list wouldn't
fully understand the issue.
As for unfamiliarity with ZBuffer... hmmm... I'll admit I'm a relative
3D newbie (having not been exposed to 3D before Java 3D) I did think I
knew the basics of how it works (it's nicely described in "Real Time
Rendering"), but the issues that you mentioned and now claim as just for
illustrative purposes tend to indicate that none of us know the exact
algorithms used and that they might indeed vary from API to API and
driver to driver.
- John
David wrote:
>
> I just love you guys.
>
> *sniff*
>
> Group Hug!
>
> Dave
> ----- Original Message -----
> From: Justin Couch <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, May 08, 2001 7:27 PM
> Subject: Re: [JAVA3D] Grafic card question
>
> John Wright wrote:
> >
> > Oh gawd Justin, we don't seriously need to explain why floats have
> > precision problems do we?
>
> Yes and no:
>
> 1. I was bored and didn't feel like doing anything else at the time (ie
> trying to avoid the other big piles of work I have to do)
>
> 2. You didn't seems to know the basic concepts of Zbuffer handling so I
> assumed you probably wouldn't know why floats cause so much problems.
>
> 3. General interest for the others on the list. Plenty of non electrical
> engineers on the list. I only learnt about float representation and
> low-level handling in my engineering degree. The comp-sci degree never
> even mentioned it so I assume a lot of other people don't know these
> basic principles - particularly here on this list were we tend to get a
> lot of people from the content side of life rather than the programmer
> that can compute matrix transforms in thier sleep.
>
> > 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.
>
> Exactly, and that's why I said is was a very simplified algorithm to
> illustrate the points. You will find that no-one implements hardware
> like that.
>
> > 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.
>
> That's a fairly rough summary. It is more the problem of intersecting
> and lots of nearly parallel polygons that are really close together that
> are the problem.
>
> --
> 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".
===========================================================================
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".
