Jon S. Berndt wrote:
> 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.
You have a chicken-and-egg bug here: The tire contact point is
*defined* as the intersection of the gear compression vector with the
ground. You can't possibly ask for the elevation beneath it until you
know it. Going back to the same diagram, the point of the wheel is
the "result" of the collision detection algorithm. All the input
knows is the base point and the point beneath the ground:
+ <-- gear min extension point
.\
. \
. \
elev . (\) <-- computed contact point
ation->. ++---------------
. / \
. / + <-- gear max extension point
./
/
Really, I'm sorry if this seems arrogant. I'm trying to be nice.
But, well, despite how much you think you're right here, ... you're
not. This algorithm you propose is incorrect. It's not terribly
incorrect, since it works great for lots of situations. But the
discussion at hand was how to improve the gear handling. If we're
going to improve it, isn't it worth considering all the available
solutions and picking the best one?
> 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?
OK, it's my turn to make a (mild) snipe. You've been arguing with me
on this point all day, through many message, and have finally ended up
calling me arrogant. But you haven't read through the original
suggestion that started it all??? Jeez, Jon, if you had questions,
why didn't you ask them BEFORE dropping your bombs? OK, having blown
off that steam, the suggestion was simply this:
// Calculates and returns a point of scenery intersection that lies on
// the line segment between p1 and p2. If the line segment intersects
// the scenery more than once, then the point closest to p1 is chosen.
// All coordinates are in global cartesian.
sgdVec3 fgGetSceneryIntersection(sgdVec3 p1, sgdVec3 p2,
sgdVec3* normalOut);
If you want to use this interface to do vertical-only compression,
then there is nothing stopping you. But an interface that does *only*
vertical-only compression does not work right for the intersection
calculations I want to do for things like ski jumps, etc...
> > 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
Jon, cut me some slack here. How else would I have written that
paragraph? I mean, I stand by the statement: it is the correct
algorithm for this problem. Am I arrogant just because I think you
are wrong? Can I call you pig-headed because you don't think I'm
right? (If it's not obvious, please insert LOADS of smileys in the
above sentence).
Look at it from my side: there is a cool new feature that *almost*
does what I want it to do. But it can't do what I want unless I get
an interface change. But I can't get that interface change unless the
other FDM authors agree to use it too. So I advocated my solution.
Part and parcel of advocating one solution over another is (1)
explaining why my way is good and (2) explaining why the alternative
is bad. So I called your mechanism bad. Is that an attitude problem
or a debate? Where is the line? How might I have made the same
technical points in a way that doesn't seem so arrogant?
Andy
--
Andrew J. Ross NextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
"Men go crazy in conflagrations. They only get better one by one."
- Sting (misquoted)
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
