Re: Dynamic Object paging

New Message Reply Date view Thread view Subject view Author view

moore++at++WOLFENET.com
Wed, 26 Mar 1997 11:36:29 -0800 (PST)


   From: jason++at++cerebus.cambridge.com (Jason Williams)
   Date: Wed, 26 Mar 1997 09:50:26 -0500

> > We have a situation, where we need to support potentially thousands of
> dynamic
> > objects which will come and go from our scene. We wanted to subclass
   various
> > pfNode types to represent our dynamic objects. The question is, since
> pfNodes
> > need to have seperate memory copies maintained, would there be alot of
> overhead
> > when using a huge number pfNode types which are created and deleted fairly
> > often?. What if they weren't in the scene graph but the geometry was
   culled
> > and drawn by a different method, but the pfNodes are used to create the
   gsets
> > in seperate cull and draw processing? Should we abandon the pf class
   objects
> > altogether for representing our dynamic objects in favor of pr defined
> objects?
> >
> >

Most overhead will come from object update (including
creation and deletion). If you're updating every object (with
articulated parts) every frame then you've got a problem. You may
find it advantageous to do some range-based culling of your own
in addition to Performer's: remove objects that are out of range from
the scene graph and don't update their DCSs or geometry.

It should be straightforward to write a benchmark that tests the
overhead of dealing with thousands of objects.

I'd make sure that standard Performer techniques plus the above don't
work before doing your own pr-based objects; that sounds like a big
pain in the butt.

Tim
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com


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:54:57 PDT

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