On 12/3/07, Curtis Olson <[EMAIL PROTECTED]> wrote:
> On Dec 3, 2007 6:23 AM, STenyaK (Bruno Gonzalez) <> wrote:
>
> > I'm not sure what "FDM" means, couldnt' find a good explanation.
>
> FDM is the acronym we use for "flight dynamics model". Conceptually, a
> "physics engine" engine covers much of the same ground. If I were to get
> really nitpicky, perhaps I could say that the flight dynamics model contains
> a physics engine + additional speciallized code to model the dynamics of
> flight.
Ok, it's what i thought. Personally, i call "physics engine" to
everything that models real world physics, no matter if they have to
deal with air, water, terrain, outter space or whatever. But I'm not
interested in the naming each community gives to it, just in its
meaning :-)
> So far in the flightgear project we have not addressed aircraft/vehicles
> affecting each other. Our philosophy is that we are modeling a friendly
> airspace so collisions with other aircraft should never ... at least for
> those that take their simming seriously and start somewhere other than the
> default location. It would be interesting to model turbulence affects from
> one aircraft/vehicle onto another, but to do this in a generic and
> physically correct way, might be far beyond the scope of what we can
> accomplish with finite compute power. Maybe we could build in some
> interesting heuristics/hacks though that could be fun. In the world of
> aviation we have wake turbulence, formation flying (and air to air
> refueling, aero towing, etc.)
In the world of racesims, car-to-car collisions are pretty important
and common, as is car-to-track collision (both driving surface, walls,
tire piles, sand, cones, etc).
I'm not a physics expert, in fact i'm crap at maths and physics
(compared to many people), so it's not my intention to even try to
merge 2 physics engines together, when i can barely create one of them
myself :-) By merging, i mean the mentioned idea of allowing a car to
tow a plane, each of which would have its own "FDM".
My intention is to provide a good framework where knowledgeable people
can contribute code to. That has been the case of several university
students, one of which added drivetrain physics to the old version of
Motorsport. Another one coded genetic-evolutive AI that drived around
tracks. Also i've been approached by people working for the DARPA
Challenge, in order to use Motorsport for the last urban challenge
project.
I'm good at computers and programming, so that's what i try to
contribute with. For example, P2P distribution of contents, streaming
of gEarth or WorldWind or FlightGear terrain data... Well, the kind of
things that i know how to code.
> The FlightGear "FDM" interface was originally designed so it is relatively
> straight forward to drop in another "physics engine." (sorry to mix terms
> there.) :-)
Good, since the Motorsport remake is also planned to be easy to drop
into other games/programs/simulators.
> I've always thought it would be fun to wind through an interesting mountain
> region for a hundred miles or so of realistic roadway with real terrain,
> etc. The driving sims I've seen have either stuck with specific race tracks
> or very small areas with lots of detail, or larger areas with very sparse
> detail. Algorithmically it would be possible to create large areas with
> pretty nice detail. I've been dabbling in some of that recently, but it's
> really hard stuff. Intersections are hard to deal with, the complexity and
> polygon count of detailed roadways are hard to handle, and creating
> realistic surfaces from noisy SRTM data is also a difficult thing to do.
> But there are some tantalizing ideas that wouldn't be all that hard. If you
> added some attributes to your road data base, you could start dropping in
> things like mile markers, street lights, other regularly spaced signs, mail
> boxes, guard rails, jerzey barrier. My problem is that I have way more good
> ideas than I have time. Well at least I think they are good ideas. :-)
The problem is that heaps of detail are needed in order to make it
enjoyable or realistic. The air is reasonably constant, so if i'm not
mistaken, there's not much need to model differences in pressures or
temperatures or things like that. Plus you have 6 degrees of freedom
to play with.
In the case of cars, you're limited to following a road (with the
occasional jumps, which are interesting if taking gyroscopic effects
into account), and so the driving surface needs good detail or it'll
be boring to drive. Potholes, camber, different leves of adherence in
different places, materials, weather conditions, temperatures, etc.
I've also thought about automatic generation of roads (i implemented a
4D-Stunts track loader in the old Motorsport as a first approach), but
there's still a long way to go before any result is good enough. I'll
only concentrate on allowing data streaming for now, procedural roads
will still wait for some years (unless someone steps in and codes it
sooner, of course).
--
Saludos,
Bruno González
_______________________________________________
Msn/Jabber: stenyak AT gmail.com
ICQ: 153709484
http://www.stenyak.com
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
