Thread: [Algorithms] Large scale terrain vis
Brought to you by:
vexxed72
From: Brian H. <ho...@bo...> - 2004-09-16 14:58:02
|
Is anyone aware of extreme scale terrain visualization research, e.g. orbital down to planet, using spherical geometry instead of planar heightfields? Brian |
From: Thatcher U. <tu...@tu...> - 2004-09-16 17:27:43
|
On Sep 16, 2004 at 10:57 -0400, Brian Hook wrote: > Is anyone aware of extreme scale terrain visualization research, e.g. > orbital down to planet, using spherical geometry instead of planar > heightfields? You should be able to find loads of stuff on this; here are a couple notes: "Adaptive Tetrapuzzles" by Cignoni et al from Siggraph 2004 looks pretty good. They have a nice movie of a Mars flyover. http://www.crs4.it/vic/cgi-bin/bib-page.cgi?id='Cignoni:2004:ATE' http://www.cs.brown.edu/~tor/sig2004.html It's basically chunked LOD plus a clever tetrahedral subdivision scheme so they handle arbitrary meshes and never have cracks. You can also map six heightfields onto cube faces and treat the heightfield coords as spherical coords. (Involves a per-vertex normalize + misc ops somewhere in your pipeline, see chunklod code for a very rough experiment along these lines.) -- Thatcher Ulrich http://tulrich.com |
From: Mark D. <duc...@ll...> - 2004-09-16 19:41:03
|
Hi Brian, For dealing with huge planet databases, we have a paper coming out at IEEE Vis shortly, the final paper is online temporarily here: http://graphics.cs.ucdavis.edu/~duchaine/vis04_4-8textures.pdf This deals with both the texturing and geometry, out-of-core disk layouts, efficient chunked vertex buffer use, and the use of ROAM2-style diamonds for planetary geometry. Since the IEEE Vis format only allows eight pages, there will be a follow-on journal article with additional details. I will have a draft of that paper hopefully by the end of this month. You should also check out the BDAM papers by Cignoni and his group. Very nice work using ROAM-style triangle bintrees at the macro level, then high-quality edge-collapse (TIN) meshes within a bintree triangle patch using chunked vertex arrays etc. They use a basic quadtree scheme for the textures. I would recommend looking instead at the quadtree of mipmaps scheme that Thatcher Ulrich came up with, or try out the 4-8 textures. Your height maps on disk can be compressed by storing only displacements in the "up" direction that correct one level to the next level. If you want, wavelets can be used, but that causes some restrictions on the quality of low-pass filter you can use. Very nice procedural geometry can be produced using the -1/16 9/16 9/16 -1/16 midpoint interpolation weighting combined with random displacements. There are lots of aspects to getting fully scalable planets: from orbit to walk-around requires view-dependent coordinate systems and dealing with huge disparities in depth between foreground and background that cause Z fighting; there is also asyncronous loads, horizon culling, realtime shading, etc). What do you want to know more about at the moment? Cheers, --Mark D. Brian Hook wrote: > Is anyone aware of extreme scale terrain visualization research, e.g. > orbital down to planet, using spherical geometry instead of planar > heightfields? > > Brian |
From: Brian H. <ho...@bo...> - 2005-04-30 19:28:00
|
Thread necromancy at work! I read Hwa's paper, but I'm a little confused with some of the stuff in there to do with the diamond topology. In Fig 4 of the revised IEEE paper, the ancestors are labeled a0 to a3. a0 is the ancestor quad tree, a1/a2 are the immediate parents, but what is a2? It's not clear from the diagram what that's supposed to be. > You should also check out the BDAM papers by Cignoni and his group. How would you contrast the P-BDAM stuff with Hwa's work? Brian |
From: Mark D. <duc...@ll...> - 2005-05-04 17:01:13
|
Hi Brian, Yes, a0 is the quadtree ancestor (so the structure includes conventional quadtrees as one of its native capabilities), a1 and a3 are the right and left parents (that each overlap half of the diamond, thus defining conventional "triangle bintree" structures). The a2 ancestor is kind of an oddball. It can be a grandparent, or at any coarser level. Usually the a2 ancestor is only used to grab that corner vertex, and is not used in its role as an edge or face. We review the BDAM/P-BDAM work in the papers (briefly). I like their work a lot. The main issues are with dynamic geometry, filtering, textures and compression, all of which I think work out better using diamond tiles. Their use of high quality unstructured (TIN) simplification can produce lower geometric error for a given triangle count. There is some cost to this for preprocessing, and because you have a unique index array per triangle patch (with regular tiles you can just re-use a single index array for all patches). Also, the low-pass geometry filtering of regular tiles is very high quality using well known image processing methods, whereas the TIN methods are much trickier to use to avoid unintentional artifacts (think lighting and interpolation issues). My argument is that given the huge triangle counts we can now achieve on high-end (soon to be low-end) PC graphics cards, the process should be though of as doing high quality filtering for both textures and geometry. BTW, a somewhat shortened version of the paper will appear in TVCG soon. The best version to date is at http://graphics.cs.ucdavis.edu/~duchaine/roam_lecture20041110/hwa_tvcg04_revised.pdf I am working on getting some demo code and implementation notes out on the ROAM homepage. Cheers, --Mark D. Brian Hook wrote: > Thread necromancy at work! > > I read Hwa's paper, but I'm a little confused with some of the stuff > in there to do with the diamond topology. In Fig 4 of the revised > IEEE paper, the ancestors are labeled a0 to a3. a0 is the ancestor > quad tree, a1/a2 are the immediate parents, but what is a2? It's not > clear from the diagram what that's supposed to be. > > >>You should also check out the BDAM papers by Cignoni and his group. > > > How would you contrast the P-BDAM stuff with Hwa's work? > > Brian > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > |