RE: [Flightgear-devel] Moving carrier, and Repositioning questions
Well I had something similar in mind when I wrote fgLoadDCS() and fgUpdateDCS() in main.cxx. I had used a limit of 32 objects since I guessed that more than that might affect frame rates. Presently repositioning is possible thro network, albeit tied to fdm=ada, but thats trivial to change to make it more widely usable. So far I have used scenery/objects.txt file instead of .xml for loading objects. Is what you have in mind drastically different from whats been implemented so far. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Curtis L. Olson Sent: Friday, April 05, 2002 1:01 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Moving carrier, and Repositioning questions 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.nn /lon-deg=nn.nn /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. RossNextBus 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 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
Norman's intersection testing works just fine for the moving carrier as well. In fact this was discussed on the list almost six months ago. So you would not fly through the deck. Yes your FDM should recieve the current scenery altitude and compute landing gear reactions accordingly. All those issues of aircraft and carrier coordinates are easily handled as pointed out by Jon S Berndt. In fact I have implemented all of it in FORTRAN. I can steer on deck, launch from deck and land on deck and get arrested all the time with the carrier moving. The only hack I use is for the ski-jump. Although I recieve ski-jump ramp height from FlightGear intersection calculations, I dont use that since it is too coarse to accurately simulate ski-jump launch dynamics, so as long as the aircraft is within the deck (on or over) I use height over deck as computed by the FDM, until aircraft leaves the deck. This check is done using longitudinal and lateral coordinates of the deck, i.e a/c posn in deck coords. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Megginson Sent: Friday, April 05, 2002 2:30 AM To: [EMAIL PROTECTED] Subject: re: [Flightgear-devel] Moving carrier, and Repositioning questions Justin Palamar writes: 1) A design goal was to have a moving aircraft carrier within the simulator with the option to land on its deck Right not we have only been able to insert the static model by editing the appropriate .stg scenery file, including OBJECT_STATIC saratoga.3ds -122.353617 37.624617 -130 0 We know this has been done before, there is code in the main.cxx file that refers to a carrier, and a model was included in the 0.7.8 release. Is there any way to get this working using the higher level .xml files, and avoid editing the C++ source code? You'll need the carrier to be in the main scene graph so that collision and ground detection works -- otherwise, you'll fly right on down through the deck. From an SSG perspective, all you need is an ssgTransform node between the carrier model and the rest of the scene graph, and then to updated that node with the carrier's new position and orientation (relative to scenery centre, which is the only tricky part). In fact, Curt's code in FGTileEntry::load (src/Scenery/tileentry.cxx) already creates the ssgTransform node when it loads the OBJECT_STATIC model. If you save a pointer to the transform (somehow) and update it in each frame, the carrier will move. Note especially this code: sgCoord obj_pos; WorldCoordinate( obj_pos, center, lat, lon, elev, hdg ); ssgTransform *obj_trans = new ssgTransform; obj_trans-setTransform( obj_pos ); You can use something similar in your update routine, using the current scenery centre and supplying new lat/long/elev/hdg params. 2) When loading our blackhawk model (again by editing/adding .xml files from the ./Aircraft directory our model appears about 3 meters into the ground. We have attempted to reposition the model using the instructions from the flighgear website (rather than pointing directly to the model, point to a .xml wrapper file with repositioning information in it that also points to the model) but we an ssgLOAD error: Unknown file type .xml. As if it is trying to see a graphic file and sees an .xml and doesn't know what to do with it. I'm not sure if this is a change in the newest release, of if I'm missing something. Yes, you need the latest CVS code. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Plotting tool
Regarding the thread you are referring to - The code is presently with Alex Perry and he is in the process of integrating it into SimGear (?) and should be available soon. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Quint Mouthaan Sent: Wednesday, April 03, 2002 6:27 PM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] Plotting tool Hi there, my name is Quint Mouthaan and I'm a student at the Technical University Delft in the Netherlands. I'm working a project in which we want to use FlightGear. The first thing we want to do is analyze some flight data. I saw a thread a little while ago about a tool that would be added to FlightGear that could be used to plot some data real time. Is that tool already available and if it is how can I obtain it? Thanks, Quint. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Post 0.7.9 priorities (lights)
Roman,
If you know the light posns in runway (object) coords all you need to know
is the lat, lon and alt of the centre/corner (0,0,0) of the runway.
Construct transformation matrix as is done for dynamic objects in main.cxx.
Rotate first for lat, lon and translate by Objtrans (see below).
//object gbs-posn in cartesian coords
Point3D obj_posn = Point3D( obj_lon,obj_lat,obj_alt);
Point3D obj_pos = sgGeodToCart( obj_posn );
// Translate object w.r.t tile center
Point3D Objtrans = obj_pos - tile_center;
This should work. This can be done offline and stored in a seperate file or
done on the fly.
Regards
Ranga
-Original Message-
Okey guys, I'm trying to implement runway lights but I have some
mathematical trouble:
I know 4 corners of runway in local tile coordinates O1 O2 O3 O4 {x,y,z}
And I have runway sheme of lights for example let O1 will have {100,100,100}
in FG coordinates and {0,0,0} in local lights coordinate system. All I need
to have formulas to convert this local lights coordinates to tile fg
coordinates. I know that I can construct plane by 3 points using plib sg
routine but wthat formulas?
O2O3
y
|
0--00
||
||
||
0--00--x
O1O4
so in runway coordinate system we have 6 points
{0,0,0}{100,0,0}{200,0,0},{0,50,0},{100,50,0},{200,50,0} and have simple
routine to convert it to tile coordinate system
I try many formulas but no success :((
So if some on do it we HAVE runway lights
because you simply construct it using tileentry.cxx routines
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Urgent: Network and external flight model
Roman, This was dicussed earlier on this list. I found one disdavantage of using multicast. My packet size or structure kept growing as I added more computers on the network that are **not** image generators but pcs used as flight test engineer station or fcs monitoring station etc. Why should image generators receive data that is not intended for it and vice versa. So I find non-blocking udp fast enough while maintaining packet sizes to the minmum required and I suppose bandwidth requirements are not too high to cause perceptible delays. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan Polley Sent: Friday, February 01, 2002 7:16 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Urgent: Network and external flight model David, At work, I run a proprietary FDM on a Sun Workstation and feed the data to FlightGear. I use the '--fdm=external' and '--native_fdm=...' options (--native_fmd= uses the same parameters as --native). I did make some changes to Network/native_fdm.cxx to properly manage the byte-order issues, but it works like a champ. IMHO, --native_fdm= has a cleaner interface than does --native=. To see the data structure that the FDM needs to generate, look in Network/raw_fdm.hxx. Jonathan Polley p.s. I have submitted my edits. On Thursday, January 31, 2002, at 06:37 PM, David Findlay wrote: Just checking a couple of details - you can run an external flight model on a machine other than the one running FGFS right? Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Urgent: Network and external flight model
Roman, but I think that for IGs - best is multicast (no delays between channels) Theoretically speaking, yes. But practically what delays are we talking about even with a 10 Mbps dedicated network. We will be fast enough for realtime. Synchronisation problems would not happen at the network level but could happen at the tile-loading/culling/rendering stages of each IG **if** no. of polygons/textures are different for each IG (or view). Yes multicast can certainly be useful, like httpd, for remote IGs but not for local IGs around a dedicated network. With it I could perhaps join your multicast group half way round the globe and watch you fly, bandwidth permitting. Regards Ranga -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan Polley Sent: Friday, February 01, 2002 7:16 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Urgent: Network and external flight model David, At work, I run a proprietary FDM on a Sun Workstation and feed the data to FlightGear. I use the '--fdm=external' and '--native_fdm=...' options (--native_fmd= uses the same parameters as --native). I did make some changes to Network/native_fdm.cxx to properly manage the byte-order issues, but it works like a champ. IMHO, --native_fdm= has a cleaner interface than does --native=. To see the data structure that the FDM needs to generate, look in Network/raw_fdm.hxx. Jonathan Polley p.s. I have submitted my edits. On Thursday, January 31, 2002, at 06:37 PM, David Findlay wrote: Just checking a couple of details - you can run an external flight model on a machine other than the one running FGFS right? Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Urgent: Network and external flight model
Erik, Yes I mean multicast and not broadcast. The destination address is the group still, unless I have different multicast groups - one for IG, one for the engineer etc. That would be a waste. Regards Ranga -Original Message- Are you shure you don't mean broadcast here? For what i know, multicast has the destination ip-addresses inside the packages, so only intended computers should receive the data. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Objects
David, -Original Message- What's FG_EXPERIMENTAL_LIGHTING? And is it used by default? It is code to enable lighting on the aircraft carrier incuding an Optical Landing aid (fixed at 3.75 deg). It is not enabled by default unless you add that define. As far as I know only I am using it. If you haven't already written code for billboarding trees there is fgbillboard() function (unused so far) in tileentry.cxx. You may use it. It works fine and I used it earlier for polygon based runway lights. You may need to change the arguments depending on your implementation. Regards Ranga _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] buildings or planes?
Hi everyone, I have been following this thread. Pretty sure Objects/Geometry/saratoga.obj is a carrier Yes, this would be cool.Definitely. Jon Jon, as pointed out by John, we already have an aircraft carrier. It is one with a ski-jump and 3 arrestor wires. We use it in our design work. Andy, You can see the carrier in FlightGear by giving the lat,lon,alt in ~scenery.objects.txt. Or use the 3dexplorer (windows only) shareware viewer. If you are interested I could send you the wavefront .obj file format specs. The carrier model is a simple low polygon one which I edit manually!!. It uses object coordinates with its (0,0,0) at waterline (or metacenter, there is no hull below waterline in this model). You can use 3dexplorer to convert it some format that PPE supports and then use PPE to edit. But I havent tried that. I'll be glad to help anyone who is interested in using it. Regards Ranga I've never touched the geometry side of fgfs, so any pointers would be appreciated. What can I use to look at this thing? I don't recognize wavefront .obj format (although it's ASCII at least -- big plus). I'm not a big modelling guy, so be gentle. I just need to figure out the coordinate system and where the deck plane and arrestor wires are. If plib supports it, then is Pretty Poly the best editor to use? Does ssg support API-side inspection of the geometry once it's loaded? (dumb question, I could just look it up...) _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
