Mathias Fr�hlich wrote:
> Sent: 20 October 2004 07:41 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] status of aircraft carrier > > 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 ... 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. > > 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. 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. > So all together: if lat/lon/alt is omitted in those computations, we can > get > the same effect with less computations. Yes, agreed. > 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. Good > 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, let's go for it. > > 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... Just teasing :-) - some arbitrary number related to number of wires in the surface and aircraft type will do in due course: Buccaneers almost always caught a wire, Gannets suffered from hook skip and often had to do a bolter. > With that cache it would also be easy to model individual wires. If we > have > them deterministically modelled, multiply with some catch propability. > That would be nice, but a surface would probably do to start with. The probability of catching a wire is more to do with the aircraft than with the wire if we model individual wires, if we use a surface then we would need to add a probability related to the number of wires in the surface, but this would be pretty arbitrary. 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. Regards, Vivian _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
