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

## Advertising

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