(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
+From sjbaker@hti.com Mon Jun 14 08:52:00 1999
+X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
+ ["2439" "Mon" "14" "June" "1999" "08:51:06" "-0500" "Stephen J Baker" "sjbaker@hti.com" "<Pine.SGI.3.96.990614083347.20686H-100000@samantha.bgm.link.com>" "65" "Re: glPolygonOffset()" "^From:" nil nil "6" nil nil nil nil nil]
+ nil)
+Received: from issun6.hti.com (sunmgr.hti.com [130.210.206.69])
+ by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id IAA24327
+ for <curt@me.umn.edu>; Mon, 14 Jun 1999 08:51:59 -0500 (CDT)
+Received: from issun5.hti.com ([130.210.202.3]) by issun6.hti.com
+ (Netscape Messaging Server 3.6) with ESMTP id AAA3DCD
+ for <curt@me.umn.edu>; Mon, 14 Jun 1999 08:51:27 -0500
+Received: from samantha.bgm.link.com ([130.210.66.11]) by issun5.hti.com
+ (Netscape Messaging Server 3.6) with SMTP id AAA4A5D
+ for <curt@me.umn.edu>; Mon, 14 Jun 1999 08:51:26 -0500
+X-Sender: steve@samantha.bgm.link.com
+Reply-To: Steve Baker <sjbaker@hti.com>
+In-Reply-To: <14177.35403.456685.793490@kenai.me.umn.edu>
+Message-ID: <Pine.SGI.3.96.990614083347.20686H-100000@samantha.bgm.link.com>
+MIME-Version: 1.0
+Content-Type: TEXT/PLAIN; charset=US-ASCII
+From: "Stephen J Baker" <sjbaker@hti.com>
+To: "Curtis L. Olson" <curt@me.umn.edu>
+Subject: Re: glPolygonOffset()
+Date: Mon, 14 Jun 1999 08:51:06 -0500 (CDT)
+
+On Fri, 11 Jun 1999, Curtis L. Olson wrote:
+
+> What's the current recommendation for doing glPolygonOffset() type
+> stuff.
+
+It doesn't work on 3Dfx hardware at all.
+
+I have been trying to get David B. to implement it in the FXMesa
+driver - but I'm not sure if he plans to do it in Mesa 3.1 or not.
+
+> I think I'm going to need to do something with this in the forseeable
+> future. Either with roads and streams, or with runway markings, or
+> night lighting ...
+
+Yep.
+
+I have been using the kludge of moving the near/far clip planes
+just a tad. This has a similar effect to glPolygonOffset and it
+works on 3Dfx hardware.
+
+Under Mesa 3.0, doing this trick is pretty fast too.
+
+Unfortunately, I kindof screwed myself on this one though.
+
+I found a Mesa bug in the fog code - and part of the fix
+increased the cost of doing fog density changes (so what!).
+Then both David B and I noticed that there was a bug that
+prevented the fog density from being recomputed when the
+near/far clip range was changed....and the fix for *that*
+makes my near/far kludge run pretty slowly.
+
+So, I'm working on the basis that I'll use the near/far
+hack on Mesa 3.0 and switch to glPolygonOffset for 3.1.
+
+Of course glPolygonOffset might well work for Mesa 3.0
+on non-3Dfx machines - and it certainly should work under
+Windoze with the OpenGL's supplied by the hardware vendors.
+
+Regrettably, the value of the two parameters to glPolygonOffset
+are likely to vary from card to card. Also, the older SGI
+machines (running OpenGL 1.0) don't have glPolygonOffset, and
+their glPolygonOffsetEXT has a different definition for the
+two glPolygonOffset parameters.
+
+Ugh!
+
+> I want to handle some tile paging issues. I want to try drawing
+> all the terrain in immediate mode rather than doing display lists.
+
+That's probably not such a bad idea. Compiled Vertex arrays (in
+immediate mode) are the trendy solution (ie that's what Quake III does),
+you might want to investigate that.
+
+> Anyways, assuming I get that stuff handled, the next major thing I
+> hope to do would be along the lines of airports, or roads, or ground
+> lights ...
+
+Yep. Light aircraft pilots often navigate by roads/rivers/railroads
+and having those in the scene will certainly help.
+
+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
+
--- /dev/null
+From kaszeta@me.umn.edu Tue Apr 27 12:25:04 1999
+X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
+ ["1377" "Tue" "27" "April" "1999" "12:25:03" "-0500" "Richard Kaszeta" "kaszeta@me.umn.edu" nil "46" "Screen Dump under OpenGL" "^From:" nil nil "4" nil nil nil nil nil]
+ nil)
+Received: from bofh.me.umn.edu (kaszeta@bofh.me.umn.edu [134.84.18.23])
+ by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id MAA17257
+ for <curt@me.umn.edu>; Tue, 27 Apr 1999 12:25:04 -0500 (CDT)
+Received: (from kaszeta@localhost)
+ by bofh.me.umn.edu (8.9.1/8.9.1) id MAA32360;
+ Tue, 27 Apr 1999 12:25:04 -0500
+MIME-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+Content-Transfer-Encoding: 7bit
+Message-ID: <14117.62191.861894.721574@bofh.me.umn.edu>
+X-Mailer: VM 6.47 under Emacs 19.34.1
+From: Richard Kaszeta <kaszeta@me.umn.edu>
+To: curt@me.umn.edu
+Subject: Screen Dump under OpenGL
+Date: Tue, 27 Apr 1999 12:25:03 -0500 (CDT)
+
+Dumps the framebuffer to a .ppm file:
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <limits.h>
+#include <GL/glut.h>
+
+#define RGB 3 /* 3 bytes of color info per pixel */
+#define RGBA 4 /* 4 bytes of color+alpha info */
+
+void my_glDumpWindow(const char * filename, int win_width, int win_height) {
+ int i, j, k, q;
+ GLubyte *buffer;
+ unsigned char *ibuffer;
+ FILE *fp;
+
+ buffer = (GLubyte *) malloc(win_width*win_height*RGBA);
+ ibuffer = (unsigned char *) malloc(win_width*win_height*RGB);
+
+ /* read window contents from color buffer with glReadPixels */
+ glFinish();
+ glReadPixels(0, 0, win_width, win_height, GL_RGBA, GL_UNSIGNED_BYTE, buffer);
+
+ fp = fopen(filename, "w");
+ fprintf(fp, "P6\n# CREATOR: glReadPixel()\n%d %d\n%d\n",
+ win_width, win_height, UCHAR_MAX);
+ q = 0;
+ for (i = 0; i < win_height; i++)
+ for (j = 0; j < win_width; j++)
+ for (k = 0; k < RGB; k++)
+ ibuffer[q++] = (unsigned char)
+ *(buffer + (RGBA*((win_height-1-i)*win_width+j)+k));
+ fwrite(ibuffer, sizeof(unsigned char), RGB*win_width*win_height, fp);
+ fclose(fp);
+ free(buffer);
+ free(ibuffer);
+
+ printf("wrote file (%d x %d pixels, %d bytes)\n",
+ win_width, win_height, RGB*win_width*win_height);
+}
+
+--
+Richard W Kaszeta PhD. Candidate and Sysadmin
+bofh@me.umn.edu University of MN, ME Dept
+http://www.menet.umn.edu/~kaszeta
+
--- /dev/null
+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".
+
--- /dev/null
+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".
+
--- /dev/null
+"Christian Mayer" <Vader@t-online.de>
+ http://home.t-online.de/home/vader/internet.zip
+ http://home.t-online.de/home/vader/myones.zip
+ http://home.t-online.de/home/vader/nz_tex.zip
+
+Note: some of these textures may have specific copyrights and restrictions
+on their use. Please view and follow the documentation/readme that comes
+with these.
projects / flightgear.git / commitdiff