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
> 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

> 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.



Flightgear-devel mailing list

Reply via email to