On Fri, 15 Mar 2002 16:40:38 -0800 Andy Ross <[EMAIL PROTECTED]> wrote:
>Here's another ASCII diagram (please don't mock this one) >to try to explain: This is actually pretty good for an ascii diagram and it shows where the misunderstanding is coming onto play. > > + > .\ > . \ <--gear strut > . \ >elev . (0) >ation->. +---------------- > . / > . / ground > ./ > / > >Here, the elevation says that the gear is clear of the ground. We, of course, track the local frame position of the contact point of the tire. We are not measuring elevation using the CG, nor the attach point of the strut to the body. I keep repeating myself here, but when I ask for elevation, I am asking for it at the point DIRECTLY BELOW THE TIRE CONTACT POINT. JSBSim can provide a lat/lon for that point. > But that is wrong! The gear strut points forward, and the >gear should, in fact, be sitting nicely on the edge as shown. Which we would track properly, given that the elevation below the *tire* is reported. >My way, which computes an intersection between the gear base and the >maximum extension point below the ground, works fine here. It is the >correct algorithm for this problem. How typically arrogant. It's not your approach, it's your attitude. You are perfectly welcome and free to do things in whatever way you desire - I'm not stopping you at all. I am just considering taking Norman up on his suggestion that a per-wheel elevation can be given. Your algorithm is "correct" for what you want to do. There are tradeoffs and approximations that can be made anywhere in the sim. You may pay more attention to areas here and there than we do, or do things different here and there than we do. That makes your approach different, or more precise, or more approximated, or whatever. Given all the factors to consider in simulation, it doesn't make it uniquely and alone "_the_ correct" solution. It's called "simulation" after all. >> Either you are missing my point, or I am missing yours. > >Both, it seems. Let's try this: You want to handle (1) aircraft on >non-level-but-flat ground so that they tilt and (2) non-flat areas >where two polygons with different normals meet. [You agree with me >this far, right? Have I misrepresented?] > >OK, now my point: > >In order to handle case #2, you are willing to make the assumption >that gear compression is always along the up vector from the ground >and simply use the elevation at that point. [Are we still on the same >page? Do you not see why this must be?] > >So, your proposed solution can handle the case where the ground is >non-level, but flat, or the case where the ground is non-flat, but >level, but it fails in the case where the ground is both non-flat and >non-level. Disagree. I am assuming by "flat" you mean that the polygon and any adjacent polygons have parallel normals and that "level" means a vertical normal. ? As long as any polygon that the tire sits on has a reasonable surface normal (i.e. say within ten degrees of vertical) then we'll do fine. Anything else is likely a crash, anyhow. >I argue that the only interesting non-flat or non-level cases happen >together. This is true for ski jumps. It is true at catalina. It is >true at the edge of a cliff. We could handle either. >I further argue that it requires no more work on the part of the FDM >or the scenery code to do this the Right Way: by computing an >intersection point along the gear's axis of compression. I even >posted a putative interface for such code, which you and Tony, for no >reason that I can for the life of me figure out, hate with a >passion. :) I can't remember rejecting your interface. But go ahead and do things your own way - like I said I have no objection to you doing whatever you want to do. That's not my place. >Try turning it around. Rather than justify why your way is Good >Enough, tell me why my way (which, I think we all agree, is >technically more correct) is harder? Or more expensive? Or uglier? >Or... what? I still haven't seen a good overall description of exactly what it is that you are proposing. Can you give me a reference to the message? >Stated as simply as I can possibly say it: The simplifications that >you want to make are (1) unnecessary and (2) incorrect. There are >better ways of doing ground intersection code. Again, how arrogant. It's been done like this for a long time. That doesn't make it correct. But it works. It's not incorrect. Your way may be more precise, and handle various odd special cases that at the moment we don't really care about, and that's fine. I'll hand you that. But, you've got to get over this attitude and learn to make a distinction between precision, approximation, and "correctness". Jon _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
