Re: Real-Time Simulation

New Message Reply Date view Thread view Subject view Author view

John Rohlf (jrohlf++at++tubes)
Tue, 22 Mar 94 14:33:04 PST

> I'm working on an autonomous navigation system based on the optical
> flow. (Onyx RE^2, Performer 1.2)
>
> 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.
>
> 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?
>
        The application process must call pfFrame to trigger the
        rendering for a new frame. If your processing takes 2 secs then
        you are limited to a rendering rate of .5Hz since you are
        only providing a new eyepoint every 2 seconds.

        It sounds like what you want is eyepoint extrapolation
        or "dead reckoning" which is used for systems like DIS
        which receive positional updates at long intervals.
        "Dead reckoning" is non-trivial and I don't have any
        references for you. Extrapolation is trivial but
        will require that you spawn another process which
        will handle your processing. As soon as you remove your
        processing from Performer's APP process, the APP can easily
        keep up with the frame rate and extrapolate the eyepoint.

> 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 synchronisatione
> problems?

        When you run in LOCK or FLOAT mode, pfSync will sleep the APP
        process until the next frame boundary. pfFrame triggers the culling
        and drawing of a new frame and does not sleep although it may not
        return immediately.

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

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