Re: Real-Time Simulation

New Message Reply Date view Thread view Subject view Author view

Aaron M. Hightower (aaron++at++skips.dseg.ti.com)
Mon, 21 Mar 94 13:50:06 CST

> From: susi++at++avocado.mpib-tuebingen.mpg.de (Susanne Huber)
>
> Until now the algorithm, which is computing the next heading
> direction isn't a real-time algorithm.
> I have the feeling that Performer gets in trouble with the
> synchronisation, if the application lasts a lot longer (here ca. 2 seconds)
> than the framerate.
> 
--
from the pfConfig man page:


   Each pfPipe has a cull and draw stage which may be configured as either
   one or two processes. The intersection stage is independent of any pfPipe
   and may run in the same process as the application process or as a
   process by itself. In the latter case, the user may further multiprocess
   intersection traversals through any IRIX multiprocessing mechanism such
   as fork, sproc, or m_fork.

--
It seems that what you may be able to do is create a user-defined
intersection process that handles the high compute-intensive heading
determination, and places the result in shared memory
(EG ViewState->myHeading)...

--
from the pfIsectFunc man page:


   Within the intersection callback, the user may further multiprocess
   intersection queries through any IRIX multiprocessing mechanism such as
   fork, sproc, or m_fork. All of these processes may call pfSegsIsectNode
   in parallel.
   
   When the intersection function is in a separate process, it will run
   asynchronously with the rest of the rendering pipeline. Specifically, if
   the intersection function takes more than a frame time, the rendering
   pipeline will not be affected.

--
> 
> Does anybody have experience whether Performer can handle those applications 
> which last longer than the FrameRate? 
> Or is it perhaps better to use Inventor for this problem?


There is more information in pfIsectFunc man page that you definitely want
to check out.
 
> Or the other way round: synchronisation starts with the call to
> pfSync(). Does the synchronisation sleep after the call to pfFrame 
> until pfSync is called again? 
> If that is true, I could call the appliation before calling pfSync or 
> after calling pfFrame, and there wouldn't be any synchronisation
> problems?
 
Hope this helps!
                                      _
Aaron Hightower - aaron++at++dseg.ti.com  | | .
Visualization & Simulation         __| |___
Technology Development, TI         \   =/=/
Voice: (214)575-6759                \X / /
FAX:   (214)575-6779                  \ (
                                       \/















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:12 PDT





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