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.
> 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. Moving and rotating triangles for the
ac carriers deck, and special elements like the wires/catapults.
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.
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).
> 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.
greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
