Re: pfCycleBuffer

New Message Reply Date view Thread view Subject view Author view

Mario Veraart (rioj7++at++fel.tno.nl)
Mon, 28 Jul 1997 11:20:26 +0200 (MET DST)

>
> > Performers:
> >
> > Could someone please clear up my thoughts on pfCycleBuffer.From the
> > examples and man pages, I'm a little confused on the implementation.
> >
> > >From morph.C:
> >
> > //// This is where the new cycle buffer is created.
> >
> > cbuf = new(arena) pfCycleBuffer(nSph * sizeof(pfVec4));
> >
> > ncoords = (pfVec3*) pfMalloc(pfGetSize(coords), arena);
> > nnorms = (pfVec3*) pfMalloc(pfGetSize(norms), arena);
> > ....
> > colors = (pfVec4*) cbuf->getData();
> >
> > /// How is it possible for cbuf->getData() to return anything since
> > //// nothing has ever been done to cbuf since it's creation. Where is all
> > //// the information allocated and created from the arena associated with
> > ///// the cycle buffer?
> >
>
> Lemme try and take a stab at this and then some:
>
> line 132: allocate pfCycleBuffer data
> Note: just enough space for a packed array of nSph color vectors.
>
> cbuf = new(arena) pfCycleBuffer(nSph * sizeof(pfVec4));

This will allocate for every separate process a block of memory with
size nSph * sizeof(pfVec4). The cycle buffer keeps an array of pointers to
these blocks of memory allocated in shared memory.

>
> line 137: Get a handle to the data buffer:
> Note: I believe any time get data is called it gets a version
> of the data appropriate to which process you are in (APP, CULL,
> DRAW) and which pfMultiprocessing mode you are in (e.g.,
> PFMP_APP_CULL_DRAW)
>
> pfVec4 *colors = (pfVec4*) cbuf->getData();
>
> Again in answer to one of your questions this returns a POINTER
> to the buffer that was allocated in line 132. You still need to
> set the data as below.
Every process has a global variable that contains the number of the buffer
in a cyclebuffer to use for this process.
This variable is updates during pfSync/pfFrame.
In all the processes the value is different. So cbuf->getData() checks the
needed buffer number and returns the pointer to the right buffer.

>
> line 159-160: Set the colors and hence the cbuf data:
>
> colors[i].set(0.0f, 0.0f, 0.0f, 1.0f);
> colors[i][max] = 1.0f;
>
> line 178:. Initialize all the other CycleBuffer copies of this buffer:
>
> /* Set all pfCycleMemories to the same colors */
> cbuf->init(cbuf->getData());
>
> line 180: Associate this cycle buffer data with the color data of the
> pfGeoSet:
>
> gset->setAttr(PFGS_COLOR4, PFGS_PER_VERTEX,
> (void*)cbuf, NULL);
>
> Now you can change your color in the APP process as shown in the
> breatheMorphe function:
>
> colors = (pfVec4*) cbuf->getData();
> for (int i=0; i<nSph; i++)
> colors[i][0] = s;
>
> cbuf->changed();
>
> And these changes will get propagated down the pipeline AUTOMAGICALLY by
> the pfCycleBuffer, and if I understand this correctly... when the draw
> process comes along to render the pfGeoSet and accesses the color
> information. The pfCycleBuffer will feed it a pointer to the "correct"
> data.
>
> Hope this is right,
Yes you are

> scott

Mario
=======================================================================
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:55:39 PDT

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