fly/flightgear
1
0
Fork 0
Code Activity
flightgear/Hints/aaa
curt 29f6d05875 Initial revision
1999-04-05 21:32:32 +00:00

306 lines
13 KiB
Text
Raw Blame History

From fatcity!root@news.cts.com Wed Aug 20 16:34:24 1997
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["3412" "Wed" "20" "August" "1997" "14:14:39" "-0800" "Steve Baker" "steve@mred.bgm.link.com" nil "83" "Re: culling with view frustrum before view transformation" "^From:" nil nil "8" nil nil nil nil nil]
nil)
Received: from mailhub.cts.com (mailhub.cts.com [204.216.216.130])
by meserv.me.umn.edu (8.8.6/8.8.6) with SMTP id QAA04291
for <curt@me.umn.edu>; Wed, 20 Aug 1997 16:34:23 -0500 (CDT)
Received: from donews.cts.com(really [192.188.72.21]) by mailhub.cts.com
via smail with smtp
id <m0x1IGC-000Y2Ba@mailhub.cts.com>
for <curt@me.umn.edu>; Wed, 20 Aug 97 14:25:48 -0700 (PDT)
(Smail-3.1.92 1996-Mar-19 #3 built 1996-Apr-21)
Received: from fatcity by donews.cts.com with uucp
(Smail3.1.29.1 #5) id m0x1IG4-000007a; Wed, 20 Aug 97 14:25 PDT
Received: by fatcity.com (06-Aug-97/v1.0d-b55/bab) via UUCP id 0C90BB6D; Wed, 20 Aug 1997 14:14:39 -0800
Message-ID: <F001.0C90BB6D.19970820141439@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: steve@mred.bgm.link.com (Steve Baker)
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0d, build 55; ListGuru (c) 1996-1997 Bruce A. Bergman
Precedence: bulk
From: steve@mred.bgm.link.com (Steve Baker)
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: culling with view frustrum before view transformation
Date: Wed, 20 Aug 1997 14:14:39 -0800
> >Brian Hook wrote:
> >> You can do bounding spheres,
> >> bounding boxes, or a combination of both (sphere first, then box).
> >
> >Which is faster to test for being completely inside, outside, or
> >partial, of the view frustrum?
>
> Obviously bounding sphere will be the fastest, but since it's, well, a
> sphere, it's not going to be particularly accurate (since it's rotationally
> invariant).
>
> if ( distance( obj.position, plane ) >= obj_sphere.radius )
> trivial_reject = true;
>
> (I assume you also check the sign of the distance)
I echo your sentiments that bounding spheres are the fastest approach to
culling to FOV frustum - also for some kinds of collision detection.
The most important thing to bear in mind about culling is that the first
trivial-reject test you apply is by far the most time-critical. This test
is always applied to more nodes than any of the subsequent tests.
So, do the cheapest test first.
This is typically the NEAR plane test. Everything behind the viewers head
gets chopped out - and it's an especially cheap test.
if ( obj_sphere.center.z < near_plane - obj_sphere.radius )
REJECT!!
...next do the second cheapest test (assuming you know that your database
could possibly beyond the far clip plane)...
if ( obj_sphere.center.z - obj_sphere.radius > far_plane )
REJECT!!
...and *then* do...
if ( distance( obj.position, plane ) >= obj_sphere.radius )
REJECT!!
It's also useful to know that in many applications, you cull more objects from
the left and right faces of the frustum than you do from the top and bottom - so
test left, then right, then bottom then top.
Also, with bounding sphere tests, you shouldn't forget to do total-accept
as well as total-reject tests. Once you know that an object's sphere is
TOTALLY on screen, you don't have to descend into the daughter objects to
cull-test them...you *know* they are all on-screen.
Another way to look at that it to remember which of the six possible plane tests
didn't even touch the sphere - as you work your way down the object hierarchy,
you can accumulate those flags and avoid even testing those planes that a parent
sphere has already cleanly passed. If you do this then a vast percentage of
your spheres will only need to be tested against one plane.
Sphere-based culling can be extremely cost-effective. It's so cheap that even if
you feel the need to use a bounding cubeoid (or even a yet more complex shape),
it's still worth doing a sphere-based cull first just to get rid of the trivial
accept and reject cases.
Steve Baker 817-619-1361 (Vox-Lab)
Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail)
2200 Arlington Downs Road 817-619-4028 (Fax)
Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail)
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
** Beware of Geeks bearing GIF's. **
--
Author: Steve Baker
INET: steve@mred.bgm.link.com
Fat City Network Services -- (619) 538-5030
San Diego, California -- Public Internet Access
-------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).
From fatcity!root@news.cts.com Thu Aug 21 09:19:20 1997
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["2834" "Thu" "21" "August" "1997" "07:00:54" "-0800" "Steve Baker" "steve@mred.bgm.link.com" nil "77" "Re: culling with view FRUSTUM before view transformation" "^From:" nil nil "8" nil nil nil nil nil]
nil)
Received: from mailhub.cts.com (mailhub.cts.com [204.216.216.130])
by meserv.me.umn.edu (8.8.6/8.8.6) with SMTP id JAA02567
for <curt@me.umn.edu>; Thu, 21 Aug 1997 09:19:20 -0500 (CDT)
Received: from donews.cts.com(really [192.188.72.21]) by mailhub.cts.com
via smail with smtp
id <m0x1Y1o-000Wd7a@mailhub.cts.com>
for <curt@me.umn.edu>; Thu, 21 Aug 97 07:16:00 -0700 (PDT)
(Smail-3.1.92 1996-Mar-19 #3 built 1996-Apr-21)
Received: from fatcity by donews.cts.com with uucp
(Smail3.1.29.1 #5) id m0x1Y1f-0000Qaa; Thu, 21 Aug 97 07:15 PDT
Received: by fatcity.com (06-Aug-97/v1.0d-b55/bab) via UUCP id 0C90BDD1; Thu, 21 Aug 1997 07:00:54 -0800
Message-ID: <F001.0C90BDD1.19970821070054@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: steve@mred.bgm.link.com (Steve Baker)
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0d, build 55; ListGuru (c) 1996-1997 Bruce A. Bergman
Precedence: bulk
From: steve@mred.bgm.link.com (Steve Baker)
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: culling with view FRUSTUM before view transformation
Date: Thu, 21 Aug 1997 07:00:54 -0800
> OK, this is probably explained in books etc., but what is the fastest way
> to find the distance between a point and a plane?
A plane can be represented by the equation
Ax + By + Cz + D = 0 ;
A,B,C is just the surface normal of the plane and D is the shortest
distance from the origin to the plane.
So, if you need to find the distance of a point from the plane, just
imagine a new plane that goes through your test point and is parallel
to the plane you want to test. The plane equation of that new plane would be:
A'x + B'y + C'z + D' = 0 ;
Since the two planes are parallel, their surface normals are the same, so
A' == A
B' == B
C' == C
D' == D + distance_between_the_two_planes
...the only thing that's different is their D values - which differ by the
distance of your test point from the original plane.
So, for a point (x,y,z), the distance from the plane (A,B,C,D) is
dist = D' - D
= -A'x - B'y - C'z - D
= -Ax - By - Cz - D
= -( [ABC]dot[xyz] + D )
That's the general result - but culling to the view frustum is a very
special case...if you are working in eye-relative coordinates (IMHO this
is best), then since all top,bot,left,right planes of the frustum meet
at the eye - and since the eye is at the origin (by definition), then
D is always zero for those plane and that saves you a subtract.
If you are feeling even more in need of optimisation - then you can save one
multiply per plane by realising that (for rectangular screens) one of the
three components of the plane equation will always be zero.
eg for the LEFT clip plane, the Y component of the normal of the plane
is zero, so the distance to the left or right plane is just
- ( A x' + C z' )
and to the top or bottom plane it's just:
- ( A x' + B y' )
Since you are only using this for culling, you don't need the minus sign
so the cost of a test can be as little as two multiplies and one add
per plane.
Steve Baker 817-619-1361 (Vox-Lab)
Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail)
2200 Arlington Downs Road 817-619-4028 (Fax)
Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail)
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
** Beware of Geeks bearing GIF's. **
--
Author: Steve Baker
INET: steve@mred.bgm.link.com
Fat City Network Services -- (619) 538-5030
San Diego, California -- Public Internet Access
-------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).
From fatcity!root@news.cts.com Fri Aug 22 08:51:10 1997
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["2087" "Fri" "22" "August" "1997" "06:31:24" "-0800" "Steve Baker" "steve@mred.bgm.link.com" nil "47" "Re: culling with view FRUSTUM before view transformation" "^From:" nil nil "8" nil nil nil nil nil]
nil)
Received: from mailhub.cts.com (mailhub.cts.com [204.216.216.130])
by meserv.me.umn.edu (8.8.6/8.8.6) with SMTP id IAA21767
for <curt@me.umn.edu>; Fri, 22 Aug 1997 08:51:09 -0500 (CDT)
Received: from donews.cts.com(really [192.188.72.21]) by mailhub.cts.com
via smail with smtp
id <m0x1u2d-000Wk7a@mailhub.cts.com>
for <curt@me.umn.edu>; Fri, 22 Aug 97 06:46:19 -0700 (PDT)
(Smail-3.1.92 1996-Mar-19 #3 built 1996-Apr-21)
Received: from fatcity by donews.cts.com with uucp
(Smail3.1.29.1 #5) id m0x1u2a-0000PHa; Fri, 22 Aug 97 06:46 PDT
Received: by fatcity.com (06-Aug-97/v1.0d-b55/bab) via UUCP id 0C90C1C4; Fri, 22 Aug 1997 06:31:24 -0800
Message-ID: <F001.0C90C1C4.19970822063124@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: steve@mred.bgm.link.com (Steve Baker)
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0d, build 55; ListGuru (c) 1996-1997 Bruce A. Bergman
Precedence: bulk
From: steve@mred.bgm.link.com (Steve Baker)
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: culling with view FRUSTUM before view transformation
Date: Fri, 22 Aug 1997 06:31:24 -0800
> > > Actually, I find it easier to scale the whole such that D = 1, then you
> > > only need to store the non-degenerate (A', B', C') vector (i.e., A' =
> > > A/D, etc...). Storing a already-normalized (A, B, C) + D quadruple is
> > > worth it only if you know before hand that the planes will never be
> > > scaled before their normals are used. In the general case where a
> > > scaling is possible, you'll have to renormalize anyway.
> >
> > Normally, I might agree with you - but in the case of Frustum clipping,
> > scaling the normal by dividing by 'D' is a bad move since D==0 in the
> > case of all four 'interesting' planes. :-)
>
> Interesting point. This is of course only true when the eyepoint is in
> the origin, which brings us back to the issue of clipping before or
> after the modelview transformation.
Well - that's a dangerous thing to assume - I mean, the eye might just happen
to move to the true world coordinate origin (by flook) and crash your program
with a bunch of divide by zero errors.
In any case, you are going to run into nasty precision problems as your eye
approaches the origin - even if it doesn't reach it.
> Learn something new every day.... :-)
...Forget something important every night... :-)
Steve Baker 817-619-1361 (Vox-Lab)
Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail)
2200 Arlington Downs Road 817-619-4028 (Fax)
Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail)
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
** Beware of Geeks bearing GIF's. **
--
Author: Steve Baker
INET: steve@mred.bgm.link.com
Fat City Network Services -- (619) 538-5030
San Diego, California -- Public Internet Access
-------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).
View git blame Copy permalink