fly/flightgear
1
0
Fork 0
Code Activity

Updates ...

Browse source
This commit is contained in:
curt 1999-06-15 19:54:44 +00:00
parent f8d8440953
commit 28436a23be
5 changed files with 585 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

89
Hints/polygon-offset
View file

@ -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

66
Hints/screen-dump Normal file
View file

@ -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

178
Hints/shadows-lights Normal file
View file

@ -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".

244
Hints/ssg Normal file
View file

@ -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".

8
Hints/textures-free Normal file
View file

@ -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.