From: Juan Pablo Gómez (jpgomez++at++espelsa.es)
Date: 02/25/2002 01:19:55
Thank You.
After some experiments, we have determined that the time taken
in pfSync is linearly proportional to the number of pfGeoSets. If we
leave the same number of nodes (pfNodes and derived) without any
pfGeoSets, the delay disappears.
As far as I know, only libpf objects (pfNode and derived) are duplicated
down the process pipeline, not libpr objects (such as pfGeoSet).
Therefore, I think that there are few chances that the first step is the
lengthy one.
We have tried to manually set a BSphere to all nodes with
pfNodeBSphere(node, sphere, PFBOUND_STATIC), but time taken
remains the same.
This is a problem for us, because it takes much more time than
our code reading data files and generating that geometry. Is there
any way to get debug information to learn what is happening inside
pfSync()? Is there a way to manually provide results to pfSync() to
avoid lenghty calculations (such as precomputed BSpheres)?
Thank You.
Javier
> Hello There !
>
> Any call to pfSync does the following:
>
> - process new nodes. Make clones of each new node for each downstream process
> (CULL, ISECT).
> - process pending mergeBuffers requests from a DBASE process.
> - clean (compute dirty bounding boxes)
> - APP callback traversal (all nodes with APP func)
> - clean (compute bounding boxes that the APP callback dirtied)
> - wait for start of next frame.
>
> In your case, I expect the first stage to take a long time. Each new node
> you created has to be cloned for the ISECT process (if forked) and for every
> CULL process.
>
> pfSync is slow in frames where you introduce many new nodes from inside
> the APP process (not only in the first frame).
>
> -yair
>
>
>
>
> > Can someone explain us what is happening inside pfSync() the first time we call it?
> >
> > We create a complex scene through code with lots of pfGroups, pfLODs and many pfGeoSets carefully organized,
> > and our problem is that the first pfSync() is taking a lot of time. (+/- 4000 geosets takes +/- 5 sec).
> > When the number of pfGeoSets increases, (and we need around 180.000), time increases linearly with
> > the number of geosets.
> >
> >
> >
> > At first, we thought that it could be the time required to calculate bounding spheres. We have tried
> > to disable this calculation by providing static Bounding Spheres for all nodes, but this doesn't
> > seem to reduce any time in pfSync().
> >
> > Any ideas?
> >
> > Thanks in advance.
> >
> >
> >
> >
> > ------ =_NextPart_000_01C1BBAA.66F34D20--
> >
> > -----------------------------------------------------------------------
> > List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> > Open Development Project: http://oss.sgi.com/projects/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> > -----------------------------------------------------------------------
> >
>
>
> --
> \_________ \_____ \__ \__ \_____
> \_________ \_____ \__ \__ \_____ Yair Kurzion
> \__ \__ \____\__ \__ yair++at++sgi.com
> \__ \__ \__ (650) 933-6502
> \__ \__ \__
> \__ \__ \__
This archive was generated by hypermail 2b29 : Mon Feb 25 2002 - 01:21:24 PST