Re: fast isect when inside geometry

New Message Reply Date view Thread view Subject view Author view

Kowsik Guruswamy (kowsik++at++coryphaeus.com)
Tue, 30 Apr 1996 11:47:23 -0700

On Apr 30, 2:03am, Sharon Clay wrote:
> Subject: Re: fast isect when inside geometry
> +>---- On Apr 17, 2:54pm, Dwight Meglan wrote:
> > Subject: fast isect when inside geometry
> ->
> ->I would like to get comment on the best way to quickly do intersection
> ->testing for moving about inside of a large chunk of geometry. By large I
> ->mean around 50,000 polygons. By moving around I mean that I want to steer
> ->the camera about at 15-30 Hz (preferably on an Impact but I can fallback to
> ->an Onyx) and be constrained to within the boundaries of the geometry.
>
> If you don't absolutely have to have results every frame, you might consider
> forcing a forked intersection process so that if the intersections
> take a long time, they won't be so likely to hold up the drawing.
>

[snip]

> This is true. And, if you use pfPartitions, your search for the proper
> pfGeoSet will be _very_ fast indeed.
>

[snip]

> Since the size of pfGeoSets is also going to effect your drawing efficiency,
> you don't want them tooo small. I'd say a minimum of 12 tris per
> pfGeoSet and this is really assuming that you are on a low-end gfx system
> that is not easilty host limited. Since you say you are on an IMPACT, I'd
> expect that you are more likely fill limited. Generally, for high-end
> systems, I'd say the good range is more like 24-64 tris.

[snip]

> If the segments have reasonable spatial locality and direction, put
> them together and put a cylinder around them.
> Otherwise, use partitions and do them separately so that you don't have
> to intersect lots of polygons with segments that have no chance of making a
hit.
>
> One might also ask if _all_ of the segments require polygon intersection
> information - maybe for some segments you can stop at just PFTRAV_IS_GEODE
> for bounding sphere or PFTRAV_IS_GSET for bounding box intersections for
> setting your pfNodeTravMask().
>
> Also, I am sure that you know this but just to be complete, be sure
> to enable isect caching on static pfGeoSets with the PFTRAV_IS_CACHE bit
> set in your setMode to pfNodeTravMask().

If I may add, since Performer uses separate masks for APP, CULL, DRAW and ISECT
and because of the fact that a set of geometry that's tuned for rendering may
not be the most efficient set for collision, you might think about a simplified
set of geometry [with lesser number of polygons] for the ISECT process.

This definitely means more memory, but the benefits of having a specialized set
of geometry just for collision might be worthwhile considering.

K.

-- 
kowsik++at++coryphaeus.com     | pirts suiboM a hguorht neeb sah txet sihT
http://www.coryphaeus.com |
                          | You are not you, you are me! - arnie
work: (408)-395-4537 e201 |

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:49 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.