fly/flightgear
1
0
Fork 0
Code Activity
flightgear/Hints/texturing
curt 29f6d05875 Initial revision
1999-04-05 21:32:32 +00:00

1073 lines
44 KiB
Text
Raw Blame History

From sbaker@link.com Mon Jan 12 09:03:37 1998
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
["11420" "Mon" "12" "January" "1998" "11:03:54" "-0600" "Steve Baker" "sbaker@link.com" "<Pine.SGI.3.96.980112101657.22119D-100000@lechter.bgm.link.com>" "318" "[FGFS] Da-da-da (fwd)" "^From:" nil nil "1" nil nil nil nil nil]
nil)
X-VM-Message-Order:
(1 2 3 5 4 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61 62 63)
X-VM-Summary-Format: "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n"
X-VM-Labels: ("r")
X-VM-VHeader: ("Resent-" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:") nil
X-VM-Bookmark: 4
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
by meserv.me.umn.edu (8.8.8/8.8.6) with ESMTP id JAA01094
for <curt@me.umn.edu>; Mon, 12 Jan 1998 09:03:28 -0600 (CST)
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
id JAA14248 for <curt@me.umn.edu>; Mon, 12 Jan 1998 09:02:52 -0600 (CST)
X-Sender: steve@lechter.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
Message-ID: <Pine.SGI.3.96.980112101657.22119D-100000@lechter.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
From: Steve Baker <sbaker@link.com>
To: curt@me.umn.edu
Subject: [FGFS] Da-da-da (fwd)
Date: Mon, 12 Jan 1998 11:03:54 -0600 (CST)
> I went with the wife to see "Titanic" tonight. It was all sold out,
It was a 'girl' movie - my Wife loved it - my kid and I zzzzz'd out.
> and the only other movie that hadn't started yet was "007" which Ruth
> didn't want see. :-(
Now *that* was a 'boy' movie. Easily the best Bond movie so far (although
the chase scene with the Tank in Goldeneye is still up there).
> So I just generated a section of scenery in "ultra-high" detail and am
> getting about 0.2 frames a second.
Pretty neat ... but what it needs is:
####### ####### # # ####### # # ###### #######
# # # # # # # # # #
# # # # # # # # # #
# ##### # # # # ###### #####
# # # # # # # # # #
# # # # # # # # # #
# ####### # # # ##### # # #######
(which is v.easy to add - and comes for free on a 3Dfx - although it'll
*KILL* your frame rate on software-only Mesa).
Could you do a screen dump of a wire-frame rendering of that so people can
see the tesselation? Just set xglPolygonMode(GL_FRONT_AND_BACK,GL_LINE).
> Anyone know anything about view frustum culling?
Yep.
Two issues:
1) Scene hierarchy generation (offline).
2) Runtime culling.
Hierarchy:
==========
There are lots of ways to do this. I usually build an heirerchical description
of each terrain tile. I typically build a tree structure that's organized
as follows:
| The World.
|
___________________|___
| | | | | | |
* * * * * * * Terrain tiles currently loaded
| | | | | | |
|
|
_____|_____
| | | |
* * * * Quarter-tiles
| | | |
|
|
_____|_____
| | | |
* * * * Sixteenth-tiles
| | | |
...and so on down until the number of polygons in each 'object' gets 'small enough'.
When you do this, don't try to split polygons when they cross a quarter or a
sixteenth tile boundary - just dump each polygon into the nearest 'bucket' to
it's centroid.
Do your tri-stripping on the leaf nodes of this tree - so that each tristrip
is contained entirely within one bucket.
Eventually, you will need to include buildings, roads, rivers, etc. Since these
need to be culled by level of detail, it is often useful to put them into a separate
tree structure that parallels the terrain 'skin' structure.
Finally, compute a bounding sphere around each leaf node, find the best fit
sphere by finding the maximum and minimim x, y and z of the tristrips in that
leaf node, taking the mid-point and then finding the vertex that is furthest
from that center point and using it as the radius.
Compute the bounding sphere for each level in the tree (everywhere where there is
a '*' in my diagram).
Runtime:
========
At runtime, you walk that tree every frame, testing the bounding sphere against
the view frustum.
* If the sphere lies entirely outside the view frustum then stop traversal
for that node. There is no need to test any of the nodes beneath this one
(we know that none of their leaf tristrips are visible).
* If the sphere lies entirely inside the view frustum then traverse immediately
to all of the leaves below this node without doing any more sphere testing
on them - draw all of the tristrips that are there. (We know they are all visible)
* If the sphere straddles the view frustum then check each daughter node in
turn by applying this algorithm on them recursively. If a leaf node straddles
the view frustrum then it's bad luck, you just draw all the tristrips it
contains and let OpenGL do the work.
You might also want to put a 'transition range' onto each node and if it
lies beyond that range cull it. You can also use this to conveniently
switch levels of detail by having multiple versions of each object in
the tree.
Testing a sphere against the View Frustum:
==========================================
In most cases, we can describe the volume of space that you can see
through the little glass window on the front of your CRT using a
Frustum (frequently mis-spelled as Frustrum or Fustrum even in some
text books).
A frustum is a truncated pyramid - which typically bounded by six
planes called:
NEAR, FAR, LEFT, RIGHT, TOP, BOTTOM
There are applications that require additional clipping planes (eg for
non-rectangular screens) - extending the work described in this
to cater for that is not hard).
In principal, all six planes can be constructed as general plane
equations:
A x + B y + C z + D == 0
However, for most applications, NEAR and FAR are parallel to the
screen, LEFT, RIGHT,TOP and BOTTOM all meet at the eye and the eye lies
along a vector that extends out from the center of the screen and is
perpendicular to it. This simplifies the equations considerably for
practical applications.
Transforms.
~~~~~~~~~~~
It is easiest to perform culling in a coordinate system where the
eyepoint is at the origin and the line from the eye through the center
of the screen lies along one major axis with the edges of the screen
parallel to the remaining two axes. This coordinate system is called
'Eye Space'.
Testing a Sphere against a Frustum.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The most important thing to bear in mind about culling is that the
first trivial-reject test you apply is by far the most time-critical.
This test is always applied to more nodes than any of the subsequent
tests.
So, do the cheapest test first.
This is typically the NEAR plane test. Everything behind the viewers
head gets chopped out - and it's an especially cheap test.
if ( obj_sphere.center.z < near_plane - obj_sphere.radius )
REJECT!!
...next do the second cheapest test (assuming you know that your
database could possibly extend beyond the far clip plane)...
if ( obj_sphere.center.z - obj_sphere.radius > far_plane )
REJECT!!
...and *then* (for each of the other 4 planes) do...
if ( distance( obj.position, plane ) <= obj_sphere.radius )
REJECT!!
(The algorithm for computing that 'distance()' function is described
below).
It's also useful to know that in many applications, you cull more
objects from the left and right faces of the frustum than you do from
the top and bottom - so test left, then right, then bottom then top.
Also, with bounding sphere tests, you shouldn't forget to do
total-accept as well as total-reject tests. Once you know that an
object's sphere is TOTALLY on screen, you don't have to descend into
the daughter objects to cull-test them...you *know* they are all
on-screen.
Another way to look at that it to remember which of the six possible
plane tests didn't even touch the sphere - as you work your way down
the object hierarchy, you can accumulate those flags and avoid even
testing those planes that a parent sphere has already cleanly passed.
If you do this then a vast percentage of your spheres will only need to
be tested against one plane. However, for the normal case of a simple
frustum - when you examine the fully optimised
distance-of-point-from-plane code (below), you may well conclude that
this additional logic doesn't justify the paltry amount of additional
math that it might save.
Computing the Distance from Sphere Center to Clipping Plane.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A plane can be represented by the equation
Ax + By + Cz + D = 0 ;
A,B,C is just the surface normal of the plane and D is the shortest
distance from the origin to the plane.
So, if you need to find the distance of a point from the plane, just
imagine a new plane that goes through your test point and is parallel
to the plane you want to test. The plane equation of that new plane
would be:
A'x + B'y + C'z + D' = 0 ;
Since the two planes are parallel, their surface normals are the same,
so
A' == A B' == B C' == C D' == D + distance_between_the_two_planes
...the only thing that's different is their D values - which differ by
the distance of your test point from the original plane.
So, for a point (x,y,z), the distance 'd' from the plane (A,B,C,D) is
derived as:
d = D' - D
= -A'x - B'y - C'z - D
= -Ax - By - Cz - D
= -( [ABC]dot[xyz] + D )
A dot-product of the point and the surface normal of the plane, plus
the distance from the plane to the origin. Three multiplies, three
additions and a negation.
As an aside - if you consider the point (x,y,z) as a FOUR element
homogeneous vector (x,y,z,w) then 'w' is 1.0 and you can compute the
distance by simply taking the four element dot-product of (A,B,C,D)
with (x,y,z,w). If you have fast 4x4 matrix math hardware in your
machine then you can use it to compute the distance from a point to all
four planes in a single operation!
That's the general result for an arbitary plane - but culling to the
view frustum is a very special case. If you are working in eye-relative
coordinates (IMHO this is best), then since all TOP,BOTTOM,LEFT,RIGHT
planes of the frustum meet at the eye - and since the eye is at the
origin (by definition), then D is always zero for those planes and that
saves you a subtract.
If you are feeling even more in need of optimisation - then you can
save one multiply per plane by realising that (for rectangular screens)
one of the three components of the plane equation will always be zero.
So, for the LEFT clip plane, the Y component of the normal of the plane
is zero, so the distance to the left or right plane is just
d = -( Ax + Cz )
...and to the top or bottom plane it's just:
d = -( By + Cz )
Furthermore, we know that the A component for the LEFT plane is just
the negation of the A component of the RIGHT plane, and the C component
is the same for both LEFT and RIGHT (and similarly, the B component of
the TOP plane, is the negation of the B component for the BOTTOM plane
and the C component is the same for both TOP and BOTTOM). This means
that you only need four multiplies and four additions to do the entire
job. (Since you are only using this for culling, you don't need the
minus sign - just reverse the conditional).
The NEAR and FAR planes are typically parallel to the X/Y plane. That
means that A and B are both zero and C is one (or minus-one) - but D is
not zero, so the math boils down to an add and a negate:
d = -(z + D)
Conclusions.
~~~~~~~~~~~~
Sphere-based culling can be extremely cost-effective. It's so cheap
that even if you feel the need to use a bounding cubeoid (or even a yet
more complex shape), it's still worth doing a sphere-based cull first
just to get rid of the trivial accept and reject cases.
Steve Baker 817-619-8776 (Vox/Vox-Mail)
Hughes Training Inc. 817-619-4028 (Fax)
2200 Arlington Downs Road SBaker@link.com (eMail)
Arlington, Texas. TX 76005-6171 SJBaker1@airmail.net (Personal eMail)
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
** Beware of Geeks bearing GIF's. **
From owner-flight-gear@me.umn.edu Thu Jan 15 21:09:17 1998
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1752" "Thu" "15" "January" "1998" "22:08:56" "-0500" "Bob Kuehne" "rpk@sgi.com" nil "41" "Re: [FGFS] Status Update w/ Scenery" "^From:" nil nil "1" nil nil nil nil nil]
nil)
Received: (from majordom@localhost)
by meserv.me.umn.edu (8.8.8/8.8.6) id VAA10212
for flight-gear-outgoing; Thu, 15 Jan 1998 21:09:17 -0600 (CST)
X-Authentication-Warning: meserv.me.umn.edu: majordom set sender to owner-flight-gear@me.umn.edu using -f
Received: from sgi.sgi.com (SGI.COM [192.48.153.1])
by meserv.me.umn.edu (8.8.8/8.8.6) with SMTP id VAA10205
for <flight-gear@me.umn.edu>; Thu, 15 Jan 1998 21:09:11 -0600 (CST)
Received: from dataserv.detroit.sgi.com (relay.detroit.sgi.com [169.238.128.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id TAA28641
for <@external-mail-relay.sgi.com:flight-gear@me.umn.edu>; Thu, 15 Jan 1998 19:09:07 -0800
env-from (rpk@sgi.com)
Received: from applab3.detroit.sgi.com by dataserv.detroit.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/930416.SGI)
for <@dataserv.detroit.sgi.com:flight-gear@me.umn.edu> id WAA02541; Thu, 15 Jan 1998 22:09:00 -0500
Received: from localhost (rpk@localhost) by applab3.detroit.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id WAA04150 for <flight-gear@me.umn.edu>; Thu, 15 Jan 1998 22:08:56 -0500
X-Sender: rpk@applab3.detroit.sgi.com
In-Reply-To: <199801160204.UAA06347@kenai.me.umn.edu>
Message-ID: <Pine.SGI.3.96.980115215042.4110A-100000@applab3.detroit.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
Reply-To: flight-gear@me.umn.edu
From: Bob Kuehne <rpk@sgi.com>
Sender: owner-flight-gear@me.umn.edu
To: flight-gear@me.umn.edu
Subject: Re: [FGFS] Status Update w/ Scenery
Date: Thu, 15 Jan 1998 22:08:56 -0500 (EST)
On Thu, 15 Jan 1998, Curtis L. Olson wrote:
> Eric Mitchell (from the MSFS world) sent me some really nice textures,
> so I may just have to sit down and figure out how to texture a polygon
> in OpenGL. It looks like the hardest part will be deciding what image
> format to use and figuring out how to read that into memory so OpenGL
> can use it as a texture.
1) load the texture (and mipmaps) via glTexImage2D. Ideally we'll want to
use a bound texture (in 1.1, and in 1.0 as an extension) for efficency.
2) enable texturing with glEnable( GL_TEXTURE_2D )
3) Throw a 'glTexCoord2[*]' (your favorite variant of that call) next to
each vertex you draw.
> I have an example of how to do this with the JPEG format using
> jpeglib. IRIX RGB format seems like it might be the most
> straightforward, but not the most space efficient. I don't believe
on disk - note that in memory the only type of image data that most OpenGL
implementations can deal with is uncompressed.
> it's pretty easy to convert amongst these formats, but not necessarily
> as easy to read them into your program.
> One of these day's I'm going to have to break down and buy an OpenGL
> book ... I bet they tell you exactly how to do this stuff. :-)
You, sir, are a candidate for the Red Book. :)
Bob
Bob Kuehne | There was coffee. | Applications
rpk@sgi.com | Life would go on. | Consulting
248/848-4465 | William Gibson, The Winter Market | Silicon Graphics
-------------------------------------
Please visit the Flight Gear web page:
http://www.menet.umn.edu/~curt/fgfs/
For help on using this list (especially unsubscribing), send a message to
"flight-gear-request@me.umn.edu" with a single line of text: "help".
From owner-flight-gear@me.umn.edu Fri Jan 16 01:41:59 1998
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1477" "Fri" "16" "January" "1998" "03:42:36" "-0600" "Steve Baker" "sbaker@link.com" nil "38" "Re: [FGFS] Status Update w/ Scenery" "^From:" nil nil "1" nil nil nil nil nil]
nil)
Received: (from majordom@localhost)
by meserv.me.umn.edu (8.8.8/8.8.6) id BAA15817
for flight-gear-outgoing; Fri, 16 Jan 1998 01:41:59 -0600 (CST)
X-Authentication-Warning: meserv.me.umn.edu: majordom set sender to owner-flight-gear@me.umn.edu using -f
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
by meserv.me.umn.edu (8.8.8/8.8.6) with ESMTP id BAA15813
for <flight-gear@me.umn.edu>; Fri, 16 Jan 1998 01:41:53 -0600 (CST)
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
id BAA10510 for <flight-gear@me.umn.edu>; Fri, 16 Jan 1998 01:41:21 -0600 (CST)
X-Sender: steve@lechter.bgm.link.com
In-Reply-To: <Pine.SGI.3.96.980115215042.4110A-100000@applab3.detroit.sgi.com>
Message-ID: <Pine.SGI.3.96.980116033805.27487B-100000@lechter.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
Reply-To: flight-gear@me.umn.edu
From: Steve Baker <sbaker@link.com>
Sender: owner-flight-gear@me.umn.edu
To: flight-gear@me.umn.edu
Subject: Re: [FGFS] Status Update w/ Scenery
Date: Fri, 16 Jan 1998 03:42:36 -0600 (CST)
On Thu, 15 Jan 1998, Bob Kuehne wrote:
> 1) load the texture (and mipmaps) via glTexImage2D. Ideally we'll want to
> use a bound texture (in 1.1, and in 1.0 as an extension) for efficency.
Whether to load or compute the MIPmaps is an interesting question.
The nice thing about loading the MIPmaps from disk is that you can
use off-line tools to compute fancy MIPmaps in some special cases -
notably for translucent textures.
Talk to me off-line for an in-depth discussion sometime.
> > One of these day's I'm going to have to break down and buy an OpenGL
> > book ... I bet they tell you exactly how to do this stuff. :-)
>
> You, sir, are a candidate for the Red Book. :)
No question. Purchase (in this order):
Red (make sure your bookstore doesn't stick you with V1.0!!)
Green
Blue (but only if you dislike reading man pages off the screen)
Steve Baker 817-619-8776 (Vox/Vox-Mail)
Hughes Training Inc. 817-619-4028 (Fax)
2200 Arlington Downs Road SBaker@link.com (eMail)
Arlington, Texas. TX 76005-6171 SJBaker1@airmail.net (Personal eMail)
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
** Beware of Geeks bearing GIF's. **
-------------------------------------
Please visit the Flight Gear web page:
http://www.menet.umn.edu/~curt/fgfs/
For help on using this list (especially unsubscribing), send a message to
"flight-gear-request@me.umn.edu" with a single line of text: "help".
From sbaker@link.com Fri Jan 16 01:28:35 1998
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["2966" "Fri" "16" "January" "1998" "03:29:18" "-0600" "Steve Baker" "sbaker@link.com" nil "74" "Re: [FGFS] Status Update w/ Scenery" "^From:" nil nil "1" nil nil nil nil nil]
nil)
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
by meserv.me.umn.edu (8.8.8/8.8.6) with ESMTP id BAA15513
for <curt@me.umn.edu>; Fri, 16 Jan 1998 01:28:34 -0600 (CST)
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
id BAA02053 for <curt@me.umn.edu>; Fri, 16 Jan 1998 01:28:02 -0600 (CST)
X-Sender: steve@lechter.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
In-Reply-To: <199801160204.UAA06347@kenai.me.umn.edu>
Message-ID: <Pine.SGI.3.96.980116031847.27041B-100000@lechter.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
From: Steve Baker <sbaker@link.com>
To: "Curtis L. Olson" <curt@me.umn.edu>
Subject: Re: [FGFS] Status Update w/ Scenery
Date: Fri, 16 Jan 1998 03:29:18 -0600 (CST)
On Thu, 15 Jan 1998, Curtis L. Olson wrote:
> 5. This allows me to generate very nice images with the one exception
> which you can clearly see if you view the picture. The shared vertices
> aren't currently using shared normals, so the shading doesn't
> transition smoothly across tile boundaries.
We cheat and point all the vertices along the edges of squares
straight upwards.
The reason for this is simple - it allows us to build each square
independantly of the others - which is an important issue when
databases are build by a number of different people at different
times.
The result is remarkably reasonable - you still can't really tell
where the terrain tile edges are.
> Eric Mitchell (from the MSFS world) sent me some really nice textures,
> so I may just have to sit down and figure out how to texture a polygon
> in OpenGL. It looks like the hardest part will be deciding what image
> format to use and figuring out how to read that into memory so OpenGL
> can use it as a texture.
Consider using PNG as your image format - it's the future - it's very
compact, the loader is freeware, it's not a "lossy" format.
> I have an example of how to do this with the JPEG format using
> jpeglib.
JPEG is **NOT** a good choice - the data compression is "LOSSY" -
when you compress an image and decompress it, what you end up with
is different from what you started with. The compression scheme is
designed to not be noticable to the human eye - but that doesn't
hold up when the image is viewed in perspective. JPEG sucks.
> IRIX RGB format seems like it might be the most
> straightforward, but not the most space efficient.
True - but for lossless compression (where compress+decompress == no-op)
it's not far from optimal.
> I don't believe GIF is a 24bit color format (only 8bit)
That's true - there are also legal issues over it's copyright/patent.
> BMP has "Bill" written all over it (enough said.) :-)
Exactly.
> But, it's pretty easy to convert amongst these formats,
> but not necessarily as easy to read them into your program.
PNG is easy bacuse there are is a standard (and really good)
library available. It's also supported by both major web
browsers. It's the official replacement for GIF on the web.
> One of these day's I'm going to have to break down and buy an OpenGL
> book ... I bet they tell you exactly how to do this stuff. :-)
Yep - the example in the Red book is about all you need.
I'm sure you could get what you need from one of the Mesa
example programs though (in fact, aren't all the RedBook
examples distributed with Mesa? - I forget).
Steve Baker 817-619-8776 (Vox/Vox-Mail)
Hughes Training Inc. 817-619-4028 (Fax)
2200 Arlington Downs Road SBaker@link.com (eMail)
Arlington, Texas. TX 76005-6171 SJBaker1@airmail.net (Personal eMail)
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
** Beware of Geeks bearing GIF's. **
From owner-flight-gear@me.umn.edu Thu Feb 19 12:34:42 1998
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
["3263" "Thu" "19" "February" "1998" "12:35:18" "-0600" "Steve Baker" "sbaker@link.com" "<Pine.SGI.3.96.980219121749.23466B-100000@lechter.bgm.link.com>" "85" "Re: [FGFS] New HUD Screen Shots" "^From:" nil nil "2" nil nil (number " " mark " R Steve Baker Feb 19 85/3263 " thread-indent "\"Re: [FGFS] New HUD Screen Shots\"\n") nil nil]
nil)
Received: (from majordom@localhost)
by meserv.me.umn.edu (8.8.8/8.8.8) id MAA15262
for flight-gear-outgoing; Thu, 19 Feb 1998 12:34:42 -0600 (CST)
X-Authentication-Warning: meserv.me.umn.edu: majordom set sender to owner-flight-gear@me.umn.edu using -f
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id MAA15258
for <flight-gear@me.umn.edu>; Thu, 19 Feb 1998 12:34:35 -0600 (CST)
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
id MAA19280 for <flight-gear@me.umn.edu>; Thu, 19 Feb 1998 12:33:57 -0600 (CST)
X-Sender: steve@lechter.bgm.link.com
In-Reply-To: <199802191621.KAA09095@kenai.me.umn.edu>
Message-ID: <Pine.SGI.3.96.980219121749.23466B-100000@lechter.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk
Reply-To: flight-gear@me.umn.edu
From: Steve Baker <sbaker@link.com>
Sender: owner-flight-gear@me.umn.edu
To: flight-gear@me.umn.edu
Subject: Re: [FGFS] New HUD Screen Shots
Date: Thu, 19 Feb 1998 12:35:18 -0600 (CST)
On Thu, 19 Feb 1998, Curtis L. Olson wrote:
> Here's where I'm at with textures.
>
> 1. I gleaned some "RGB" format texture loading code out of a GLUT
> demo.
So you have the texture into OpenGL using glGenTextures/glBindTexture
and you have a number for each texture? Does the routine generate
the MIPmaps for you?
> 2. I have some reasonable terrain textures for starters that Eric
> Mitchell from the MSFS world contributed.
Good start! (Could you post them to the Web site? I might be able
to suggest a suitable scale factor for them)
> So for anyone who's familiar with texturing, it would likely be a
> simple matter to call the texture load routine and do all the
> OpenGL-ese to setup the textures.
As a starter (just to get something going), you could simply divide the
latitude and longitude of each terrain vertex by some suitable constant
and use that as the texture coordinate. Alternatively, you could let
OpenGL do the work using glTexGenf.
Something like (off the top of my head):
glEnable ( GL_TEXTURE_2D ) ;
glBindTexture ( GL_TEXTURE_2D, texture_number ) ;
glTexParameteri ( GL_TEXTURE_2D , GL_TEXTURE_WRAP_S , GL_REPEAT ) ;
glTexParameteri ( GL_TEXTURE_2D , GL_TEXTURE_WRAP_T , GL_REPEAT ) ;
glTexParameteri ( GL_TEXTURE_2D , GL_TEXTURE_MAG_FILTER, GL_LINEAR ) ;
glTexParameteri ( GL_TEXTURE_2D , GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR ) ;
glTexEnvi ( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE ) ;
glHint ( GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST ) ;
{
Draw bunches of terrain
For each vertex, add a glTexCoord2f with your scaled lat/long
values
}
glDisable ( GL_TEXTURE_2D ) ;
> So, I guess I've been trying to make what I have be a bit more solid
> before I charge forward again.
I guess that's a good thing.
Adding texturing is *SO* easy though that you might want to just
slip it in when you have an odd hour and feel like getting a 'WOW!'
response!
:-)
> > Have you checked the link ordering?
> >
> > I see a couple of posts a day from people who have either failed to
> > link with M$ OGL *as well as* SGI's OpenGL (SGI's OpenGL relies
> > on some functions from M$ OpenGL) - or who have linked them in the
> > wrong order or something.
>
> Interesting, I'm not linking in opengl32 or glu32 ... The compiler
> never complains about unresolved symbols, and at runtime, I get no
> complaint about missing dll's.
Hmmm - that's odd - I'm pretty sure you need them because SGI's
OpenGL falls back to M$ opengl if it thinks that M$'s OpenGL has
hardware accelleration. That suggests that it *must* link to it
somehow.
Steve Baker 817-619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc. 817-619-4028 (Fax)
2200 Arlington Downs Road SBaker@link.com (eMail)
Arlington, Texas. TX 76005-6171 SJBaker1@airmail.net (Personal eMail)
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
** Beware of Geeks bearing GIF's. **
-------------------------------------
Please visit the FGFS web page: http://www.menet.umn.edu/~curt/fgfs/
For help on using this list (especially unsubscribing), send a message to
"flight-gear-request@me.umn.edu" with a single line of text: "help".
From sbaker@link.com Mon Apr 27 23:45:25 1998
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
["2532" "Mon" "27" "April" "1998" "23:43:38" "-0500" "Steve Baker" "sbaker@link.com" "<Pine.SGI.3.96.980427233205.16486C-100000@lechter.bgm.link.com>" "58" "Re: texture coordinates" "^From:" nil nil "4" nil nil nil nil nil]
nil)
X-VM-Message-Order:
(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
31 32)
X-VM-Summary-Format: "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n"
X-VM-Labels: ("r")
X-VM-VHeader: ("Resent-" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:") nil
X-VM-Bookmark: 32
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id XAA19155
for <curt@me.umn.edu>; Mon, 27 Apr 1998 23:45:24 -0500 (CDT)
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
id XAA03828 for <curt@me.umn.edu>; Mon, 27 Apr 1998 23:44:53 -0500 (CDT)
X-Sender: steve@lechter.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
In-Reply-To: <199804272123.QAA19688@kenai.me.umn.edu>
Message-ID: <Pine.SGI.3.96.980427233205.16486C-100000@lechter.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
From: Steve Baker <sbaker@link.com>
To: "Curtis L. Olson" <curt@me.umn.edu>
Subject: Re: texture coordinates
Date: Mon, 27 Apr 1998 23:43:38 -0500 (CDT)
On Mon, 27 Apr 1998, Curtis L. Olson wrote:
> I just thought I'd fire off a quick texture coordinate question while
> things were fresh on my mind. I was doing the quick hack of texture
> coordinate = (lon, lat) * CONSTANT. I'm using a value of 128.0 for
> the constant, lat/lon are in degrees. This is giving me a lot of
> "swimming" of the textures, where each frame the texture gets aligned
> differently. I'm thinking that 128 * 180 = 23040 which isn't that big
> of a number.
>
> So then before "clicking the proverbial send button" I decided to
> fmod() the result with something smaller like 10.0 and now everything
> seems to work pretty well.
>
> Does this all sound reasonable?
Yes - regrettably, it does.
Most OpenGL implementations (or any 3D API for that matter) have
serious problems with texture precision when the numbers get
large.
As you must have realised, you really don't need all those large
integer parts - all that really matters is the delta.
I think the best thing to do is to use a different constant
for lat and long (v.important near the poles), and to compute
that "constant" for each terrain tile such as to get an integer
number of map repeats across the tile - keeping the actual size
of each texel reasonably close to what it was designed to be.
That ensures that adjacent tiles will match up most of the time
- and it will minimise the number of texture seams you get. The
coordinates within each tile should be as small as possible -
take the south-west corner of each tile as (0,0) in texture space.
I don't know of any really solid ways to avoid *any* texture
seams. It is after all a topological impossibility to tile
a sphere with equal sized squares without getting seams -
and the alternative is to distort the textures very badly
towards the poles - and that sucks even more than the
seams IMHO.
I had a plan once to tile the planet with a particular
grid spacing for each major continent - with the texture
seams appearing exactly at the Suez canal, Panama canal,
Straits of Gibralta...etc. I now believe that to be hard
to implement, and it still causes far too much distortion
in the larger continents.
Even if I could have made *that* work - there would still
be the problem of texturing the oceans.
In the end - I think seams are inevitable. (sniffle, sob)
Steve Baker (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-4028 (Fax)
Work: SBaker@link.com http://www.hti.com
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
From sbaker@link.com Mon May 4 07:42:43 1998
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
["3088" "Mon" "4" "May" "1998" "07:40:58" "-0500" "Steve Baker" "sbaker@link.com" "<Pine.SGI.3.96.980504071851.3721B-100000@sutcliffe.bgm.link.com>" "75" "Re: texture coordinates" "^From:" nil nil "5" nil nil nil nil nil]
nil)
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id HAA28780
for <curt@me.umn.edu>; Mon, 4 May 1998 07:42:42 -0500 (CDT)
Received: from sutcliffe.bgm.link.com (sutcliffe.bgm.link.com [130.210.236.18])
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
id HAA08974 for <curt@me.umn.edu>; Mon, 4 May 1998 07:42:10 -0500 (CDT)
X-Sender: steve@sutcliffe.bgm.link.com
Reply-To: Steve Baker <sbaker@link.com>
In-Reply-To: <199805011935.OAA12780@kenai.me.umn.edu>
Message-ID: <Pine.SGI.3.96.980504071851.3721B-100000@sutcliffe.bgm.link.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
From: Steve Baker <sbaker@link.com>
To: "Curtis L. Olson" <curt@me.umn.edu>
Subject: Re: texture coordinates
Date: Mon, 4 May 1998 07:40:58 -0500 (CDT)
On Fri, 1 May 1998, Curtis L. Olson wrote:
> (At this point I'm working in cartesian coordinates with all the
> terrain points.)
>
> I know a central point for a tile (average of min/max for x, y, z).
> If I normalize (x, y, z) this gives me a nice normal. So, I have a
> nice point and a normal which is enough to define a plane that roughly
> approximates the tile data points.
>
> Now, I could take each individual terrain point and project it onto
> this plane. This conceptually could be my texture coordinate. But, I
> would first have to rotate and translate the whole pile of projected
> points so that they are at or near (0,0,0) at which point I could drop
> the z dimension and (x,y) would be my real texture coordinate.
>
> I'm pretty confident that I could do the math, but do you think it
> would be worth the hassle? It would all happen in the preprocessing
> stage so I guess speed wouldn't be an issue.
The problem is that you would end up with a seam in the texture at the
edge of every terrain tile. Since your tiles are not exact squares,
and (from what you seems to be saying), your texture *is* a square,
there are bound to be differences in texture coordinates at the
edges of adjacent tiles. Imagine taking a lot of square post-it notes
(the textures) and sticking them onto a globe. Towards the poles,
they would overlap more and more - and that is what would happen
to your textures.
Using the original lat/long as the texture coordinate eliminates
the ugly seams.
S = lon / k1 ;
T = lat / k2 ;
(k1 & k2 are constants).
This squishes the texture around so it wraps neatly onto the spherical
surface.
However, there are two problems with this:
* The texture coordinates get very big and that causes texture
swimming, jitter, etc.
* The texture will now get long and thin near the poles.
The way I get around these two problems is firstly to say:
S = ( lon - tile_origin_lon ) / k1
T = ( lat - tile_origin_lat ) / k2
Now the texture coordinates are small - but the texture
seams come back unless k1 and k2 are exact submultiples of
a terrain tile size (expressed in degrees latitude/longitude).
So, I set k1/k2 to the exact submultiple of a terrain tile
size that comes closest to the ideal scale that I want for
my textures (expressed in meters per map repeat). Since the
size of a degree of longitude changes over the surface of
the earth, k1 is no longer a constant. Whenever k2 changes,
you get a texture seam that runs east-west across the terrain.
This is unavoidable - but a lot better than having seams at
the edges of every terrain tile.
Hence, k1 will equal k2 at the equator and gradually go to
zero at the poles. It's easiest to take the longitudinal
size of the terrain tile half way up the tile (rather than
at the top or bottom edge) to avoid a divide by zero error
at either the north or south pole.
Steve Baker (817)619-8776 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-4028 (Fax)
Work: SBaker@link.com http://www.hti.com
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
From owner-fgfs-devel@flightgear.org Tue Sep 22 16:24:52 1998
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1870" "Tue" "22" "September" "1998" "16:23:23" "-0500" "Steve Baker" "sbaker@link.com" nil "43" "Re: [FGFS-Devel] vegetation / land use" "^From:" nil nil "9" 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 QAA05981
for <curt@me.umn.edu>; Tue, 22 Sep 1998 16:24:52 -0500 (CDT)
Received: from majordom by mailhub.woodsoup.org with local (Exim 1.92 #1)
for fgfs-devel-outgoing@flightgear.org
id 0zLZvM-0000ZG-00; Tue, 22 Sep 1998 16:24:40 -0500
Received: from bgm.link.com ([130.210.2.10] helo=lfkw10.bgm.link.com)
by mailhub.woodsoup.org with esmtp (Exim 1.92 #1)
for fgfs-devel@flightgear.org
id 0zLZvK-0000ZA-00; Tue, 22 Sep 1998 16:24:38 -0500
Received: from samantha.bgm.link.com (samantha.bgm.link.com [130.210.65.19])
by lfkw10.bgm.link.com (8.8.6/RSC-RTI-1.0) with SMTP
id QAA23764 for <fgfs-devel@flightgear.org>; Tue, 22 Sep 1998 16:24:08 -0500 (CDT)
X-Sender: steve@samantha.bgm.link.com
In-Reply-To: <3607FBD8.58FC@mars.ark.com>
Message-ID: <Pine.SGI.3.96.980922152528.24232C-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: Steve Baker <sbaker@link.com>
Sender: owner-fgfs-devel@flightgear.org
To: fgfs-devel@flightgear.org
Subject: Re: [FGFS-Devel] vegetation / land use
Date: Tue, 22 Sep 1998 16:23:23 -0500 (CDT)
On Tue, 22 Sep 1998, Eric Mitchell wrote:
> Sounds good. Can you tell me the (rough) dimensions of a single texture
> square when it's rendered in FG? I'll need to know that to make the farm
> fields look right.
I think we should be prepared to vary the size of the texels on the ground
to fit the style of the map. (The technical term for "the size of the
texels on the ground" is the "lambda" of the texture - measured in
meters-per-texel).
Also, it's going to be hard to pick a single lambda that looks good at
all altitudes. There isn't a good solution for that - with big SGI machines,
you can use a feature called "detail texture" - but there don't seem to
be any efforts to implement that on PC boxes yet.
Maybe we'll make use of the upcoming multitexture hardware (if 3Dfx
and nVidia solve their lawsuits...) to apply two or more textures
at differing lambdas.
I think the preson who paints the map should have some idea of what
altitudes it's going to look good at - and hence should be able to
specify the lambda to the terrain generator software on a per-map
basis.
Clearly, for field patterns, we need a fairly small lambda to make it
possible to see nice sharp field edges with the odd road or boundary
hedge/treeline running between them. This makes the texture fairly
repetitious, but for field patterns that may not be too bad.
For fuzzier 'natural' textures, you can use a larger lambda's resulting
in less obvious repetition.
Steve Baker (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-4028 (Fax)
Work: SBaker@link.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".
From owner-fgfs-devel@flightgear.org Tue Sep 22 16:28:28 1998
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1472" "Tue" "22" "September" "1998" "16:26:37" "-0500" "Steve Baker" "sbaker@link.com" nil "34" "Re: [FGFS-Devel] vegetation / land use" "^From:" nil nil "9" 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 QAA06106
for <curt@me.umn.edu>; Tue, 22 Sep 1998 16:28:27 -0500 (CDT)
Received: from majordom by mailhub.woodsoup.org with local (Exim 1.92 #1)
for fgfs-devel-outgoing@flightgear.org
id 0zLZyX-0000aT-00; Tue, 22 Sep 1998 16:27:57 -0500
Received: from bgm.link.com ([130.210.2.10] helo=lfkw10.bgm.link.com)
by mailhub.woodsoup.org with esmtp (Exim 1.92 #1)
for fgfs-devel@flightgear.org
id 0zLZyW-0000a5-00; Tue, 22 Sep 1998 16:27:56 -0500
Received: from samantha.bgm.link.com (samantha.bgm.link.com [130.210.65.19])
by lfkw10.bgm.link.com (8.8.6/RSC-RTI-1.0) with SMTP
id QAA23910 for <fgfs-devel@flightgear.org>; Tue, 22 Sep 1998 16:27:21 -0500 (CDT)
X-Sender: steve@samantha.bgm.link.com
In-Reply-To: <13831.64964.272599.402309@kenai.me.umn.edu>
Message-ID: <Pine.SGI.3.96.980922162432.24319B-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: Steve Baker <sbaker@link.com>
Sender: owner-fgfs-devel@flightgear.org
To: fgfs-devel@flightgear.org
Subject: Re: [FGFS-Devel] vegetation / land use
Date: Tue, 22 Sep 1998 16:26:37 -0500 (CDT)
On Tue, 22 Sep 1998, Curtis L. Olson wrote:
> Eric Mitchell writes:
> > Sounds good. Can you tell me the (rough) dimensions of a single texture
> > square when it's rendered in FG? I'll need to know that to make the farm
> > fields look right.
>
> This is a tough one I haven't really ironed out yet. We can easily
> change this in the code to suit our needs. 3dfx imposes a 256x256
> limitation on texture dimensions. What amount of ground could we
> reasonably cover with a texture of this resolution. Obviously this is
> trade off city here ... :-(
Probably ought to paint the maps at better than 256x256 resolution - 3Dfx
won't be the norm forever - and there is a definite trend to having much
bigger maps - and more of them.
All portable OpenGL code should use the "PROXY" texture trick to figure
out if the texture is going to fit and automagically reduce the size
(by dropping out the higher level MIPmaps) on less capable hardware.
This will make the textures look fuzzier on 3Dfx hardware than on others,
especially at low altitudes.
Steve Baker (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-4028 (Fax)
Work: SBaker@link.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".
From mschaefe@MIT.EDU Wed Sep 23 12:33:42 1998
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
["1083" "Wed" "23" "September" "1998" "13:30:37" "-0400" "mschaefe@MIT.EDU" "mschaefe@MIT.EDU" nil "34" "Re: [FGFS-Devel] vegitation / land use" "^From:" nil nil "9" nil nil nil nil nil]
nil)
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
by meserv.me.umn.edu (8.9.1a/8.9.1) with SMTP id MAA22241
for <curt@me.umn.edu>; Wed, 23 Sep 1998 12:33:42 -0500 (CDT)
Received: from MIT.MIT.EDU by MIT.EDU with SMTP
id AA17918; Wed, 23 Sep 98 13:33:41 EDT
Received: from LFM-IDAHO.MIT.EDU by MIT.MIT.EDU (5.61/4.7) id AA06057; Wed, 23 Sep 98 13:33:41 EDT
Message-Id: <3.0.32.19980923133036.008fc440@po10.mit.edu>
X-Sender: mschaefe@po10.mit.edu
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
From: mschaefe@MIT.EDU
To: "Curtis L. Olson" <curt@me.umn.edu>
Subject: Re: [FGFS-Devel] vegitation / land use
Date: Wed, 23 Sep 1998 13:30:37 -0400
Curt,
I believe all of that data is contained on the 1:2mil CD, which I know to
be in lat/long format. It's FTP'able, or you can buy the CD for $20, with
data from all the states (I'm not sure if AK and HI are included on 2mil).
It doesn't, as far as I know, have building/smokestack/... data on the
2mil CD. It think that's much too detailed.
Mark
P.S. Check out
ftp://mapping.usgs.gov/pub/ti/DLG/2mdlgguide/1994_Revision/2mdug95.txt
for more info on what is contained on the CD. The site has more
information on how to decode the data as well.
>Mark,
>
>Is there lake, road, river, city outline data available on line that
>uses lat/lon coordinates? The data sets I've seen have all been
>with the funky projected coordinate system relative to some reference
>point.
>
>What other things can you get out of this? Is there smoke stack,
>powerline, tall building data available in these too?
>
>Thanks,
>
>Curt.
>--
>Curtis Olson University of MN, ME Dept.
>curt@me.umn.edu
>http://www.menet.umn.edu/~curt Try Linux!
>
View git blame Copy permalink