Re: Lines disappear--They were getting culled.

New Message Reply Date view Thread view Subject view Author view

Brian Furtaw (brian++at++sgi.com)
Thu, 14 Nov 1996 14:00:17 -0500

These sound like good insights Steve, I'll keep in mind that when you change
the bounding box it has to recompute all the way up the tree. Luckily I have
maintained a very flat tree. The Geode for the cables is at the top of the
Group right below the DCS that changes the point of view. So no other bound
boxes should be effected. Computing a large bounding box to cover all
posiblities is not partical the cable Geode is attached to to moving vessels. I
can live with the lines not being culled for right now. I would however like to
discover why I can't need to do cull testing on these vertices.

Brian

On Nov 14, 10:32am, Steve Baker wrote:
> Subject: Re: Lines disappear--They were getting culled.
>
> Brian Furtaw (brian++at++sgi.com) is having problems with lines
> disappearing. I think I can summarise what's going on:
>
> 1) He is using cyclebuffers to sync his vertex updates
> (presumably in APP) with the DRAW process. This is good.
>
> 2) Since he is changing his vertex coords, he must also
> recompute the bounding volume - since Performer doesn't
> do that for you. This is good too.
>
> I don't think that Performer knows how to take the bounding
> box for a pfGeoSet from a cyclebuffer - so isn't there a
> problem with the synchronization of the bounding volume change
> with the vertex update?
>
> Brian - you also need to be aware that if you change the bounding
> volume of an object that is deep within the database tree, Performer
> has to go and recompute all the bounding volumes of the nodes above
> the one you are changing. This can be time-consuming.
>
> Making the bounding volume big enough to contain all possible
> positions of the GeoSet vertices is often the best solution -
> it depends on the amount of geometry in that node which would be
> passed on to GL unnecessarily when the overly-large bounding
> volume is on-screen, but the geometry isn't.
>
>
>
> 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++at++MrEd.bgm.link.com (eMail)
> http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve
(intranet)
> http://web2.airmail.net/sjbaker1
    (external)
>
>
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Steve Baker

-- 
o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o


Brian Furtaw  (brian++at++sgi.com)	
VisSim  Technical  Consultant
12200-G  Plum  Orchard  Drive	Office:	(301)572-3293  Fax: (301)872-3293	
Silver Spring, Maryland 20904	OpenGL/ImageVision/OpenInventor/Performer
=======================================================================
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:53:57 PDT

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