Mathias Fr�hlich wrote:
> Sent: 21 October 2004 07:31 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > On Mittwoch 20 Oktober 2004 09:49, Vivian Meazza wrote: > > We calculated the output in geodetic terms (lat/long/alt) for submodels > so > > that they could be displayed, and it's no problem to output in x,y,z > > aircraft terms. It didn't seem to be expensive computationally. Further, > > lat/long/alt was the easiest to get at for the aircraft location. I > think > > that I'll need some help here with the necessary conversion factors. > I'll > > look into it further. > The problem is that those values are in geodetic lat/lon. The underlying > transform to an elliptical coordinate space is done in sgCartToGeod in > SimGear/simgear/math/sg_geodesy.cxx. There is also a paper about this > stuff > floating around. > But it is sufficient to know that this transform is significantly more > expensive than doing a scalar times vector. Unless I can find a way to get at the XYZ positions we're stuck with it. However, my initial impression, admittedly on a pretty powerful machine is that the computation effort is not significant. > > > Do we need ground reactions as an intrinsic part of this code? Although > I > > can see that it might represent an opportunity to improve the current > > situation. > I think so. > I cannot see a way to model the earths surface with different properties > like > runnway/grass/water with load factor. In principle you need to tell the fdm what static and dynamic coefficients of friction to apply for each type of surface - I think I've seen suitable figures around on the net. Did you mean water lying on runway/grass or the sea? That�s just another coefficient of friction. I think the hydrodynamics of floats are a whole new ballpark. We shouldn't tackle that, but we need to recognize that we now have a float plane in the inventory, so someone might like to do it some time. > Moving and rotating triangles for > the > ac carriers deck, and special elements like the wires/catapults. This is a similar problem to the position of the hook tip relative to the origin of the aircraft. We should be able to adapt the (soon to be) existing code. > Ok, this can be put into the property tree as we have a structure broken > out > into scalar values. But I guess that this provides a huge overhead for > that > stuff. If you do serious computatiions with those values you will need to > transform them back into structs/classes/whatever. > > > Good, let's go for it. > Ok, yesterday evening I did that hierarchical boundingbox stuff. It looks > very > hackish at the moment and I first need to seperate out some stuff also in > that experimental tree before I can send you what I have. I hope to get > that > done today evening ... > > I can taxi on slopes and get all surfaces/lines in an ball aroung the > aircraft. > > So If you can think about, how we can inject our preliminary wire area > into > the scenegraph, we will be some step ahead. > :) > I thought about using normal ssgLeafs for such a thing with some special > information that this is a wire area stored in the UserData field of > ssgBase. I was thinking on similar lines. Let's start with that and see how we evolve. > Really, modelling individual wires with lines is also not a big deal. > So If we could inject individual wires every 5 meters on the whole KSFO > runway > (I am not a good pilot for testing ... :) we can start with that. > > A word for testing if a wire is caught: > The hook (think of it as a line) has a position before the integration > step. > Past integration, it has a new position. The rectangle spanned by those > two > lines is the area where the hook was during that integration step. > If a wire line intersects this rectangle, we have cought that wire (when > we > assume for now and testing, that we catch every wire we touch). Yes, good, I hadn't thought that far. This should work > > I'll get on with seeing if I can provide hook position - we would be > well > > under way with that. I think this would be a worthwhile activity since > we > > seem to have most of the bits almost in place. > Yep this hook position is also something we will need. > As I told, best in (double valued) cartesian coordinates relative to the > earth's center. The only common output from the fdms that I can get hold of right now seems to be LLZ. Not to worry for now, my code will only need a small change to cope with XYZ. Regards, Vivian _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
