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" "" "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 ; 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 ; 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 ; 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Reply-To: fgfs-devel@flightgear.org From: "Stephen J Baker" 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".