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?

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

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

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

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

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.

pls upload the latest terravox demo! :)

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.

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.

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?

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

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.

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.

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

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.

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.

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.

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!

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.

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.

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.

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.

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

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

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

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?

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.

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

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.

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