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 'dyanamic'.
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> :-) Regards, Curt. 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 > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
