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" "" "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 ; 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 ; Mon, 12 Jan 1998 09:02:52 -0600 (CST) X-Sender: steve@lechter.bgm.link.com Reply-To: Steve Baker Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Steve Baker 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 ; 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 ; 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Reply-To: flight-gear@me.umn.edu From: Bob Kuehne 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 ; 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 ; Fri, 16 Jan 1998 01:41:21 -0600 (CST) X-Sender: steve@lechter.bgm.link.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Reply-To: flight-gear@me.umn.edu From: Steve Baker 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 ; 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 ; Fri, 16 Jan 1998 01:28:02 -0600 (CST) X-Sender: steve@lechter.bgm.link.com Reply-To: Steve Baker In-Reply-To: <199801160204.UAA06347@kenai.me.umn.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Steve Baker To: "Curtis L. Olson" 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" "" "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 ; 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 ; 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Reply-To: flight-gear@me.umn.edu From: Steve Baker 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" "" "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 ; 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 ; Mon, 27 Apr 1998 23:44:53 -0500 (CDT) X-Sender: steve@lechter.bgm.link.com Reply-To: Steve Baker In-Reply-To: <199804272123.QAA19688@kenai.me.umn.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Steve Baker To: "Curtis L. Olson" 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" "" "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 ; 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 ; Mon, 4 May 1998 07:42:10 -0500 (CDT) X-Sender: steve@sutcliffe.bgm.link.com Reply-To: Steve Baker In-Reply-To: <199805011935.OAA12780@kenai.me.umn.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Steve Baker To: "Curtis L. Olson" 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 ; 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 ; 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Reply-To: fgfs-devel@flightgear.org From: Steve Baker 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 ; 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 ; 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Reply-To: fgfs-devel@flightgear.org From: Steve Baker 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 ; 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" 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! >