Good job!! finally terrain engine!! :) is there source somewhere?

Hi dataman,

Very cute!

I was wondering what the benefit of geomipmap is?

And about the VCL: How did you manage to put the directX viewport on the VCL control?

Thanks & goodluck on your further experiments!

nkm

sounds very impressive!

1.can you say something about your "adaptive quad tree"?
2.what kind of dynamic lightning ?
3.how do you get the normals without the gridspacing ?

thanks

Slow blitting from the back buffer huh? I think it's funny it's one of the same issues 2D games used to have in the old days.

I thought 128x128 textures was pretty much the lowest common denominator for most peoples GPU's. I realize the GeForce family can handle 512x512's (or more?), but your performance will degrade significantly if the card starts storing textures in system RAM. Especially since no one uses the AGP bus. ;o)

But I digress. Looks very cool!

Looks very impressive, it would be nice to see some water.

How do you do your quadtree? As i'm currently trying to implement a quadtree myself. Which doesn't seem to work.


Well keep up the good work,

Ronald.

Silkyslim, almost every card on the market (even the much maligned ATI Rage Pro) supports 1024x1024 texture sizes. The only cards NOT to support that are early 3Dfx Voodoo cards, which supported only up to 256x256 textures.

These days, you'll be hard-pressed to find a card that DOESN'T support 2048x2048; and the GeForce3 even supports 4096x4096.

Adaptive quadtree, is that the same as the one of which they had an article on gamasutra? That's pretty cool, anyway. Good for huge terrain.
How do you do your geomipmaps? There seems to be different oppions about this. Do you do some sort of bilinear or "cubic" resampling of the heightmap and use that as a second LOD-stage or do you simply remove every other vertex?

Hi-res textures can be done by using texture splatting. Read about it on Charles Bloom's page. You can't do that on slow hardware though (GF minimum). It's faster than one would think though since you only transform each patch once (so you can render it 5 times and the last 4 times will basically only be rastering, no transformation).

Getting a Direct3D or OpenGL display in a VCL control is easy. I have created a few custom VCL controls in the past to do this. Remember that a visual control is really just another window with a handle. Pass this window handle to Direct3D and it will render itself to the window.

Thanks for the replies people.

icewolf: Sorry, but src will not be available. First, it's full of garbage (i keep it for back up ... and feature work) and it's not a public project.

NeukuM:
The benefit of geomipmaps is that you send a large batch of triangles/vertices to the 3d card in one time, and you avoid the habitual
ROAM/Qaud tree send of call per triangle fan. The 3d hardware likes this very much, and you have less API calls. (it likes it, because he
have some thing to do, till the next call, we use every clock of the card.. or almost ...correct me if i am wrong).

To init Dx, you need only a handle to a window. I use the handle of the TForm (your window) for full screen , and a handle to any
TWinControl (i use TPanel) for the windowed mode. (you can use Dx as background :) .
You use the TPanel size for the viewpoint ...etc .. I really don't remember what i did, it was so long ago ... I must convert every thing to
Dx8 soon (i use Dx7) . If you need more details ...ask again

TimeHunter:

