Seperate ISECT process

New Message Reply Date view Thread view Subject view Author view

Alon Rosenfeld 18 Hatzedef street Jaffa (alon++at++bvr.co.il)
Mon, 20 Jun 1994 12:59:42 +0000


To: info-performer++at++sgi.com

Hi,

A week ago I came up with a problem regarding the use of a separate isect
process, but unfortunately I did not receive an answer. Therefore I am sending
the message again in case it was never received.

*****************************************************************************

My application uses a separate process for intersection calls.
(pfMultiprocess(PFMP_FORK_ISECT)).

It seems that Performer lacks a two-way path between the APP process
and the ISECT process. Currently changes done in the ISECT structure,
in the APP process, are passed down to the isect_func() (the ISECT cb),
but sadly enough it is not true the other way around.

Since isects are done in a separate process and they are quite lengthy in time,
it may take the process some time to come up with a result (could even take a
couple of frames). Therefore it is important that a two-way data path is
available between the two processes to enable a hand-shaking mechanism.

Well, could or should Performer support a two-way data path?
Meanwhile, is the only solution is the use of a globally defined, pre pfConfig,
structure?

Below are some relevant code lines from my application

static void isect_func(void *userData)
{
IsectData *isect_data;

        isect_data = (IsectData *)userData;
        .
        .
        .
}

main()
{
        .
        .
        .
/* Initializing the ISECT cb */
        pfIsectFunc(isect_func);
        isect_data = (IsectData *)pfAllocIsectData(sizeof(IsectData));
        .
        .
/* Main loop */
        while (1)
                {
                .
                .
                .
                pfPassIsectData();
                pfFrame();
                }
}

Thanks

Alon


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:50:20 PDT

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