Patrick Quirk wrote:
Yeah I saw those, and those could probably work for now, though I'm
really looking for a more exact way since I already have a look vector.
This sounds like an "interfacing" issue. If you could convert your
lookat/up vectors into heading, pitch, roll, FlightGear would be a lot
happier and all the other FG facilities should fall into place more
easily. The matrix math for the lookat/up -> HPR transformation isn't
exactly trivial (since matrix ops lie outside the bounds of what I'd
personally consider trivial) :-) but there isn't anything especially
hard about it either. Someone more clever than I could probably pump
the lookat/up vectors into gluLookAt(), read back the resulting view
transformation matrix, look at the rows/columns and figure out a way to
extract heading, pitch, roll. Or you might be able to look at what the
gluLookAt() routine does and perhaps gain some insight from that, or you
could just derive your own transformation pipeline. It's all pretty
straightforward stuff as far as matrix transformations go. :-) There's
probably code floating around the FG project to do similar if not
Could you perhaps elaborate on what you mean by telnet interface? Are
you saying it's inside of FlightGear? Also how would I set the view
property (as in cockpit, tower, chase...)? Please forgive my
rudimentary questions, my working knowledge of the fgfs code structure
is not terribly deep.
Ok, this is one of the ways FlightGear is incredibly cool.
First, pop open the property browser in a live running copy of
FlightGear (it's a menu choice someplace.) Browse around to see the
different data fields that are available. Just about everything
interesting/useful is published in the property system. The browser
allows you to inspect and even change values in the live running copy of FG.
Now, start up FlightGear with the following option: --telnet=5401 (or
pick your favorite port number.) Once FlightGear is up and running, go
to an xterm/shell on the same machine running flightgear and type
"telnet localhost 5401". You could do this from any machine on the net
by substituting the appropriate machine name/ip-address. From the
telnet session hit enter or type "help" to get a list of available
commands. You can now remotely navigate through the property structure
and examine and change values in the live running copy of FlightGear.
This is very powerful (although low bandwidth) and allows you to set and
change a huge range of values in FlightGear.
Even better, it's pretty easy to automate a remote telnet session so you
can write scripts or code that can remotely control FlightGear in
various ways. I've written a commercial operator GUI that interfaces to
FlightGear in this way. I've scripted (perl) out all the FAA Level 3
FTD certification tests in this way (setting up initial conditions,
reseting the FDM, enabling/adjusting autopilot modes, and even remotely
manipulating control surfaces when needed.)
And you can use the same mechanism to adjust view parameters, configure
weather settings, time of day, etc.
The only draw back is that it's low bandwidth. It's good for setting a
few parameters at a relatively low rate, it's good for interactive use,
it's good for many remote scripting tasks, but you don't want to use it
to try to blast a bunch of position/orientation data in real time. We
have other interfaces better suited for that.
I should also point out that we have an html version of the telnet
interface "--httpd=5400" that allows you to connect up to a live copy of
FlightGear from any web browser and interact with the sim. Just type in
a url like this: "http://localhost:5401/"
Curtis Olson http://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
Flightgear-devel mailing list