Re: Intersection process...
John Rohlf (jrohlf++at++tubes)
Wed, 3 May 95 10:21:56 PDT
>
> I have a question about the intersection process. I am using
> pfIsectFunc() and pfPassIsectData() to pass intersection data to the ISECT
> process [and back? - that's the question...]...
>
> Well, my understanding of pfPassIsectData() is that it makes a copy of the
> data allocated and sends it to the isectFunc(). I also noticed that the example
> in the Performer Reference pages uses a IsectStuff structure that has a
> collisionResults field.
>
> If the isectFunc gets a copy of the isectdata, when and how is it passed
> back to the APP process [ if at all it's done? ]. Any modifications will be
> done to its local copy...
>
> I know I can work around this by directly accessing the pointer returned by
> pfAllocIsectData(), in which case I don't need pfPassIsectData() at all. I
> have tried this and it works.
>
> How do I do it *WITHOUT* bypassing pfPassIsectData()?
>
> Thanks for any insights,
There is currently no mechanism for propagating info
"upstream" from either the ISECT or CULL/DRAW back to the APP.
The man page does imply otherwise so I'll change it.
The pfPass* API provides frame-accurate data propagation downsream
only. Upstream data migration is a bit nastier and we haven't tackled
it yet.
A reasonable solution for the ISECT is to use a chunk of shared
memory which the ISECT writes and the APP reads. You can use locks
and framestamps to ensure data exclusion and frame-accurate behavior.
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:51:28 PDT