What I would like to see implimented is a 'standard' DCS system (where
DCS stands for dyanamic coordinate system which is industry lingo for
objects that move in the scene ... their local coordinate system is

I'm envisioning a DCS manager where you can register 'entities' with
an associated 3d model and an associated 'behavior'.  The behavior
could be a preset path to follow, or something more AI-ish, or even
something like JSBSim or YAsim (or perhaps entity positions could be
driven externally from a server to produce a 'shared' world for
collaborative flying.)  I'm thinking we could create some simple
"FDM's", one that replays a preset path, and one that impliments
ultra-simple-light-weight flight dynamics which would be good enough
for 'realistic' robot planes viewed from a distance, but simple enough
so we can compute the dyanmics for "many" planes each frame.

The DCS system would take care of loading and attaching the 3d models
to the correct place in the scene graph and removing them.  It would
call the update() routine for each of their "engines".  And it would
probably provide some sort of property interface to the positions,
orientations, and velocities of these dynamics entities.

That doesn't solve all the problems and address all the issues, but I
think it would be a good start.

Anyone want to work on this?  I could even give you your own
subdirectory.  <ooh/ahh> :-)



Andy Ross writes:
> Justin Palamar wrote:
>  > 1) A design goal was to have a moving aircraft carrier within the
>  > simulator with the option to land on its deck
> There are actually two problems here.  The first, making the object
> move, is relatively easy.  It will require C++ code, though.  One way
> I've thought about doing it is to put the object in the property tree
> rather than the static scenery description.  Something like:
> /scenery/objects[n]/model-file=Models/carrier.ac3
>                     /lat-deg=nn.nnnnnn
>                     /lon-deg=nn.nnnnnn
>                     /alt-ft=nnn
>                     /hdg-deg=nnn
>                     /speed-kt=nnn
> And then the "dynamic scenery" code would update the lat/lon
> accordingly.  This could be extended with extra orientation and
> velocity parameters for a full 6DOF model animation, controllable via
> properties.
> But there's another problem -- the current FDMs model gear force using
> only the aircraft's velocity.  They assume the ground is fixed and
> unmoving.  This means that you could land on the carrier, but would
> then come to a stop relative to the earth, while the carrier slipped
> smoothly out from under you.
> I'm not quite sure about the "right" way to do this -- doing it in the
> low-level ssg "hitlist" collision detection is going to be rather
> complicated, and won't perform well.  Perhaps the best way to handle
> it would be to special case "carrier deck" objects (more generally,
> anything moving on which the gear are expected to rest), and expose
> them directly to the FDMs via a "ground velocity" parameter.
> Andy
> -- 
> Andrew J. Ross                NextBus Information Systems
> Senior Software Engineer      Emeryville, CA
> [EMAIL PROTECTED]              http://www.nextbus.com
> "Men go crazy in conflagrations.  They only get better one by one."
>   - Sting (misquoted)
> _______________________________________________
> Flightgear-devel mailing list
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Curtis Olson   IVLab / HumanFIRST Program       FlightGear Project
Twin Cities    [EMAIL PROTECTED]                  [EMAIL PROTECTED]
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Flightgear-devel mailing list

Reply via email to