diff --git a/Hints/polygon-offset b/Hints/polygon-offset index fd5d71b40..6bd65c4fc 100644 --- a/Hints/polygon-offset +++ b/Hints/polygon-offset @@ -267,3 +267,92 @@ the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L (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 + diff --git a/Hints/screen-dump b/Hints/screen-dump new file mode 100644 index 000000000..b77b24f4e --- /dev/null +++ b/Hints/screen-dump @@ -0,0 +1,66 @@ +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 + diff --git a/Hints/shadows-lights b/Hints/shadows-lights new file mode 100644 index 000000000..f27db254b --- /dev/null +++ b/Hints/shadows-lights @@ -0,0 +1,178 @@ +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". + diff --git a/Hints/ssg b/Hints/ssg new file mode 100644 index 000000000..6409424b3 --- /dev/null +++ b/Hints/ssg @@ -0,0 +1,244 @@ +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". + diff --git a/Hints/textures-free b/Hints/textures-free new file mode 100644 index 000000000..d311fb1f4 --- /dev/null +++ b/Hints/textures-free @@ -0,0 +1,8 @@ +"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.