On Freitag, 30. April 2004 18:57, Andy Ross wrote:
> Erik Hofman wrote:
> > Why do you think that collision detection is not implemented? You
> > can crash to the ground and to the buildings (maybe even other
> > aircraft?), so there must be some logic behind this.
>
> Ground handling right now only uses a flat, horizontal ground plane at
> the MSL altitude of the aircraft coordinate origin. This works fine
> for runways, but isn't good enough for ground vehicles. This is the
> reason that you can't fly off the ski jump on the carrier without
> crashing, and why aircraft don't roll down hills.
>
> AFAIK all the FDMs share the same bug here. What's needed is to
> intersect each gear strut against the local scenery independently, and
> have a per-gear ground plane.
Sadly, yes.
So what a FDM definitly needs to know is the terrain level, sea level and
surface normal of an arbitrary given lat/lon pair (Most likely somewhere in
the environment of the location of the aircraft).
An additional value which signals the ground type we have here would be good
too, so you would need to hit the runway ...
I think we have three possible solutions from the FDM <-> Flightgear interface
point of view.
1. Have a callback function in FGInterface which is able to provide you a
terrain level and a surface normal for a given lat/lon pair.
2. On every update push *all* tiles in an environment of the aircraft to the
FDM and leave it to the FDM to fiddle with that information.
3. Provide a callback function to query a surface tile for a given lat/lon
pair.
I am not shure about the word 'surface tile' I do not know what this exactly
means in Flightgear, especially I do not know if knowledge of surface tiles
is sufficient to know if we roll on a runway or on grass ...
Pros and Cons IMO:
Method 1. is the easiest to use for a FDM programmer. But is definitly
unusable for a netfdm based approach Curt Olsen shortly told about on
jsbsim-devel (FDM <=> FlightGear interface).
Method 2. most likely either provides a too small environment to match the
fdm's needs or continously pushes too much data which is never used.
This one and the next one would require some additional code in the FDM to
directly gain the data the FDM is interessted in (terrain
level/sealevel/surface normal/surface type).
Method 3. The most intelligent one I think, Just queries a new tile if it is
really required for computations.
Method 1 and 3 can also be combined in the sense that the FDM just sees a
solution like method 1, but the actual queries are done based on a FDM local
tile cache. Using this I can imagine that it is still possible to do some
netfdm based solution Curt Olsen told about shortly ...
Suggestions?
Someone with internal knowledge about Flightgear to help building such a
beast?
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
