Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Jon S Berndt writes:
Yeah, I've considered that for some time, just haven't
gotten around to it. But, I guess if it's causing so many
problems, maybe we need to just go ahead and do it.
Another reason I have waited is because even though I know
how to use stuff in other namespaces, I'm not positive
that I know how to go about putting our stuff into a
namespace. Can anyone explain this to me?
Put
namespace jsbim {
at the start of every file, and
}
at the end. If you want, you can #ifdef them for older compilers, but
I don't think anyone's having a problem with Andy's YASim code.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
David Megginson writes: When we get around to modelling ships, we can impose on Norm Vine to share some of his expertise, since this is his specialty. Although I have experienced a LOT of it I have done VERY little modelling of ship motion. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
Norman Vine writes: it would behoove the project to stop thinking in spherical terms xcept when doing user input / output. Converting back and forth between sperical and cartesian representation is a time sink that doesn't need to happen at all as far as the inner workings of the program are concerned. The cartesian form of the position and orientation is already put on the 'bus' in cartesian form USE IT We don't have that information for other things (control tower, aircraft carrier, wind sock, terminal building, etc.), and this is where the FGLocus class would be an advantage -- it can cache the conversion and redo it only when one of the parameters has changed. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Tony Peden writes: The latter would certainly be easier, no code would need to be changed. Wouldn't it have the effect of forcing client code to keep track of which vehicle was being referenced in the tree? A good example here, I think, would be the view manager. Another good example would be the real-time plotting code Curt discussed a few weeks back. In both cases, just blindly using the data in the tree would be likely to have some interesting results. That sounds fair. As long as we have everything working through FGGlobals (i.e. no global variables declared in header files like current_panel), then we can swap different versions of FGGlobals in and out. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Jim Brennan jjb - writes: Now to be really fancy, you'll need to model the pitch and roll of the carrier deck. And the changes in height above the sea as the landing area moves up and down! Right. And for Canadian aircraft carriers, you'll have to ... ... oh, sorry, we don't have any aircraft carriers, or even battleships (does anyone still use battleships?) or cruisers, I think. Here's something more interesting (and Canadian) -- what about landing a Beaver or Otter on a large (i.e. 5km x 5km) moving ice floe during the spring thaw up north? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
Norman Vine writes: But we really need another name and I realize that you are trained in 'English' and will argue for (1) below however I believe (3) below is paramount in this case as this class refers to a 'single point' not a 'set of points' in the 'mathematical sense and Locus is misleading here :-) Actually, it's my Latin training causing trouble here. FGPOV would be OK if we were dealing only with cameras, but it doesn't make sense for placing models. How about FGPlacement? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
On Fri, 5 Apr 2002, David Megginson wrote: Jim Brennan jjb - writes: Now to be really fancy, you'll need to model the pitch and roll of the carrier deck. And the changes in height above the sea as the landing area moves up and down! Right. And for Canadian aircraft carriers, you'll have to ... And for the british ones you need the ramp - it's also a much smaller target to aim for! -- Jon StockillPublic Key: C3749C06 [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
David Megginson [EMAIL PROTECTED] said: Norman Vine writes: But we really need another name and I realize that you are trained in 'English' and will argue for (1) below however I believe (3) below is paramount in this case as this class refers to a 'single point' not a 'set of points' in the 'mathematical sense and Locus is misleading here :-) Actually, it's my Latin training causing trouble here. FGPOV would be OK if we were dealing only with cameras, but it doesn't make sense for placing models. How about FGPlacement? Or maybe FGLocalCoordor just FGCoord? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
David Megginson writes: Norman Vine writes: But we really need another name and I realize that you are trained in 'English' and will argue for (1) below however I believe (3) below is paramount in this case as this class refers to a 'single point' not a 'set of points' in the 'mathematical sense and Locus is misleading here :-) Actually, it's my Latin training causing trouble here. FGPOV would be OK if we were dealing only with cameras, but it doesn't make sense for placing models. How about FGPlacement? How about something simple like FGPosition or FGPos ... I thought of it so it gets my vote. :-) Curt. -- 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
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
Jim Wilson writes: Or maybe FGLocalCoordor just FGCoord? I'd be worried about confusion with sgCoord. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
Jim Wilson writes: David Megginson [EMAIL PROTECTED] said: Norman Vine writes: But we really need another name and I realize that you are trained in 'English' and will argue for (1) below however I believe (3) below is paramount in this case as this class refers to a 'single point' not a 'set of points' in the 'mathematical sense and Locus is misleading here :-) Actually, it's my Latin training causing trouble here. FGPOV would be OK if we were dealing only with cameras, but it doesn't make sense for placing models. How about FGPlacement? Or maybe FGLocalCoordor just FGCoord? +1 on FGCoord -1 on FGLocalCoord as IMHO this is better used for either TileCoordinates or better yet for coordinates in the Current Coordinate Frame as 'seen' by OpenGL Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
On Fri, 5 Apr 2002 10:27:44 -0500 David Megginson [EMAIL PROTECTED] wrote: Here's something more interesting (and Canadian) -- what about landing a Beaver or Otter on a large (i.e. 5km x 5km) moving ice floe during the spring thaw up north? What kind of crazy place is this Can ada? I've seen beavers and otters. Down here they only swim. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
On Fri, 5 Apr 2002 10:10:10 -0600 (CST) Curtis L. Olson [EMAIL PROTECTED] wrote: How about something simple like FGPosition or FGPos ... I thought of it so it gets my vote. :-) Curt. We thought of it three years ago (FGPosition). It's already in JSBSim. :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
Jon S Berndt writes:
On Fri, 5 Apr 2002 10:10:10 -0600 (CST)
Curtis L. Olson [EMAIL PROTECTED] wrote:
How about something simple like FGPosition or FGPos ... I thought of
it so it gets my vote. :-)
Curt.
We thought of it three years ago (FGPosition). It's
already in JSBSim.
Yes BUT ... your FGPosition is what I would call FGRigidBody
ie you have velocity and acceleration terms
IMHO the class heirarchy should be something like
class FGPosition
{
private:
double htmatrix [4][4];
}
class FGRigidBody : public FGPosition
{
private:
doubletime_of_posture;
doublex_dot; // linear velocity along x axis
doubley_dot; // linear velocity along y axis
doublez_dot; // linear velocity along z axis
double phi_dot; // angular velocity about x axis
doubletheta_dot; // angular velocity about y axis
double psi_dot; // angular velocity about z axis
}
but-we've-been-here-before'ly yr's
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
On Fri, 5 Apr 2002 12:11:43 -0500 Norman Vine [EMAIL PROTECTED] wrote: Yes BUT ... your FGPosition is what I would call FGRigidBody ie you have velocity and acceleration terms IMHO the class heirarchy should be something like Given any 100 people, you'll get 400 different FDMs. :-) Our RigidBody EOM is in the translation and rotation classes - we split them out for a reason. The position class takes those results and integrates to get position, and converts from body to local (NED), and some other stuff. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
Jon S Berndt writes: On Fri, 5 Apr 2002 12:11:43 -0500 Norman Vine [EMAIL PROTECTED] wrote: Yes BUT ... your FGPosition is what I would call FGRigidBody ie you have velocity and acceleration terms IMHO the class heirarchy should be something like Given any 100 people, you'll get 400 different FDMs. :-) :-)) I guess I was just trying to point out that IMHO we shouldn't adopt the JSBSIM::FGPosition class as is in that it has in the more general enviroment of FGFS xtra baggage when one is considering 'statically' positioned things such as buildings signposts ect... That said -- I do believe that FGFS should make an object heirarchy that should be all stem from a class that is a wrapper around a 4x4 Matrix that is the 'Homogeneous Matrix' representatation of a point in the world. hence my prefered name class HMatrix. For most Dynamic Objects I also suggest that the equivalant of my RigidBody class is the 'obvious choice' apon which to base further object derivation. Note these are 'minimal' base classes meant to be derived from What we actually end up calling them I really do not care however it makes sense to me that the names reflect the nomenclature of the 'standard Math / Physics' principals that they implement ie HMatrix and RigidBody Regards Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Jon S Berndt writes: On Fri, 5 Apr 2002 12:58:57 -0500 Norman Vine [EMAIL PROTECTED] wrote: I guess I was just trying to point out that IMHO we shouldn't adopt the JSBSIM::FGPosition class as is in that it has in the more general enviroment of FGFS xtra baggage ... Oh, I certainly agree - I didn't mean to imply I was endorsing that. I was just playing with Curt, telling him I had already 'thought of' the FGPosition name. I want to see a patent number. :-) Curt. -- 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
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
On Fri, 5 Apr 2002 13:00:00 -0500 David Megginson [EMAIL PROTECTED] wrote: Jon S Berndt writes: That's actually becoming a bit of a problem -- I couldn't use FGModel for the 3D model either because JSBSim had already taken it. As Andy keeps reminding us, it would be a good idea to put JSBSim and possibly SimGear into their own namespaces to avoid conflicts like these. Yeah, I've considered that for some time, just haven't gotten around to it. But, I guess if it's causing so many problems, maybe we need to just go ahead and do it. Another reason I have waited is because even though I know how to use stuff in other namespaces, I'm not positive that I know how to go about putting our stuff into a namespace. Can anyone explain this to me? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
David Megginson writes: Jon S Berndt writes: We thought of it three years ago (FGPosition). It's already in JSBSim. That's actually becoming a bit of a problem -- I couldn't use FGModel for the 3D model either because JSBSim had already taken it. As Andy keeps reminding us, it would be a good idea to put JSBSim and possibly SimGear into their own namespaces to avoid conflicts like these. Yes the time as probably come to do this To bad JSBSim presumptiously used the FG prefix I would think something like JSB would have been a more traditional prefix to have chosen wink Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Moving carrier, and Repositioning questions
Jon S Berndt writes: . In hindsight, we might have preferred to not call everything FG I volunteer to change the JSBSim usage of the 'FG' prefix to anything you want :-) 15-minutes-of-sed'ly-yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
* [EMAIL PROTECTED] (Norman Vine) [2002.04.06 12:25]: Jon S Berndt writes: . In hindsight, we might have preferred to not call everything FG I volunteer to change the JSBSim usage of the 'FG' prefix to anything you want :-) 15-minutes-of-sed'ly-yr's 15 minutes? $ find . -name *.[ch]?? -o -name *.h \ perl -pi.bak -e 's/FG/JSB/g' -- Cameron Moore [ I have an inferiority complex. But it's not a very good one. ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
On Thu, 4 Apr 2002 16:04:53 -0500, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: What about landing a helicopter on top of a moving train in a James Bond emulator? This is a nasty problem. I do think that it should be possible to locate the ssgVertexTable under the wheels, walk up to the nearest branch, then lock the gear to the object's motion somehow. Probably not this week, though. ..adding to the fun, in WWII, several merchantmen were converted to auxillary aircraft carriers, for convoy escort duty, such as to Murmansk, Russia, essentially by roofing the ship. These were small enough to heave, pitch and roll etc in weather. Anyone here who knows their way around ship's stability? ..in the 1920-30'ies the US played with landing pursuit planes, in hooks under zeppeliners (dirigibles?sp!) and then hoisted them onboard up thru the hangar deck/floor. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
. In hindsight, we might have preferred to not I volunteer to change the JSBSim usage of the 'FG' prefix to anything you want :-) 15-minutes-of-sed'ly-yr's 15 minutes? $ find . -name *.[ch]?? -o -name *.h \ perl -pi.bak -e 's/FG/JSB/g' 10 seconds to write, 14.83 minutes to fix those typos, ... 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Alex Perry writes: . In hindsight, we might have preferred to not I volunteer to change the JSBSim usage of the 'FG' prefix to anything you want :-) 15-minutes-of-sed'ly-yr's 15 minutes? $ find . -name *.[ch]?? -o -name *.h \ perl -pi.bak -e 's/FG/JSB/g' 10 seconds to write, 14.83 minutes to fix those typos, ... 8-) And 4 hours to track down all the places where FG existed where it shouldn't have been converted to JSB ... :-) Curt. -- 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
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
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
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
On Thu, 04 Apr 2002 14:03:10 -0500 Justin Palamar [EMAIL PROTECTED] wrote: Hello, flightgear devolpers, this is my first message to this list, so please excuse any question that may sound 'stupid', I'm just a newbie. We all remember when we were newbies - no question is stupid. This *answer* may be, though ;-) And this is as good a place as any to post your question. I am currently a member of a development team working on a Senior Design project at Pennsylvania State University. PSU? Does John Anderson still teach aero there? We were assigned to construct a Blackhawk flight simulator for educational use within the Rotocraft center. We decided early on to use flightgear as our engine, due to its vast customizability. We were having problems in a few areas, and if anyone could provide ANY insight on any of these subjects I would greatly appretiate it. Have you seen the rotorcraft-related technical reports at Richard McFarland's web site at Ames? 1) A design goal was to have a moving aircraft carrier within the simulator with the option to land on its deck Right now 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 The following statement is an off-the-top-of-my-head idea thrown out to the developer wolves for your amusement only. However, it is an approach that might be a decent hack. Note that I am vaguely aware of other most assuredly better ways to do this, but here goes, anyway: JSBSim will soon have the ability to model multiple flight vehicles - or rather, multiple _vehicles_. This design feature is specifically for carrying and dropping bombs, missiles, experimental aircraft, etc. and flying them out to completion, or staging a launch vehicle, etc. However, it could also be used for such things as an AI spotter plane flying a viewpoint camera near an aircraft of interest. Or, I am thinking, just perhaps, it could model an aircraft carrier at sea, given the right set of parameters. It would have few, if any, aero coefficients (instead they would be fluid coefficients), and the ground reactions (landing gear) would be a bit different than that of an aircraft, instead representing bouyancy? Or maybe that would be done by fluid coefficients. Norman might have some observations on this. In any case, the multi- capability is not quite there, yet. I plan on having a bunch of time this weekend to program, and hope to get that stuff in JSBSim CVS at least in beta this weekend. Whether or not this might actually work for an aircraft carrier in JSBSim is unknown to me at the moment, but I think it could work OK. I might play with it once the time comes. In the meantime, I am sure there will be better ways presented here of doing what you want. How are you modeling the helicopter dynamics? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Curtis L. Olson [EMAIL PROTECTED] said: 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. I've been working toward this sort of thing...slowly severing the ties between the model code and the viewer so that we can have multiples of both. The new viewer interface will make it possible to have multiple FDM's and changes I'm planning for the model code over the next week will make it entirely autonomous. Already I have it generating its own local matrix (had to for the tower view). Once this is done we can see what we have and figure out a system for managing the components. As for Justin's project, rendering the moving ship should be quite easy once all I have planned now for the viewer/model is done (probably within a week). All that will be necessary is something that will update the position and orientation values for the ship. It can be a simple as a script that updates properties through the tcp interface every half second. The bigger problem (or so it seems to me :-)) is the one Andy brought up. How you model stopping on a moving runway. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
On Thu, 4 Apr 2002 20:50:18 - Jim Wilson [EMAIL PROTECTED] wrote: I've been working toward this sort of thing slowly severing the ties between the model code and the viewer so that we can have multiples of both. The new viewer interface will make it possible to have multiple FDM's and changes I'm planning for the model code over the next week will make it entirely autonomous. Whoa! We'd better coordinate on this. I've got a mechanism for multiple FDMs already figured out for JSBSim. It doesn't break anything that any other FDM does, either, I believe. What are you doing with the way FDMs are instantiated?! The bigger problem (or so it seems to me :-)) is the one Andy brought up. How you model stopping on a moving runway. This really is not a big deal after all, I think. The gear model calculates forces and moments imparted to the aircraft based on the aircraft motion and elevation (and we really should be modeling non-vertical-normal surfaces, too). We simply need to change the elevation in a dynamic way (and the aircraft will respond appropriately) and feed the local frame runway motion to the aircraft so it can calculate the relative motion of the aircraft wrt the runway. The rest will work as is. The aircraft will have a residual airspeed and forces/moments will be generated appropriately. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Jon S. Berndt wrote: Jim Wilson wrote: The bigger problem (or so it seems to me :-)) is the one Andy brought up. How you model stopping on a moving runway. This really is not a big deal after all, I think Agreed. Inside the gear model, the problem is basically an extra addition to the relative velocities. The problem is how to represent that to the rest of the architecture without making a gooey mess. :) I'm becomming more and more convinced that the right solution is just to special case carrier decks rather than handle this generically. 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
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Andy Ross writes: 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 I've considered something similar, but I don't think it's scalable. Imagine two year from now, if people have created tens of thousands of custom objects for scenery around the world. This requires more thought. 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 hadn't thought of that -- interesting. 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. What about landing a helicopter on top of a moving train in a James Bond emulator? This is a nasty problem. I do think that it should be possible to locate the ssgVertexTable under the wheels, walk up to the nearest branch, then lock the gear to the object's motion somehow. Probably not this week, though. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Jim Wilson writes: I've been working toward this sort of thing...slowly severing the ties between the model code and the viewer so that we can have multiples of both. I started a model overhaul myself this afternoon (it's been a little overdue). Basically, I'm separating the animation code out so that it can be used for any 3D model (windsock, aircraft carrier, waving field of grain, or what-have-you) rather than just for the aircraft. Essentially, this should remove all dependencies on the viewer, since the model will have to calculate its own matrices (it could be at any location). I'll give up and revert if it gets too hard. Jim: does this conflict with anything you're doing? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
David Megginson wrote: I've considered something similar, but I don't think it's scalable. Imagine two year from now, if people have created tens of thousands of custom objects for scenery around the world. This requires more thought. True enough. I was really thinking more along the lines of a few objects that need to be controllable and/or scripted. Moving carriers are like this, consider a Python script or whatnot that handled the battle group's movements through the property system. Other types of dynamic scenery will obviously have different requirements. Stuff like FS2002's auto-generated tree models simply can't go through the property system. But that's OK, since ephemeral vegetation doesn't have a lot of functional overlap with warships. We can handle both separately as different types of DCS objects. What about landing a helicopter on top of a moving train in a James Bond emulator? This is a nasty problem. I do think that it should be possible to locate the ssgVertexTable under the wheels, walk up to the nearest branch, then lock the gear to the object's motion somehow. Well, the locking of the gear is easy -- just add the velocities and the FDM will do the right thing. It's the storage of the velocities that a mess. Doing this right would essentially mean storing a velocity (normal and angular -- 6DOF) for every leaf of the SSG scene graph. More, if the leaves are custom objects that have moving sub-parts. Ick. Like I said, specially casing train roofs as aircraft carriers sounds more palatable. 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
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
On Thu, 2002-04-04 at 13:33, Jon S Berndt wrote: On Thu, 4 Apr 2002 21:24:06 - Jim Wilson [EMAIL PROTECTED] wrote: believe. What are you doing with the way FDMs are instantiated?! Absolutely nothing. But if your mulitple FDM instances can publish position/orientation data into a seperate property tree location for each instance, we'll be golden in the viewer and model code. Phew! Good. Yes, I think we can (or will be able to) do that (publish each instance position data). We have _planned_ on being able to, anyway. Tony will have to comment on the specifics, though. We'll have to talk about how to implement this. Right now, it would all be in /fdm/jsbsim[1,2,3...]. We need a non-FDM specific way of handling both this sort of thing and xml-defined parameters. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Tony Peden writes: We'll have to talk about how to implement this. Right now, it would all be in /fdm/jsbsim[1,2,3...]. We need a non-FDM specific way of handling both this sort of thing and xml-defined parameters. Here's what I've been thinking of (for a while): 1. Add methods something like these: SGPropertyNode * FGSubsystem::getBranch (); void FGSubsystem::setBranch (SGPropertyNode * branch); 2. Whenever tying or referencing properties specific to a vehicle, session, or whatever, reference them relative to the branch: double throttle = getBranch()-getDoubleValue(controls/throttle[0]); 3. At the top level, manage a separate branch for each vehicle. Perhaps an easier solution would be simply to swap property trees in and out for each vehicle, like process pages in a CPU. That makes it hard to access global (non-vehicle-specific) state, though. Comments? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
Jim Wilson writes:
On second thought why don't we go with what you are doing for the
time being. I think I can get by with my view manager and viewer
changes as long as your model code is independent of the viewer and
the view manager. Then if you want to go with the model
position/orientation config that I described in the previous
message, I can add that next week to the model and viewmanager
code.
Sounds good. I'll check in my changes, then, as soon as they're
working.
While we're talking about refactoring, I think that it might be time
to consider creating something like an FGLocus class, to keep track of
a single location. Its interface would look a lot like the viewer's:
class FGLocus
{
public:
FGLocus ();
virtual ~FGLocus ();
virtual double getLongitudeDeg () const;
virtual double getLatitudeDeg () const;
virtual double getAltitudeFt () const;
virtual void setPosition (double lon_deg, double lat_deg, double alt_ft);
virtual double getRollDeg () const;
virtual double getPitchDeg () const;
virtual double getHeadingDeg () const;
virtual void setOrientation (double roll_deg, double pitch_deg,
double heading_deg);
virtual const sgMAT4 getTransformMatrix () const;
};
I can create an instance of this for everything I want to place in
FlightGear (a viewpoint, a 3D model, scenery, etc.) and all the
transformation code is in one place, so Norm can easily optimize it.
We could also add XYZ/RPH offsets, as with the viewer.
Most of the work of creating this class would just be cutting and
pasting from your current viewer class. What do you think? There's a
lot of duplicate code right now doing exactly this including code in
the new FG3DModel class I'm about to check in, and it would be nice to
purge it.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
David Megginson [EMAIL PROTECTED] said: While we're talking about refactoring, I think that it might be time to consider creating something like an FGLocus class, to keep track of a single location. Its interface would look a lot like the viewer's: Yes I was thinking the same thing. If you want to, go ahead, but for the time being I'm up to my ears in viewmgr and properties and would like to get that running with what is here now for a viewer. I'll bring FGLocus in next week. BTW I may need some help doing the property stuff correctly in view manager after its running. Still a little vague on some of the property code especially considering how much i've used it. No problem getting it working, it just might not be the best approach, but I'll let you look and make suggestions. Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving carrier, and Repositioning questions
On Thu, Apr 04, 2002 at 07:57:00PM -0500, David Megginson wrote: Tony Peden writes: We'll have to talk about how to implement this. Right now, it would all be in /fdm/jsbsim[1,2,3...]. We need a non-FDM specific way of handling both this sort of thing and xml-defined parameters. Here's what I've been thinking of (for a while): 1. Add methods something like these: SGPropertyNode * FGSubsystem::getBranch (); void FGSubsystem::setBranch (SGPropertyNode * branch); 2. Whenever tying or referencing properties specific to a vehicle, session, or whatever, reference them relative to the branch: double throttle = getBranch()-getDoubleValue(controls/throttle[0]); 3. At the top level, manage a separate branch for each vehicle. Perhaps an easier solution would be simply to swap property trees in and out for each vehicle, like process pages in a CPU. That makes it hard to access global (non-vehicle-specific) state, though. Comments? The latter would certainly be easier, no code would need to be changed. Wouldn't it have the effect of forcing client code to keep track of which vehicle was being referenced in the tree? A good example here, I think, would be the view manager. Another good example would be the real-time plotting code Curt discussed a few weeks back. In both cases, just blindly using the data in the tree would be likely to have some interesting results. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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