Nothing to say about dynamic lighting. I use Dx directional light with the vertex normals. There is a problem currently. The lighting is
correct only when the terrain is at max detail. When less vertices, the normals are no more accurate. Now i understand why the
Gamasutra ROAM article used several Mip levels of the height map. Of course we can compute the normals at the lowest Lod level then
interpolate to the additional vertices (haven't done it yet).

To eliminate the gridspacing in the normal computation, i just normalize the nx and nz as a 2d vector ( div=sqrt(nx*nx+nz*nz); nx=nx/div ;
ny=ny/div; and take care when nx or ny are not zero , if so, you just avoid all the steps). So , normal={nx,1.0f,nz}, you must normalize it.


silkyslim:
Do you know haw to blit faster ?
I use 512x texture just for the testing of the blending function. I used the much bigger 2048x. But it's not detailed enough ...searching for
alternative (i have an idea ...but theory for now). Memory is an issue, even on my 64MB GeFOrce2 , that's why i don't use Render to
texture , the texture must have a Z buffer, even if i don't use it :(

Sebastian / TimeHunter:
I use the adaptive quad tree structure with geomipmaps. I read several articles, including the Gamasutra. I use / used methods from
different papers. My biggest problem was the cracks. I have spent some time to try different techniques, including the non geomipmaps.
My quad trees are actually stored in linear array. So, i avoid the 4x4byte pointer storage in each node. And that is lot of memory.

The geomipmaps. I use "patches" as a leaf in the quad tree. The size of the patches can be changed in a cfg file. They store the indices
of the vertices for the different LOD levels. The different LOD indices are computed by just skipping avery 2nd.... etc. vertex. The vertices
are stored in several Vertex Buffers (the patch keep pointer to the used buffer, and an BYTE for the used LOD) . Dx7 buffers can store
only 0xFFFF vertices ...one VB is not enough for terrain > 256x256.
These indices does not store the borders. There is different vars that store the 4 borders of every patch. I ensure that every neighbor
patch has the only level LOD difference on render. And i choose the appropriate border if difference or not. Lower LOD ensure to
connect to higher one (or the inverse , don't remember).

I traverse the quad tree and check every node against the view frustum (i use very bad test function). Every node has info about the max
height (actually an other linear stored quad tree).
The used LOD is computed from the distance, pre computed factor and a threshold value (called "quality factor").
The quality factor can be adjusted so, more details are shown on close distance , and it depends highly of the terrain type. The Grand
Canyon is a particularly popping case , and must use higher quality factor.

I know the Boom's article ...but i have trouble with any tech that uses more than one pass. Simply ...i have allergy ..there must be one
pass tech ..5 passes ..wow ...to much lost time. That not mean that's tech..but my brain have trouble with.

TimeHunter: Ask me for specific questions about quad trees ...If you just ask in general, go and read some articles. The Geomip map tech
is explained here : http://www.flipcode.com/tutorials/tut_geomipmaps.shtml . I exactly the same tech ...but anyway. There is a very good
article about quad trees on Gamasutra , much more other on the wild . I don't keep links ..i d/l the papers :(.


Now, i do research on better texturing technique, occlusion culling ... IF you have idea ..or you know good papers ... TELL me please.


Wow ...that's getting long ... to long. Never liked to write ...but from a year, i write really much, hmm.. must become a journalist ..? Naaaa

If you have more questions ...i'll be glad to answer to you in bad English

Oh ..i forgot ... i search a job in the game industry. Only ...i had not time to write my CV :-(

--
The Aero Section : http://fly.to/TheAeroSection/
The Aero Section is a large military aircraft photo gallery.

Errata:
3d card is not alive, i know (he)
haw=how

There is different vars that store the 4 borders of every patch. I ensure that every neighbor patch has only one level LOD difference on render. And i choose the appropriate border if there is difference or not (use the no difference border). Lower LOD ensure to
connect to higher one (or the inverse , don't remember).

I know the Boom's article ...but i have trouble with any tech that uses more than one pass. Simply ...i have allergy ..there must be one
pass tech ..5 passes ..wow ...to much lost time. That's not mean this is a bad tech..but my brain has trouble with.

The Geomip map tech is explained here : http://www.flipcode.com/tutorials/tut_geomipmaps.shtml . I don't use exactly the same tech ...but anyway.There is a very good
article about quad trees on Gamasutra , much more other in the wild .

Maybe i need to read my post, before actually posting ? To learn English is not bad idea either....

Hi dataman,

Thanks for your reply, but:

1. why do you need to mipmap? what's is the benefit of that? i understand that roam and terrain lod in general is cpu bound but i don't see why you should use a lod on the texture size? Is it because the vram is too small for all the textures to hold at once meaning that the driver has to get them from system memory (= slow)?
2. Thanks for the info on the components, i'll have to try it some time!

nkm

"the hole fill rate"

heheheheheh :)

Yet another terrain engine... I must get round to doing one.

Instead of doing one hires texture 1024x1024, how about 4 512x512 textures and then render the quad that that texture covers? That's how I'd do it anyway...

Yep. Must do that terrain engine...

Nice looking engine you've got there. As the author of the geomipmap paper I have to say that it's a very straight-forward technique and I have no doubt that people have come up with the same approach before (The paper was published well over a year after I came up with and implemented geomipmaps).

Anyway, if you want to get rid of edge creases (ie, neighbouring patches having different LoD's) and don't want to touch your general index buffer (remember only 1 index buffer is needed, since the layout for every terrain-chunk is the same. The single index buffer contains all the 4/8/16/etc LoD configurations. You just specify a ib range when you do a DrawIndexedPrimitive), use the flanges technique. It's very nice, in that it uses the z-buffer to sort out the union for you.

Anyway, nice look terrain.

...GeoMipMapping is an efficient, fast and flexible way or decreasing the amount of geometry to be rendered allowing greater detail and horizons at further distances than noraml while minimizing the amount of popping and other visualy artifacts in a contollable way.

That is my definination, explains all I think.

What can I say, its another terrain engine; looks like a an aerial photo or something -cool.

NeukuM:
We speak about geomipmaps and not texture mip maps. Willem called this way the technique of using different LOD terrain patches.

There are two main benefits of texture Mip maps.
If you have a box, that represent only... let's say 128x128 pixels on the screen (it's some units away from the camera). You don't need to
render this box with 512x512 texture ..when you can do it with 128x or similar.
1. The memory bandwidth. To "rasterize" 512x texture takes more time than 128x.
2. Visually it's better to draw 128x texture over 128x region. Bigger texture must be stretched and a visual artifacts are occurring (pixels
are dancing)

Of course... correct me if i am wrong.

Willem: Can you tell me more about the unique index list and the border solution .. please. What you understand under "ib range".

L.e.Denninger -
alternatively, 'A mathematician is a machine for turning coffee into theorems' (Paul Erdos)

NeukuM - read the geomipmaps tutorial... it's about the lod of the mesh and generating the midpoints rather than simply reducing the heightmap size.

I like the shot.