244 lines
10 KiB
Text
244 lines
10 KiB
Text
From owner-fgfs-devel@flightgear.org Thu May 20 08:36:54 1999
|
|
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
|
["8912" "Thu" "20" "May" "1999" "08:35:37" "-0500" "Stephen J Baker" "sjbaker@hti.com" nil "210" "Re: [FGFS-Devel] Things to do list" "^From:" nil nil "5" nil nil nil nil nil]
|
|
nil)
|
|
Received: from mailhub.woodsoup.org (IDENT:root@anduin.physics.iastate.edu [129.186.82.1])
|
|
by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id IAA09534
|
|
for <curt@me.umn.edu>; Thu, 20 May 1999 08:36:53 -0500 (CDT)
|
|
Received: from majordom by mailhub.woodsoup.org with local (Exim 1.92 #1)
|
|
for fgfs-devel-outgoing@flightgear.org
|
|
id 10kSzs-0005Sv-00; Thu, 20 May 1999 08:36:28 -0500
|
|
Received: from sunmgr.hti.com ([130.210.206.69] helo=issun6.hti.com)
|
|
by mailhub.woodsoup.org with esmtp (Exim 1.92 #1)
|
|
for fgfs-devel@flightgear.org
|
|
id 10kSzq-0005SX-00; Thu, 20 May 1999 08:36:26 -0500
|
|
Received: from issun5.hti.com ([130.210.202.3]) by issun6.hti.com
|
|
(Netscape Messaging Server 3.6) with ESMTP id AAA3BC4
|
|
for <fgfs-devel@flightgear.org>; Thu, 20 May 1999 08:35:55 -0500
|
|
Received: from samantha.bgm.link.com ([130.210.66.11]) by issun5.hti.com
|
|
(Netscape Messaging Server 3.6) with SMTP id AAA3FBA
|
|
for <fgfs-devel@flightgear.org>; Thu, 20 May 1999 08:35:54 -0500
|
|
X-Sender: steve@samantha.bgm.link.com
|
|
In-Reply-To: <14147.454.803438.762388@pinky.infoplane.com>
|
|
Message-ID: <Pine.SGI.3.96.990520073715.2204E-100000@samantha.bgm.link.com>
|
|
MIME-Version: 1.0
|
|
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
|
Precedence: bulk
|
|
Reply-To: fgfs-devel@flightgear.org
|
|
From: "Stephen J Baker" <sjbaker@hti.com>
|
|
Sender: owner-fgfs-devel@flightgear.org
|
|
To: fgfs-devel@flightgear.org
|
|
Subject: Re: [FGFS-Devel] Things to do list
|
|
Date: Thu, 20 May 1999 08:35:37 -0500 (CDT)
|
|
|
|
On Wed, 19 May 1999, Curtis L. Olson wrote:
|
|
|
|
> Flight Gear world coordinate system:
|
|
>
|
|
> (0, 0, 0) is at the center of the earth. Z is up through the north
|
|
> pole, X is out through point where the zero meridian intersects the
|
|
> equator (somewhere in africa). Y is out where the 90th meridian
|
|
> intersects the equator (somewhere in the indian ocean.) Here's a
|
|
> picture:
|
|
>
|
|
> http://www.flightgear.org/Docs/Scenery/CoordinateSystem/img8.gif
|
|
>
|
|
> However, using this coordinate system directly to render the scenery
|
|
> in OpenGL leads to all sorts of precision problems. So, for actual
|
|
> rendering in OpenGL, I use a coordinate system that is aligned exactly
|
|
> the same, but is translated so that (0, 0, 0) is at the center of the
|
|
> current tile's bounding sphere. This means that all the coordinates
|
|
> I'm feeding to opengl are "near" (0, 0, 0) within a couple thousand
|
|
> meters.
|
|
|
|
But each tile must have a translation matrix pushed on the OpenGL
|
|
stack before it is rendered - right? Does that translation
|
|
operate:
|
|
|
|
* Relative to ownship.
|
|
* Relative to some arbitary origin (like the center of the 'current'
|
|
tile) that moves periodically (eg when you cross a tile boundary).
|
|
* Some other way.
|
|
|
|
> My "embarrassing problem" is that I don't understand enough about ssg
|
|
> to know if it could be made to mesh well with the current flight gear
|
|
> coordinate system.
|
|
|
|
Well, I think the problem of point features on the terrain is a different
|
|
one from moving models like aircraft.
|
|
|
|
For aircraft, we can have an SSG scene graph, with each aircraft
|
|
model positioned under a ssgTransform node and an ssgSelector node.
|
|
Something like this:
|
|
|
|
o ssgRoot for all of our
|
|
| moving models
|
|
_________|_________
|
|
| | | | |
|
|
o o o o o ssgSelector nodes
|
|
| | | | |
|
|
o o o o o ssgTransform nodes
|
|
| | | | |
|
|
cessna pitts C130 F16 747 Aircraft models loaded
|
|
from disk.
|
|
|
|
(It would be more complex if - for example - we wanted three
|
|
747's in the scenario - but wanted to use the same polygonal
|
|
model for all three of them...still, it's not too bad)
|
|
|
|
The ssgSelector nodes allow the planes to be turned on and off
|
|
as needed in the scenario we are playing. The ssgTransform nodes
|
|
let us position them relative to some arbitary origin.
|
|
|
|
Each frame, we pick up the location of each model (Lat/Lon/Alt/
|
|
Heading/Pitch/Roll) from some FGFS data structure somewhere.
|
|
We do a very quick and dirty check to see if it is within (say)
|
|
20 miles of the eyepoint (you can do that just be comparing lat/long
|
|
with ownship lat/long using an approximate table to convert degrees
|
|
longitude into meters depending on your latitude).
|
|
|
|
If the aircraft is too far away, use it's ssgSelector node to turn
|
|
it off - this saves the expense of a costly LLA->XYZ conversion and
|
|
makes culling cheaper for SSG when there are a lot of aircraft in
|
|
the managed scene.
|
|
|
|
We need to pick a 'current local origin'. This could be the center
|
|
of the nearest terrain tile, it could be a point vertically below
|
|
the ownship at sea level...somewhere close by.
|
|
|
|
If the aircraft is reasonably close, compute the location of the aircraft
|
|
relative to the current local origin. This entails some double-precision
|
|
math but it's not all that hard - and it boils down to a 'float' 4x4 matrix.
|
|
I imagine the math for this is already there to compute the eyepoint
|
|
transform for the ownship.
|
|
|
|
Put that matrix into the ssgTransform node and turn on the ssgSelector
|
|
for that plane.
|
|
|
|
At some point (probably after the terrain is rendered) you tell SSG
|
|
where the ownship is relative to the current local origin and cull
|
|
and draw the SSG scene.
|
|
|
|
All done.
|
|
|
|
At present, the aircraft models have to be in AC3D format - because
|
|
that's the only file loader. However, there is work in progress
|
|
(check the PLIB mailing list for details) to produce a VRML-2 loader,
|
|
which should make it possible for anyone to build or convert aircraft
|
|
models using a variety of modelling tools.
|
|
|
|
For now, I think there is at least one AC3D format plane model on
|
|
the AC3D demo distribution that will allow us to get all the
|
|
FGFS code up and running.
|
|
|
|
> Thinking about ground objects for instance (buildings, radio towers,
|
|
> etc.) Basically we'd need to be able to rotate these ssh objects so
|
|
> that they are aligned with the up vector for where ever they are being
|
|
> placed. This rotation matrix can be generated directly from the
|
|
> object's latitude and longitude.
|
|
|
|
There could be a separate SSG scene graph for each terrain tile.
|
|
Placing an ssgTransform at the top of that scene graph would allow
|
|
you to apply the same transform to all the features on the terrain
|
|
tile as to the terrain itself. The objects beneath that transform
|
|
could then be positioned on the tile using the same kinds of mechanisms
|
|
that you use to create the terrain skin.
|
|
|
|
I presume that you have some code to turn a lat/lon/alt/heading/pitch/roll
|
|
into a matrix (I guess the ownship positioning code must need that).
|
|
Using that routine to generate the location of objects on the skin
|
|
(in your offline tools) would allow you to generate a terrain feature
|
|
set from a pre-built library.
|
|
|
|
So, you'd get this:
|
|
|
|
In your source data:
|
|
|
|
There is a power plant at lat=L1, lon=L2, heading=H
|
|
|
|
In your tools you'll need to figure out the height of the terrain skin
|
|
at (L1,L2) and use that resulting Lat/Lon/Alt/Heading/0/0 to compute
|
|
(in double-precision) the transform needed to position that object
|
|
relative to the center of the earth. Subtract the origin of the terrain
|
|
tile from the translation part of that - and you have something that
|
|
you can reduce to 'float' precision.
|
|
|
|
Also offline, decide which of a standard set of pre-built "library"
|
|
models best represents a power plant.
|
|
|
|
In your output terrain tile file:
|
|
|
|
There is an instance of object number 1234 at the location
|
|
described by [4x4 matrix] relative to the terrain tile's
|
|
local origin.
|
|
|
|
There are four ways (I guess) we could do the next part:
|
|
|
|
1) We could use SSG to cull the entire scene (including
|
|
terrain skin) - discarding your existing culling routines
|
|
and creating new SSG nodes for your terrain skin.
|
|
|
|
2) We could build an SSG scene graph structure that has
|
|
an ssgTransform for each terrain tile - but have that
|
|
contain only the point features for that tile. You'd
|
|
render your terrain with the existing code and then
|
|
call SSG to cull and draw the point features.
|
|
|
|
3) We could build a separate SSG scene graph for each
|
|
terrain tile and call the cull and draw routine for
|
|
each tile only if the existing terrain tile passes
|
|
the terrain cull test.
|
|
|
|
4) Don't use SSG, just extend the existing terrain renderer
|
|
to do the point features.
|
|
|
|
It seems to me that (2) is not very efficient since the
|
|
culling process is happening twice for each terrain tile,
|
|
once in the terrain renderer and again inside SSG.
|
|
|
|
I'm not sure that SSG is mature enough to do (1) yet since
|
|
it doesn't sort by material property yet. However, that is
|
|
work that will ultimately need to be done anyway - so maybe
|
|
we just live with the inefficiency for now. If SSG had
|
|
existed before the existing terrain renderer had been
|
|
written, we should certainly have gone this way.
|
|
|
|
(3) is possible. It seems a little messy to have two sets
|
|
of culling routines layered on top of each other - and I
|
|
can concieve of a problem when a point feature object is
|
|
on the very edge of a terrain tile...hanging just off
|
|
the edge in fact...the terrain culling routines might
|
|
discard the terrain tile - and hence the SSG scene
|
|
graph would never be evaluated and the point feature
|
|
would not be drawn - even though it might be partially
|
|
on-screen. That would be a bad problem for hand-built
|
|
airfields for example.
|
|
|
|
(4) might well turn out to be easiest - but Curt would
|
|
have to write loaders for VRML and other file formats
|
|
and considerably change the existing terrain rendering
|
|
code. That would be pretty wasteful and writing good
|
|
VRML loaders would duplicate the work already being
|
|
done for SSG.
|
|
|
|
Evidently this requires more thought and discussion
|
|
between Curt and myself.
|
|
|
|
> Can ssg do these sorts of things?
|
|
|
|
In principle. SSG can be changed if needed. It's my
|
|
project and I'll do whatever it takes to make it useful.
|
|
Whether I can do that to a schedule that suits FGFS
|
|
is not certain.
|
|
|
|
Steve Baker (817)619-2657 (Vox/Vox-Mail)
|
|
Raytheon Systems Inc. (817)619-2466 (Fax)
|
|
Work: sjbaker@hti.com http://www.hti.com
|
|
Home: sjbaker1@airmail.net http://web2.airmail.net/sjbaker1
|
|
|
|
|
|
--
|
|
Please visit the FGFS web page: http://www.flightgear.org
|
|
For help on using this list (especially unsubscribing), send a message to
|
|
"fgfs-devel-request@flightgear.org" with a single line of text: "help".
|
|
|