On Dienstag 19 Oktober 2004 21:23, Vivian Meazza wrote:
> > Hmm,
> > I am not satisfied with anything which is only working on a per frame
> > basis.
> > Just because, if so, we will have different bevour of our physical models
> > dependent of the frammerate.
>
> I think I put this bit badly. The geodetic output would be dependent on the
> speed of an iteration loop. If we are only modeling an arrester wire
> _surface_ it should suffice. I can generate some proof-of-principle code
> for this quite readily, I think. I'll see what I can do.
Ok, let's start now :)
I would like to have those positions of the arrester wires not in lat/lon/alt
but rather than in earth centered coordinates (cartesian coordinates: x
towards lat/lon=0, z towards northpole). Just because we already have all
scenery values stored in this format. We have a scenery reference point and
relative to that, we have rotated vertices.
With those values we can cheap compute (double valued) positions of these
vertices. And then transform them, just by translation and rotation, to some
coordinate frame required for modelling the hook, gear ...
If you use geodetic lat/lon, you need to transform the values to geodetic
lat/lon/alt values which is expensive as such since this requires the use of
an iteration method. And then transform those values back to that same flat
coordinate space suitable for comuting ground reactions.
For that backtransform, I can't think of anything not using those earth
centered corrdinates.
So all together: if lat/lon/alt is omitted in those computations, we can get
the same effect with less computations.
What I have here in my private tree, is code to have a small, per FDM
instance, cache of ground tiles around the aircraft. With this one it is easy
to taxi on slopes. Also if such arrester wires are stored there, it would be
easy to compute the interactions with them.
Intersections with those few triangles can then be done often per timestep,
since there are only few triangles in that cache. The cache itself is at the
moment filled on demand, whenever the FDM cannot find a triangle below the
contact point, the scenegraph is queried for a new triangle.
That works for our scenery, but for that simple plane modelling the arrester
wires, this does not work, since we find a triangle from the scenery, we do
never query the triangles modelling the wires.
What I plan to do here, is to build up a cache of all triangles in the area of
an aircraft. This is easy to do with the hierarchical boundingbox
intersection routines from ssg*.
Having that cache, then implement wires as geometry nodes in the scene graph,
which will then show up in the cache if we are near them. Intersection with
geometry nodes in that cache can be implemented using ssg routines.
Coupling the results into a FDM is straight forward.
This approach with that cache would also allow to implement this stuff
together with FDM's in child processes or even different machines, like Curt
was talking about some time ago.
> My main conceptual difficulty is the compass alignment of the arrester wire
> surface. If we test the hook position in geodetic terms, i.e. lat a < hook
> pos < lat b etc. how do we account for the odd triangles at the corners?
See above ...
Use cartesian coordinates for that and then use ssg* for that.
My head includes the solutions here :)
Seriously, I have much of a concept here. So if we can work together, we might
be faster :)
> Good point. The probability of catching a wire given that the hook
> intersects the wire surface is ... ? Some function of hook design, number
> of wires, aircraft velocities, ship velocities ... some pure chance ... ?
Yep, this kind of stuff. But not relevant at this stage of development...
With that cache it would also be easy to model individual wires. If we have
them deterministically modelled, multiply with some catch propability.
Greetings
Mathias
--
Mathias Fr�hlich, email: [EMAIL PROTECTED]
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
