Michael Selig wrote:
At 3/14/02, you wrote:
Just a quick note and question. I've been able to get engine sound
for the different models except the UIUC models. Specifically I've
been running the different versions of the Cessna 172. JSB and
Larcsim both produce engine sound but UIUC
Tony Peden writes:
You need to write the data to the appropriate properties. You might
take a look at JSBSim.[ch]xx and what we're doing with the
/surface-positions/elevator-pos-norm
/surface-positions/rudder-pos-norm
etc.
For LaRCSim, I just added code to copy the control inputs
Marcio Shimoda writes:
Well, this is a problem
The current version of ssgLoadMDL just loads the all the information in mdl
file. It doesn't know what is loading, if is a wheel or other moving part.
Fortunately, that doesn't matter. We specify animations externally
using an XML config
Erik Hofman writes:
To get it working the UIUC code should populate the property tree with
at least the following properties (for a piston engine driven aeroplane):
starting/stoping the sounds:
---
/engines/engine/cranking
/engines/engine/running
Hi,
Does anybody else have problems with the engine sound (it doesn't start
playing)?
I have a very weird problem over here and was wondering if I am the only
one.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
David Megginson wrote:
Erik Hofman writes:
To get it working the UIUC code should populate the property tree with
at least the following properties (for a piston engine driven aeroplane):
starting/stoping the sounds:
---
/engines/engine/cranking
David Megginsson wrote:
Marcio Shimoda writes:
Well, this is a problem
The current version of ssgLoadMDL just loads the all
the information in mdl
file. It doesn't know what is loading, if is a wheel
or other moving part.
Fortunately, that doesn't matter. We specify
Per Liedman writes:
MDL is not a format used for modellers, it's more like
a compiled binary format used for MSFS. This means that
it *does not* contain object names. Hence, ssgLoadMDL does
not preserve object names, since there are no names to
preserve. :-)
Having said that,
Erik Hofman wrote:
Hi,
Does anybody else have problems with the engine sound (it doesn't start
playing)?
I have a very weird problem over here and was wondering if I am the only
one.
I've got exactly the same problem under W2k/MSVC.
CU,
Christian
--
The idea is to die young as late
ARRRG
I just discovered this piece of code in the CVS
} else {
*(int*)0=0; // unexpected tag, boom
}
}
I will leave the name calling and expletives out but
THIS IS RUDE ARROGANT AMATURISH PROGRAMMING
TO THE MAX and completely UNACCEPTABLE in a complex
project like FlightGear
Hi guys I implemented rendering Flightgear in black and white mode using
Geforce rendering combiners
here is a sample jpeg
If some one intrested in doing this I can describe technique
It's extremly usefull for simulating missile and bomb camera views or for
helicopter simulation
attachment:
Norman Vine writes:
Note for the FDM writers This means that queries for multiple 3
or 4 gear locations should be quicker then just the single query
was before
That's good news -- I'd like to encourge the FDM writers to query
separately for each gear now, at least for the wheels and
Hi,
is there a reason why FGSubsystem uses an int as dt?
Shouldn't this be a float? And what unit does it have? Seconds or
milliseconds?
CU,
Christian
--
The idea is to die young as late as possible.-- Ashley Montague
Whoever that is/was; (c) by Douglas Adams would have been
On Fri, 15 Mar 2002 09:44:07 -0500
1) CHANGE THIS ASAP to at least print an error message
or
2) defend this hack publicly
Where is the code located?
=
There is some good news however
After discovering that the above was responsible for
unexplained crashing at startup with
On Fri, 15 Mar 2002 17:47:37 +0300
Roman Grigoriev [EMAIL PROTECTED] wrote:
Hi guys I implemented rendering Flightgear in black and white mode using
Geforce rendering combiners here is a sample jpeg
It's extremly usefull for simulating missile and bomb
camera views or for helicopter
On Fri, 15 Mar 2002 10:00:28 -0500
David Megginson [EMAIL PROTECTED] wrote:
That's good news -- I'd like to encourge the FDM writers to query
separately for each gear now, at least for the wheels and skids (crash
points aren't as serious).
So, when querying, would we supply the lat/lon/radius
Norman Vine wrote:
ARRRG
There is some good news however
After discovering that the above was responsible for
unexplained crashing at startup with some configurations
I can announce that I have a new Height above Ground algorithm
that is MUCH faster read order of magnitude
At
Christian Mayer wrote:
Erik Hofman wrote:
Hi,
Does anybody else have problems with the engine sound (it doesn't start
playing)?
I have a very weird problem over here and was wondering if I am the only
one.
I've got exactly the same problem under W2k/MSVC.
Hmm, back to the drawing board.
Jon S Berndt wrote:
On Fri, 15 Mar 2002 09:44:07 -0500
1) CHANGE THIS ASAP to at least print an error message
or 2) defend this hack publicly
Where is the code located?
Hehe, relax it's not JSBSim ...
Erik
___
Flightgear-devel mailing
Jon S Berndt
On Fri, 15 Mar 2002 10:00:28 -0500
David Megginson [EMAIL PROTECTED] wrote:
That's good news -- I'd like to encourge the FDM writers to query
separately for each gear now, at least for the wheels and skids (crash
points aren't as serious).
So, when querying, would we supply the
* [EMAIL PROTECTED] (Jon S Berndt) [2002.03.16 09:40]:
On Fri, 15 Mar 2002 09:44:07 -0500
1) CHANGE THIS ASAP to at least print an error message
or
2) defend this hack publicly
Where is the code located?
$ find . -type f | xargs grep (int\*)0=0
./src/FDM/YASim/FGFDM.cpp: *(int*)0=0;
On Fri, 2002-03-15 at 08:47, Norman Vine wrote:
Jon S Berndt
On Fri, 15 Mar 2002 10:00:28 -0500
David Megginson [EMAIL PROTECTED] wrote:
That's good news -- I'd like to encourge the FDM writers to query
separately for each gear now, at least for the wheels and skids (crash
points
Hi,
when I run a self compiled FGFS I get many of output (keybinding and
other stuff).
But when I run a version that has been compiled with CygWin it's much
less.
Is there a #define so so that I can set to reduce the amount of data?
CU,
Christian
--
The idea is to die young as late as
Tony Peden writes:
Norman Vine wrote:
Jon S Berndt
David Megginson [EMAIL PROTECTED] wrote:
That's good news -- I'd like to encourge the FDM writers to query
separately for each gear now, at least for the wheels and skids (crash
points aren't as serious).
So, when querying, would we
Just run ./configure --without-logging
Regards,
Curt.
Christian Mayer writes:
Hi,
when I run a self compiled FGFS I get many of output (keybinding and
other stuff).
But when I run a version that has been compiled with CygWin it's much
less.
Is there a #define so so that I can set to
Norman Vine wrote:
ARRRG
I just discovered this piece of code in the CVS
} else {
*(int*)0=0; // unexpected tag, boom
}
I will leave the name calling and expletives out but
THIS IS RUDE ARROGANT AMATURISH PROGRAMMING
TO THE MAX and completely UNACCEPTABLE in a
Norman Vine wrote:
Jon S Berndt wrote:
David Megginson wrote:
That's good news -- I'd like to encourge the FDM writers to query
separately for each gear now, at least for the wheels and skids (crash
points aren't as serious).
So, when querying, would we supply the
Roman Grigoriev wrote:
Hi guys I implemented rendering Flightgear in black and white mode
using Geforce rendering combiners here is a sample jpeg If some one
intrested in doing this I can describe technique It's extremly usefull
for simulating missile and bomb camera views or for
Andy Ross writes:
This is correct only so long as the gear struts are pointing straight
down, with many aircraft (even at their touchdown attitude) this isn't
the case. How much harder would it be to give you a gear location and
an extension vector, and get the intersection of that vector
Christian Mayer writes:
Curtis L. Olson wrote:
Just run ./configure --without-logging
With MSVC? Nope.
But if you can tell me what --without-logging changes (e.g. defining
something or so) I can change my workspace accordingly.
Let's see, peering into the configure.in file I see:
Jon S Berndt writes:
So, when querying, would we supply the lat/lon/radius of
each bogey of interest, then get the height above ground?
I think so. We might want to rewrite the interface so that you can
supply offsets in meters, but that would require a bit of thought.
All the best,
Tony Peden writes:
So then, we'd need to convert from our body coordinates to FG's global
cartesian?
You already have the absolute position, so you need only to add in the
body coordinates rotated to the body axes, I think.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
I wrote:
This is the YASim XML parser. You hit this line when an
unrecognized tag is found in the XML file.
In an attempt to keep blood pressures in a healthy range this morning,
I've modified the YASim parser to print messages and exit on parse
errors, rather than crash.
It's still no
On Fri, 2002-03-15 at 09:47, Andy Ross wrote:
Norman Vine wrote:
Jon S Berndt wrote:
David Megginson wrote:
That's good news -- I'd like to encourge the FDM writers to query
separately for each gear now, at least for the wheels and skids (crash
points aren't as serious).
Curtis L. Olson wrote:
Just run ./configure --without-logging
With MSVC? Nope.
But if you can tell me what --without-logging changes (e.g. defining
something or so) I can change my workspace accordingly.
CU,
Christian
--
The idea is to die young as late as possible.-- Ashley
On Fri, 15 Mar 2002 13:15:04 -0500
Norman Vine [EMAIL PROTECTED] wrote:
Who better then the FDM to know the offsets of the points to test for
contact. It certainly shouldn't be anything in the Scenery Module !!
Norman
Yep. I think all we (FDM) need is a function that returns
the terrain
tarball for new hitlist code
http://www.vso.cape.com/~nhv/files/fgfs/new_hitlist.tgz
For those of you not using the CVS version of PLib
you will need a copy of sgdPointInTriangle()
from the older hitlist.cxx this one replaces
Enjoy
Norman
___
At 3/15/02, you wrote:
David Megginson wrote:
Erik Hofman writes:
To get it working the UIUC code should populate the property tree
with at least the following properties (for a piston engine driven
aeroplane):
starting/stoping the sounds:
---
Andy Ross writes:
Norman Vine wrote:
Jon S Berndt wrote:
David Megginson wrote:
That's good news -- I'd like to encourge the FDM writers to query
separately for each gear now, at least for the wheels and skids
(crash
points aren't as serious).
So, when querying, would we
Jon S Berndt writes:
On Fri, 15 Mar 2002 13:15:04 -0500
Norman Vine [EMAIL PROTECTED] wrote:
Who better then the FDM to know the offsets of the points to test for
contact. It certainly shouldn't be anything in the Scenery Module !!
Norman
Yep. I think all we (FDM) need is a
On Friday 15 March 2002 01:57 pm, you wrote:
At 3/15/02, you wrote:
[2] Where should we put the sound files. Right now the files are in
~fbfsbase/Sounds. But different aircraft will have different
sounds. Should these sound files go in the respective ~fgfsbase/Aircraft
directories?
Jon S Berndt writes:
. We can get complicated at
some point in the future. Right now all we want is to be
able to determine the elevation at a given lat/lon.
Jon
I URGE you and everyone else to think in terms of 'direction cosine'
XYZ's instead of lat/lons and where possible to use the
Jon S Berndt writes:
If the aircraft is not aligned vertically (or nearly so),
the wingtips (or other contact points) will scrape and
gear location will be irrelevant. Indeed, at extreme
angles the gear will either be inaccessible or will be
treated as a hard contact point. We can get
Norman Vine wrote:
Who better then the FDM to know the offsets of the points to test
for contact. It certainly shouldn't be anything in the Scenery
Module !!
Of course not. You would be told the points to test by the FDM.
The problem is that the gear aren't simple points; they can
Andy Ross writes:
Of course not. You would be told the points to test by the FDM.
The problem is that the gear aren't simple points; they can compress,
and thus are geometrically line segments.
And occasionally they are a more complex linkage and can follow funky
curves (or in the case of
Jon S. Berndt wrote:
If the aircraft is not aligned vertically (or nearly so), the wingtips
(or other contact points) will scrape and gear location will be
irrelevant. Indeed, at extreme angles the gear will either be
inaccessible or will be treated as a hard contact point. We can get
On Fri, 15 Mar 2002 13:55:10 -0600 (CST)
Curtis L. Olson [EMAIL PROTECTED] wrote:
... the gear extension angle and extension amount will move the
lon/lat of the contact point. Perhaps the differences won't be
significant enough to significantly change the resulting ground
elevation?
Jon S Berndt writes:
The best solution would be for the UIUC guys to bite the
bullet and port their work to use JSBSim. :-) :-) :-)
Hmm -- today seems to be a big day for trolls. I wonder if any of
Jon's NASA contacts are still waiting for him to bite the bullet and
port JSBSim to
David Megginson writes:
Jon S Berndt writes:
The best solution would be for the UIUC guys to bite the
bullet and port their work to use JSBSim. :-) :-) :-)
Hmm -- today seems to be a big day for trolls. I wonder if any of
Jon's NASA contacts are still waiting for him to bite the
Curtis L. Olson writes:
This is true in extreme cases, but even at angles where the gear would
hit first (maybe more so for certain aircraft configurations), the
gear extension angle and extension amount will move the lon/lat of the
contact point. Perhaps the differences won't be significant
David Megginson wrote:
Jon S Berndt writes:
The best solution would be for the UIUC guys to bite the
bullet and port their work to use JSBSim. :-) :-) :-)
Hmm -- today seems to be a big day for trolls. I wonder if any of
Jon's NASA contacts are still waiting for him to bite the
Norman Vine wrote:
Unless runways aren't anywhere near as flat in reality as I was
trained to build them when I was in the Corp of Engineers I wouldn't
expect a difference of 1-2 meters in a horizontal direction to be more
then a couple of centimeters in the vertical. ie dy/dx usually
I guess we could try to model running over 'curbs and 'potholes' ' but
Would it be that difficult to do? It certainly would add some fidelity to
the ground-handling. Is this the kind of thing that's required handling
in the Level D sims?
g.
--
I'm not crazy, I'm plausibly
On Friday 15 March 2002 02:20 pm, you wrote:
Michael Selig writes:
Thanks for all the input on this. It helped get us going. The
properties structure is pretty neat!
Thanks.
If few questions (probably too many):
[1] Does it sense to define and set our properties inside
The best solution would be for the UIUC guys to bite the
bullet and port their work to use JSBSim. :-) :-) :-)
Hmm -- today seems to be a big day for trolls. I wonder if any of
Jon's NASA contacts are still waiting for him to bite the bullet and
port JSBSim to FORTRAN.
Why?
* YASim can use the flat earth to compute a consistently flat runway
for the gear to press against, for example. With a per-gear
elevation like this, there would be no way to prevent the airplane
from seeing a stair-step (really, escalator) configuration
instead, which doesn't
* [EMAIL PROTECTED] (Norman Vine) [2002.03.16 14:42]:
Curtis L. Olson writes:
This is true in extreme cases, but even at angles where the gear would
hit first (maybe more so for certain aircraft configurations), the
gear extension angle and extension amount will move the lon/lat of the
Jon S. Berndt wrote:
Andy Ross wrote:
Ski jumps are an immediate counter example.
Modeling ski jumps are the one example I can think of - the single
special case - where this is important. [How many terrain polygons
will it take to accurately model a ski jump, anyhow?] I'm not sure I
On Fri, 15 Mar 2002 12:50:08 -0800
Andy Ross [EMAIL PROTECTED] wrote:
And even so, it's not the *position* of the gear tip that is the
problem, it is the *direction* of the compression vector. An 20
degree difference from vertical (not a terribly uncommon AoA for a jet
touchdown, or bank
On Fri, 15 Mar 2002 16:24:44 -0500
David Megginson [EMAIL PROTECTED] wrote:
If the FDM guys would like it, it would be very easy to add some extra
fields to $FG_ROOT/materials.xml and make them available through the
scenery code. For example, we could provide parameters for magnitude
and
On Friday 15 March 2002 05:15 pm, you wrote:
The best solution would be for the UIUC guys to bite the
bullet and port their work to use JSBSim. :-) :-) :-)
Hmm -- today seems to be a big day for trolls. I wonder if any of
Jon's NASA contacts are still waiting for him
On Fri, 2002-03-15 at 13:03, Andy Ross wrote:
Jon S. Berndt wrote:
Andy Ross wrote:
Ski jumps are an immediate counter example.
Modeling ski jumps are the one example I can think of - the single
special case - where this is important. [How many terrain polygons
will it take to
Jon S Berndt writes:
I wonder if modeling this as a pure aural cue would be
enough?
Until Linux and PLIB support force-feedback controllers, it might be.
For many surfaces, though, we will want the plane to bounce around
visibly.
All the best,
David
--
David Megginson
[EMAIL
Jon S. Berndt wrote:
Try using a cosine if you are talking about spring compression. An
aircraft with a straight strut extending straight down from the wing,
with the aircraft at twenty degrees alpha would compress the strut
about 4.25 inches instead of 4 inches
(when using pure Z
Jon S. Berndt wrote (or, strictly, didn't write):
Andy Ross writes:
// If the line segment intersects
// the scenery more than once,
!?!?
/\
p1--+--+---p2
/\
/ground\
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer
David Megginson wrote:
Curtis L. Olson writes:
I'm just about to commit a massive series of changes that converts all
the .xml files to more standard .ini files. Oh, shoot, I meant to
save that announcement for 4/1/2002. :-)
We have to coordinate better -- I'm just finishing
On Fri, 15 Mar 2002 13:55:49 -0800
Andy Ross [EMAIL PROTECTED] wrote:
What part of assuming a flat ground is not getting across? :)
I was trying to figure out where you got that 34% error
from.
If you are willing to assume a flat ground, then you already *have* a
valid and workable model
I'm just about to commit a massive series of changes that converts all
the .xml files to more standard .ini files. Oh, shoot, I meant to
save that announcement for 4/1/2002. :-)
We have to coordinate better -- I'm just finishing switching them all
to TeX. FlightTeX will be
Jon S. Berndt wrote:
Andy Ross wrote:
What part of assuming a flat ground is not getting across? :)
I was trying to figure out where you got that 34% error from.
Sigh... grab a calculator. Type 2, then 0, then sin. :)
The answer to this question:
How far from the original position
Tony Peden wrote:
Andy Ross wrote:
You give the scenery the position of the gear min/max comprssion
points, and it tells you where the tip really is.
That is, IMO, precisely the job of the gear model. Only the gear
model can and should know the path that the wheel follows as it
David Megginson [EMAIL PROTECTED] said:
Curtis L. Olson writes:
I'm just about to commit a massive series of changes that converts all
the .xml files to more standard .ini files. Oh, shoot, I meant to
save that announcement for 4/1/2002. :-)
We have to coordinate better -- I'm
On Fri, 2002-03-15 at 14:51, Andy Ross wrote:
Tony Peden wrote:
Andy Ross wrote:
You give the scenery the position of the gear min/max comprssion
points, and it tells you where the tip really is.
That is, IMO, precisely the job of the gear model. Only the gear
model can and
Jim Wilson wrote:
Heh don't laugh. At LWCE Borland was giving away Kylix which is
basically delphi ported to linux...and if i'm not mistaken that uses
something like turbo pascal as its language. It's what they call a
RAD tool. Or is it a RAG (rapid atrocity generation) tool?
That's
Tony Peden wrote:
Andy Ross wrote:
Tony Peden wrote:
Only the gear model can and should know the path that the wheel
follows as it compresses.
I don't necessarily disagree,
But by asking the scenery code to do the intersection for you, that's
exaclty what you are doing,
On Friday, March 15, 2002, at 11:51 AM, Andy Ross wrote:
Roman Grigoriev wrote:
Hi guys I implemented rendering Flightgear in black and white mode
using Geforce rendering combiners here is a sample jpeg If some one
intrested in doing this I can describe technique It's extremly usefull
Gene Buckle writes:
If you're going to insist on cross-platform portability, then it should
obviously be Python.
Shhh...
a Python FGFS is probably closer to being unleashed then
most have any inkling of, so let's not scare it away :-)
Norman
___
Andy Ross writes:
I guess I'm just a little flummoxed at the resistance to doing things
right here. I mean, it doesn't take any more CPU time; it doesn't
make the FDM's job any more complicated, and it's reasonably
well-supported by the scenery code as-is. All that's needed is an
interface
On Fri, 15 Mar 2002 23:01:59 -
Jim Wilson [EMAIL PROTECTED] wrote:
Heh don't laugh. At LWCE Borland was giving away Kylix
which is basically
delphi ported to linux...and if i'm not mistaken that
uses something like
turbo pascal as its language. It's what they call a
RAD tool. Or is
On Fri, 15 Mar 2002 14:42:27 -0800
Andy Ross [EMAIL PROTECTED] wrote:
Sigh... grab a calculator. Type 2, then 0, then sin. :)
The answer to this question:
How far from the original position is the tip of a gear strut at 20
degrees of AoA (or bank, or whatever)?
...is 34% of its length.
On Fri, 15 Mar 2002 14:51:33 -0800
Andy Ross [EMAIL PROTECTED] wrote:
I'm not quite sure what you mean by the 3D model. Assuming vertical
gear compression is no closer to rendered reality than what we are
doing now. You'll get a tilt, but not a physically correct one.
It will be better than
On Fri, 15 Mar 2002 15:29:05 -0800
Andy Ross [EMAIL PROTECTED] wrote:
We either have to have scenery code that understands funny gear
trajectories or gear code that understands 3D collision
detection.
We can be fairly simple. If you want to do articulated
F-18 gear, be my guest. All I want
Jon S. Berndt wrote:
Given a *NON-FLAT* polygon, how do we place the aircraft on it
properly so the gear doesn't sink in on one side and sit above it on
the other? The answer is that you give each gear the blasted elevation
at that gear. How can I make it any plainer?
Jon, I'm running
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.
+
.\
.
On Fri, 15 Mar 2002 14:20:49 -0500
Michael Selig writes:
If we do add the myriad properties for many aircraft configuration
types to LaRCsim.cxx it means adding lots of code I think.
[3] The properties structure is pretty general. It seems like it
would be pretty easy to trample
On Fri, 2002-03-15 at 15:29, Andy Ross wrote:
Tony Peden wrote:
Andy Ross wrote:
Tony Peden wrote:
Only the gear model can and should know the path that the wheel
follows as it compresses.
I don't necessarily disagree,
But by asking the scenery code to do the
Jon S Berndt [EMAIL PROTECTED] said:
Don't laugh, yourself! ;-) I've used C++Builder since
v1.0 and it's an awesome tool. It is waaay RAD. I'm
excited that they ported Delphi to Linux, and the C++
version is due soon. In a former job we used it for
developing a *major* gas measurement
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
This gear collision stuff is going in horrific circles, and I've
clearly done a piss poor job of explaining it. Here is what I want,
from the top:
I want a gear interface where I specify the following two (2) points
in 3D space: One is the point of gear minimum compression, the other
Happy coding!
On Fri, 2002-03-15 at 17:59, Andy Ross wrote:
This gear collision stuff is going in horrific circles, and I've
clearly done a piss poor job of explaining it. Here is what I want,
from the top:
I want a gear interface where I specify the following two (2) points
in 3D
Andy Ross writes:
This gear collision stuff is going in horrific circles, and I've
clearly done a piss poor job of explaining it. Here is what I want,
from the top:
I want a gear interface where I specify the following two (2) points
in 3D space: One is the point of gear minimum
Forget anything else you might think I want. I don't want that. I
want the above interface. That is all I want. I no longer claim
(publically) that this interface is better. I no longer claim that
any other interfaces are wrong. I just want them, OK?
Thank you for playing nice. :-) I
Jon Berndt writes:
Thank you for playing nice. :-) I have no qualms at all about what you are
asking for. It's the people that are coding it that have to answer to that.
I think it's great if you can come up with a much better, versatile,
correct and robust model than we have, now. If you do,
You know, the code to do both what you want and what Andy wants is
already done and like Norman said, has been in place for about a year
now.
Holy! ...
Man, you guys are *fast*.
I guess I missed that somewhere along the way in months past. Or, it could
be that we got the gear to be good
Fortunately, that doesn't matter. We specify animations externally
using an XML config file; see
http://www.flightgear.org/Docs/fgfs-model-howto.html
for details. As long as ssgLoadMDL preserves object names inside the
model, we should be able to animate it.
Does anybody have a
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
Norman Vine writes:
tarball for new hitlist code
http://www.vso.cape.com/~nhv/files/fgfs/new_hitlist.tgz
For those of you not using the CVS version of PLib
you will need a copy of sgdPointInTriangle()
from the older hitlist.cxx this one replaces
Norman,
Thanks for your continued work on
- Original Message -
From: Jon S Berndt [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, March 15, 2002 6:40 PM
Subject: Re: [Flightgear-devel] black and white flightgear
On Fri, 15 Mar 2002 17:47:37 +0300
Roman Grigoriev [EMAIL PROTECTED] wrote:
Hi guys I implemented
97 matches
Mail list logo
