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

Reply via email to