178 lines
7 KiB
Text
178 lines
7 KiB
Text
From owner-fgfs-devel@flightgear.org Tue Jun 15 12:24:35 1999
|
|
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
|
|
["5330" "Tue" "15" "June" "1999" "12:24:25" "-0500" "Stephen J Baker" "sjbaker@hti.com" "<Pine.SGI.3.96.990615115046.5472A-100000@lechter.bgm.link.com>" "145" "RE: [FGFS-Devel] Towards a Binary Scenery Format" "^From:" nil nil "6" 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 MAA00346
|
|
for <curt@me.umn.edu>; Tue, 15 Jun 1999 12:24:34 -0500 (CDT)
|
|
Received: from majordom by mailhub.woodsoup.org with local (Exim 1.92 #1)
|
|
for fgfs-devel-outgoing@flightgear.org
|
|
id 10twwQ-0005Iu-00; Tue, 15 Jun 1999 12:24:06 -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 10twwP-0005Ia-00; Tue, 15 Jun 1999 12:24:05 -0500
|
|
Received: from issun5.hti.com ([130.210.202.3]) by issun6.hti.com
|
|
(Netscape Messaging Server 3.6) with ESMTP id AAA5868
|
|
for <fgfs-devel@flightgear.org>; Tue, 15 Jun 1999 12:23:32 -0500
|
|
Received: from lechter.bgm.link.com ([130.210.63.22]) by issun5.hti.com
|
|
(Netscape Messaging Server 3.6) with SMTP id AAA40B9
|
|
for <fgfs-devel@flightgear.org>; Tue, 15 Jun 1999 12:23:31 -0500
|
|
X-Sender: steve@lechter.bgm.link.com
|
|
In-Reply-To: <14182.32328.710469.293159@kenai.me.umn.edu>
|
|
Message-ID: <Pine.SGI.3.96.990615115046.5472A-100000@lechter.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] Towards a Binary Scenery Format
|
|
Date: Tue, 15 Jun 1999 12:24:25 -0500 (CDT)
|
|
|
|
On Tue, 15 Jun 1999, Curtis L. Olson wrote:
|
|
|
|
> With what you know about our current terrain scheme, do we have any
|
|
> chance of doing things like having object cast shadows on the ground
|
|
> ... especially our own plane? How about landing lights illuminating
|
|
> the ground?
|
|
|
|
Well, ownship shadow is do-able so long as people don't get too picky.
|
|
General shadows are impossible. Shadows for a few specialised things
|
|
might be doable if they are really important to you. (We need them
|
|
for things like Night-Vision-Goggles (NVG's) where shadows cast by
|
|
the moon are CRITICAL to military operations).
|
|
|
|
For ownship shadows,
|
|
|
|
You can figure out the intersection of the ray from the sun through
|
|
the center of the plane onto the ground polygons - that's not too
|
|
hard.
|
|
|
|
Then take a texture mapped quad containing a plan-view shadow and
|
|
rotate it to the same heading as ownship but with the roll/pitch
|
|
driven by the terrain.
|
|
|
|
That looks OK for 99% of the time and is probably 'good enough'.
|
|
|
|
I do this in my Tux game - with a circular shadow texture,
|
|
there are LOTS of cases where it fails, nobody noticed yet!
|
|
|
|
Caveats:
|
|
|
|
* It doesn't take account of ownship roll/pitch - although
|
|
for small angles, you can perhaps kludge it by squashing the
|
|
shadow polygon in width/length.
|
|
|
|
* It won't shadow things like buildings or other aircraft.
|
|
(because the shadow is projected onto the terrain beneath
|
|
them).
|
|
|
|
* It won't split across terrain polygons - so it tends to
|
|
momentarily vanish in concavities and momentarily float
|
|
above convexities.
|
|
|
|
* You need a different shadow texture for each aircraft type.
|
|
|
|
* It's not easy to produce umbra/penumbra effects as a
|
|
function of ownship altitude...but you could maybe
|
|
kludge something with glAlphaFunc.
|
|
|
|
Helicopter and VTOL pilots use the ownship shadow as an
|
|
important height cue - so you need to get it right for
|
|
them. However, they tend not to land with 60 degree
|
|
bank angles! I believe that Navy pilots learn to use
|
|
the shadow as a height cue when ditching in the ocean.
|
|
|
|
|
|
Landing lights are a pain. In OpenGL, you can define a light
|
|
source for each landing light (not many planes need more than
|
|
the half dozen or so that OpenGL guarantees to support).
|
|
|
|
The problem is that lighting is only computed at polygon
|
|
vertices. When you are on approach, there are likely to
|
|
be polygons that are MUCH larger than the puddle of light
|
|
that the landing light projects.
|
|
|
|
You can decimate polygons either dynamically (hard) or
|
|
statically (easier).
|
|
|
|
Statically, just make runway/taxiway/apron polygons that
|
|
are modelled so as to be switched into 'high detail' at
|
|
close range using an LOD node (ssgRangeSelector in SSG).
|
|
That's not really great because you can't land on a road
|
|
or in a field that the database prep tools didn't think
|
|
you'd want to land in because your lights won't work well.
|
|
You'll also get bad things happening when you fly low
|
|
over general terrain with your landing lights on.
|
|
|
|
Dynamically is REALLY hard to code with any generality.
|
|
|
|
Instead of using OpenGL lights, you could use multi-pass
|
|
rendering or make use of Multi-texture (if your hardware
|
|
supports it). In this way, you can render a daylight
|
|
scene and on a second pass render a black anti-light
|
|
texture over the entire scene.
|
|
|
|
In the past, that was REALLY COSTLY because it halved
|
|
your frame rate. However, the latest generation of
|
|
PC cards can do multi-texture which should greatly
|
|
speed that up. On a Voodoo-3, the second pass is
|
|
essentialy free.
|
|
|
|
Multipass is great for single landing lights - but
|
|
if you have a wingman who is landing in formation,
|
|
or if you are flying a 747 with half a dozen
|
|
landing lights - then you need one OpenGL rendering
|
|
pass PER LIGHT - plus the original...now you are
|
|
screwed and will lose framerate.
|
|
|
|
A *REALLY* cheesy solution that I used once in a
|
|
railroad simulator was to render the scene with
|
|
dense black fog applied to all of the terrain and
|
|
buildings - but not to lights and the sky. The
|
|
result was an omni-directional light source that
|
|
didn't cast nice pools of light - but which was
|
|
utterly free.
|
|
|
|
Using a second texture pass, it's hard to get the
|
|
light to attenuate nicely with range - so you tend
|
|
to light up mountains that are 40 miles away with
|
|
your super-bright landing lights! The kludge to
|
|
fix that is to add the cheesy black fog trick to
|
|
the light-texture pass.
|
|
|
|
I think that of all of these, statically diced
|
|
polygons works best. However, it rather relies
|
|
on the fact that:
|
|
|
|
* Light aircraft don't often fly low over
|
|
open country at night.
|
|
|
|
* Big aircraft don't fly low over open
|
|
country at all.
|
|
|
|
* Airforce planes don't fly with landing
|
|
lights on at all unless they are on
|
|
final approach. This would be stoopid
|
|
in combat - and they are taught to fly
|
|
that way at all times.
|
|
|
|
* Navy pilots are even taught to land without
|
|
landing lights.
|
|
|
|
If FGFS pilots want to land on freeways at night,
|
|
then their landing lights would look *terrible*.
|
|
|
|
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".
|
|
|