Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 


Submitted by Zhu Yuanchen, posted on September 01, 2001




Image Description, by Zhu Yuanchen



Shown in the screen shots is the implementation of my terrain CLOD algorithm at work.

Features of the algorithm include:
  • quadtree based VFC.
  • frame coherent view-dependent CLOD meshing.
  • geomorphing.
  • LOD accuracy adjustment, my version of the "cluster ROAM bintree",4x subdivide in the implementation.
  • low mem consumption, 1-4 bytes per height sample, further 4/16/64 cut by LOD accuracy adjustment.
  • and a lot more.
  • Features of the implementation include:
  • optimized for TNT2 class hardware, as I developed it on a PIII 500+TNT2 pro. (yeah I know about the debate of CLOD on T&L hardware, but it's really possible to get fast CLOD implementation on T&L hardware, see the ROAM discussions in the gdalgorithm list).
  • 2M tps on TNT2 agp2x+PIII500 @40-50 fps. 4M tps on my laptop GeForce2 GO! agp4x + mobile PIII 1G @ 60fps.
  • SSE optimized geomorphing code.
  • the usual "landscape stuff":sky box/texture systemization,etc.
  • A demo is available at www.tbns.net/davidz. Note that the sky-box texture quality is quite bad because of JPEG compression, and the size of the landscape is 1025*1025. A NVIDIA TNT card or better is recommended. I once noticed texture seams artifacts on a ATI Rage 128, so please avoid ATI cards.(sorry, never got the time to fix it). Ah. And the thing is done in OpenGL, really nice for prototyping.

    Happy coding.
    Zhu Yuanchen


    [prev]
    Image of the Day Gallery
    www.flipcode.com

    [next]

     
    Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
     
    Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
     
    Wim Libaers

    September 01, 2001, 05:19 PM

    Looks really good. I've noticed a staircase effect on the mountain slopes, is that a side-effect of the algorithm, or are they intended to be like that?

     
    ecko_53

    September 01, 2001, 05:23 PM

    Nice demo...I was missing all those Terrain IOTDs...keep up the good work

     
    Flous

    September 01, 2001, 05:35 PM

    very nice images...

    damn shame the download is soooooooo slow :(
    still downloading here...

    On the ATI issue, check this link (http://www.flipcode.com/cgi-bin/msg.cgi?showThread=08-27-2001&forum=iotd&id=-1) to an iotd of a few days ago, where thay had the same problem. Check my reply there, if your program is opengl based, I think you'll find the answer there.

    Greetz, Flous

     
    Flous

    September 01, 2001, 05:41 PM

    damn, I accidently placed my reply in a sub-thread... well go check that out then plz, it might help you :)

     
    ShiningKnight

    September 01, 2001, 06:16 PM

    The patch size looks a bit small, which is sorta increasing the poly amount in needless spots, other than that it looks good.

     
    Alex J. Champandard

    September 01, 2001, 06:30 PM


    Nice texture combination ;)

    The sand is a bit too red though, try something a bit more like this!

    If I'm not mistaken, the height map is one of Commanche 3's...

    Nice tessellation.

     
    lycium

    September 01, 2001, 06:41 PM

    pls upload the latest terravox demo! :)

     
    MC BAXTON

    September 01, 2001, 07:43 PM

    LOL.
    Enjoying benefits of giant texture ?
    Prefer *.dat, not *.jpg ? What a secret. Now Im gonna copy your jpgs and use in my programs (joke though .. dont like monkey-style)
    Why do you post 8 images ? 2( but bigger) would be enough.
    Your program is not running on my win2k, no messages, just black screen. (Possible problem: few hours loading time ? Too much for me)
    Normal people put some information on screen when loading(including me)
    You choosed not the best positions for viewing in best perspective.


     
    iMalc

    September 01, 2001, 08:20 PM

    Your meshes look really good, the size of close triangles look the same as the far ones.
    Nice sky photo too.
    Time to put it to use in a game.

     
    Hydri

    September 01, 2001, 09:12 PM

    I just read your post about GL_CLAMP.
    Tell me, do you mean that there is a border on textures that you explicitly give a 0 bordersize?

     
    Wesley Wu

    September 01, 2001, 11:58 PM

    Congratulations, guy! It is not difficult to guess who I am. Keep up the good work!

     
    Thunderbird

    September 02, 2001, 01:09 AM

    Looks nice. I don't know what half of those features are (Frame coherent view dependent CLOD meshing??), but they do sound good. At least I know what geomorphing is.

     
    MiNDHiVE

    September 02, 2001, 03:30 AM

    If I'm not mistaken, frame coherence involves retaining the mesh from the last frame and then increasing/reducing the polycount where required until it's time to render the scene...

    Very nice little demo... loved the midi music (I assume it was midi?). hehehe

    I'm also interested in the algo you used to create the terrain texture. Very nice :)

    Well done.

     
    Arne Rosenfeldt

    September 02, 2001, 04:07 AM

    IMHO:
    when going to higher LOD usually only z is refined,
    so when looking from above u need lower LOD than when looking from the side

    or in other words:
    project the z differenz between real landscape and LOD-level on screen
    regulate this to be under a threshold

     
    David Z

    September 02, 2001, 04:44 AM

    All right. Here're the replies to all the questions above:

    (1) "staircase side-effect": my fault, not the program's. I used 16bit per height sample for internally storing heightmaps, but 8bit grayscale jpeg for storing them on the disk (at lease in the demo to keep the file size small). I should have smoothed the heightmaps after reading in the jpegs, and then the staircase would be gone.

    (2) "GL_CLAMP": my fault again. I actually knew the problem before the post, but at the time of writing the demo, I figured it out that I would only show it on my own PC (on the ISEF), so I just neglected it to make my life a bit easier.

    (3) "patch size": could you be more specific? I have some vague ideas of what you're talking about, but don't fully understand your meaning.

    (4) "nice textures": all the artworks/heightmaps are grabbed somewhere (I forgot where)from the web. So the credit of the good looking textures should really go to their respective authors. E-mail me if you have created some of the textures.

    (5) ".dat instead of .jpg/win2k problem": for some dumb reasons I chose the ".dat" extensions. I developed the demo on a win2k box, so surely it's not the problem with the OS. Would you send me your computer's spec. (Baxton? BTW, you got a GF3, don't you?) As to the the loading time, it should be less than 6 seconds on a 500 MHz machine, and "Now loading. Please wait..." is shown on the screen when loading. And, (again, dumb of me ;) I really canít understand your last sentence.

    (6) "music/tex synth": Yes, it's a midi. Forget the '.dat' extension. The synth algorithm is just based on height and slope, plus some preburnt lighting.

    (7) "Wesley Wu": Surely I know who you are :) Greetings.

    (8) "side/top viewing": Yes, it's true, although the Z-buffer would be affected if you only use the projection based LOD function space (donuts shaped), which sucks if you want to put objects on the terrain. Actually I kind of compromised between these two by using a squashed sphere for the LOD function space.




     
    David Z

    September 02, 2001, 04:48 AM

    Ah, just one more thing. Rename the "path.dat" file in the data subdir and you'll be able to roam around with your mouse buttons.

     
    dom

    September 02, 2001, 07:31 AM

    Very nice indeed! Very beautiful.

    Please can you explain a little about the texturing solution you use?

    I've read that some people use *one* big texture to lay over the whole terrain. This seems implausible to me -- how are you gonna get a texture big enough?!. Are you tiling several different textures? I can understand that better, that's how I do mine. Do you render with one pass or multiple, how many? How/where in the vertex format do you define the textures' relative visibilities?

    Thanks!,

    d.

     
    AblazeSpace

    September 02, 2001, 08:18 AM

    Any source-code? I would love to studie it!! (especially the camera code for this smooth inerpolation between the keyframes)
    Keep up the good work!

     
    David Z

    September 02, 2001, 09:39 AM

    well, it is one big texture "treadmark" style, with preburnt lighting and another detail texture layed on top. So with single pass dual texturing cards, it's one pass. Really not the best possible solution, but looks nice enough for my purpose.

     
    David Z

    September 02, 2001, 09:49 AM

    The camera: I define some keyframes,((x,y,z,xrotate,yrotate,zrotate) you can see them in path.dat) and use Catmull-rom spline interpolation.

    As to the code: sorry, not available at the time. I am seeking publication of my algo on IEEE Trans. and according to their regulations, I'd better not do anything like releasing the code until the paper actually gets published.

     
    MC BAXTON

    September 02, 2001, 10:15 AM

    Thanks for answer, my card is voodoo3, ram is 396MB, PIII 500
    of course its "optimized" for GF3, or to be truly honest, not optimized.

    I guess if u use one big texture, u can create only one small terrain... But in this case you could prepare it completely before rendering ( blend all textures+lightmaps) and just render it normal way.
    So in fact its easy to get it working on any card.

    About texturing solutions ... I could bet I read it soemwhere in flipcode tutorials... the result on the screen is pretty similar. But I do not think that big texture can be good solution. For demo it can prolly be good.



     
    David Z

    September 02, 2001, 10:22 AM

    Really cannot understand why it showed black screen on your system. Perhaps Voodoo3 has crappy opengl implementations? Again, I don't know. Guess I'd have to switch to Dx8.

     
    Flous

    September 02, 2001, 10:48 AM

    No, not really...

    What I meant is that when filtering (using GL_LINEAR for example) and using GL_CLAMP the texels near the edge of the texture, in Opengl, the driver is supposed to take the border color into account instead of wrapping or whatever some drivers do... By defaultn this border color is set to complete black, so when filtering near the edges with GL_CLAMP you are supposed to get smooth black edges (or whatever color you set the border color to). Since this is not very usefull in games, and since it is quite difficult to implement in hardware, most driver/card manufactures ignore this border color thing.

    ATI's don't, they implement Opengl like it is supposed to be, so people developping on e.g. nvidia cards never see what problems might arise when using GL_CLAMP. And that's a damn shame, since it is so easy to correct the problem (as I explained in the other post)

    greetz, Flous

     
    steinvk

    September 02, 2001, 10:50 AM

    Very nice work.
    Is it possible to see the source, so I newbie like me could learn :)

     
    Peter Mackay

    September 02, 2001, 10:52 AM

    Hi David,

    I've not tried the demo, but the screenshots look great.

    If you're using a texture above 256 x 256, it will probably mess up on Voodoo cards, since that's the largest size the card can do.

    - Pete

     
    Louis Howe

    September 02, 2001, 12:35 PM

    In OpenGL, I thought that (don't quote me on this) polygons with invalid textures (bad ID or an ID to a texture of invalid dimensions) is drawn white. Maybe, if your screen is all black, it's trying to switch into the wrong color depth?

     
    MC BAXTON

    September 02, 2001, 01:25 PM

    after rerunning executables on win2k, I get the instruction at (address) referenced memory at 0x0000000 error. Obviously, not supported features are used without availability detection. Its usual error in such cases.

     
    MC BAXTON

    September 02, 2001, 01:35 PM

    Since this is not very usefull in games, and since

    *it is quite difficult to implement in hardware*

    , most driver/card manufactures ignore this border color thing.
    ATI's don't, they implement Opengl like it is supposed to be, so people developping on e.g. nvidia cards never see what problems might arise when using GL_CLAMP.
    And that's a damn shame, since it is

    *so easy to correct the problem*

    So it is easy to correct this problem or hard ? Or Im missing something...

     
    Coriolis

    September 02, 2001, 04:41 PM

    My experience has been that 3dfx did not gracefully handle creating a texture greater than 256x256; a black-screen lockup for this sounds entirely plausible.

     
    Hydri

    September 02, 2001, 07:58 PM

    "No, not really..."

    "in Opengl, the driver is supposed to take the border color into account instead of wrapping or whatever some drivers do"

    I'm sprry if I don't understand what you mean, but I sense a contradiction here. If the texture don't have a border (border width = 0) I interpret the opengl-specification that the border never will be used.

    Have a look in the red book:
    http://fly.cc.fer.hr/~unreal/theredbook/chapter09.html
    search for "Clamping a Texture"

    I beleive that ATI have made the wrong interpretation of the opengl-specification, I mean, they are not famous for writing good gl-drivers.

     
    This thread contains 30 messages.
     
     
    Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.