Matthew Churchill wrote:
this is exciting, this sounds close to providing the ability to playback real flights
that I'm looking for to go with the flight recorder I'm attempting to make.
please excuse the deluge of questions.
what is david calkins program ?
what kind of device is an attitude provider ? and what format is the data provided to flightgear in ?
can attitude data be stored in a file ?
what is the sharemem.dll ? and what is the linux equivalent ?
has anyone got a sample of this combined attitude and position data ?
I'd love to try this out
It should be pretty straightforward to use FG to playback a real
flight. With FG you can slave multiple instances to one master instance
of FG in real time. Slaving a copy of FG to a recorded data stream
should be also very similar.
For anyone trying to sync multiple copies of flightgear and get silky
smooth frame rates, or anyone trying to get silky smooth frame rates in
a single copy of FG the following is some important information I
learned the hard way...
If you want smooth rendering, you need to do a couple things. First,
make sure that your copy of FG can render a sustained consistant frame
rate. One *good* option is to sync to the vertical refresh signal on
your monitor. With linux/nvidia there is an environemental variable you
need to set to activate this feature (see readme that comes with the
driver.) For other cards or platforms, there may be some different
mechanism. Secondly, there is a tool that FG gives you to throttle
frame rates to a maximum value. Set the property
/sim/frame-rate-throttle to some value that is a multiple of your
monitor's refresh rate, but is fast enough for your machine to keep up
with consistently. From the command line or your ~/.fgfsrc you could do
this:
--prop:/sim/frame-rate-throttle-hz=30
Just to convince yourself this is working, you might want to try
something like:
--prop:/sim/frame-rate-throttle-hz=5
This will limit your maximum frame rate to the specified hertz (if your
machine can go that fast.) The internal FG mechanism to do this is a
simple busy/wait loop so you don't gain any CPU cycles with this, but
you do get pretty accurate timing.
Getting the rendering speed consistent is one side of the coin. The
other is that you need to feed the data input stream at the same
consistent rate. This can be hard to control if you are communicating
over the network.
Consider this: here in the USA our monitors really like to run at 60 hz
(or 72 or 75.) I usually run them at 60hz because that's easier to keep
up with for FG rendering. For one particular example, I was stepping FG
down to 30hz. I was trying to feed FG from another application running
on the same machine. This was a really low cpu-usage process so I was
using timer interrupts to wakeup every 33ms and send the data over the
network. I was about to congratulate myself on my own cleverness, but I
was continually nagged by much choppier rendering than I thought I
should be seeing. Something wasn't right. It just so happened that
someone had an oscilliscope they could connect in to one of the
interfaces and see exactly how fast my data feeding program was running
... I was shocked that it was doing 25hz (or one data output every 40ms
even though my timer was set to wake up every 33ms.) A 25hz input
stream combined with a 30hz renderer just can't provide jitter free
video output, in fact it's pretty horrible.
Upon further investigation I discovered that the underlying linux CPU
scheduler runs at 100hz (20ms cpu scheduler interrupt rate.) This is
hard coded into the kernel and at one time represented a good balance
between not burning too much CPU with excessive context switching, yet
switching processes often enough so that they didn't become too
unresponsive.
Apparently the linux timer interrupt system only checks for a timer
interrupt during a context switch (or every 20ms.) So I requested a
33ms wakeup ... after the first 20ms context switch, the timer hadn't
expired yet, and the system wouldn't check again for another 20ms ... so
I was getting 40ms interrupt times when I asked for 33ms... Actually
you get 40ms interrupts if you ask for anything > 20ms or <= 40ms.
Frustrating! I actually tried playing with the system cpu scheduler
rate and recompiling my kernel and never got the results I was hoping for.
This message is starting to get a little long and tedious, but my point
here is that for smooth frame rates: (1) you need to draw the scene at
a consistant rate (and I mean a consistant frame rate, not a variable
rate faster than movie frame rates, but that's another tedious
discussion for another time.) And (2) you need to feed your
position/orientation updates at that exact same rate (and my example was
to show why that's not always easy.) :-)
What I ended up doing on the Linux platform was to keep the two
applications running on the same machine, but commu
