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


Submitted by dataman, posted on June 11, 2001




Image Description, by dataman



Just another terrain engine.

Nothing special to say for now ... only that is adaptive quad tree based and it uses the "GeoMipMap" technique (done several months before the white paper with the same name). I use DX vertex buffers to store the patches. They are stored in a special way, so the rendering performance does not suffer much on cards without T&L . You can see the dynamic lighting. I use the method presented by Klaus Hartmann ("Texture Synthesis for Terrain" paper) to generate the vertex normals (however, i modified it, so the grid spacing is no more needed).

The texture is dynamically generated. I use the hardware to blend the different base textures. The terrain does not look so good (detailed) if close to it. The problem is the texture size (512x512). I am working on that problem. In the previous versions, i used a software blender (sampler), but it was slow (30 sec for 2048x texture). Now, the problem is the Blt operation needed to copy the blended texture from the back buffer to the texture surface. It's very slow (~1.3 seconds). Rendering to texture is not really an option, textures use to much memory. I spent months searching for good texturing solution (big terrain + detailed texture + LOD terrain support), but no luck for now. If you can help me in this domain, don't hesitate. .... oh, i use detailed texture too (not on the screen shot), but it's slows the frame rate as much as 50% (single pass multitexturing). Maybe, it's because i use the hole fill rate and any additional operations impacts the performance.

Speaking performance, here some info : the current screen was taken with the terrain with full detail (the Hmap is the Grand Canyon 513x513 from Gamasutra ROAM article), 524288 triangles , directional light, 32 bit , resolution ~900x640 (windowed, but same performance with 1024x768) = 15 fps. But, there is no optimizations, i use borland VCL, many controls , and the program is full with other stuff (garbage, or not so).

My system is an overclocked celeron 300a ->450 , GeForce2 GTS 64MB ,196MB RAM.

I know, there is no sky. Do i need it really ? Yea, sure ..but later ...

If you have questions ..don't hesitate.


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

June 11, 2001, 02:29 PM

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

 
NeukuM

June 11, 2001, 02:32 PM

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

 
TimeHunter

June 11, 2001, 02:38 PM

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

 
silkyslim

June 11, 2001, 02:43 PM

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!

 
R. van Wijnen

June 11, 2001, 03:57 PM

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.

 
Revolver

June 11, 2001, 05:27 PM

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.

 
Sebastian Sylvan

June 11, 2001, 05:33 PM

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

 
Steve 'Sly' Williams

June 11, 2001, 06:46 PM

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.

 
d@t@m@n

June 11, 2001, 08:18 PM

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.

 
d@t@m@n

June 11, 2001, 08:34 PM

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

 
NeukuM

June 12, 2001, 02:51 AM

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

 
L.e.Denninger

June 12, 2001, 05:06 AM

"the hole fill rate"

heheheheheh :)

 
Mournblade

June 12, 2001, 06:22 AM

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

 
Willem

June 12, 2001, 08:10 AM

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.

 
D.P.

June 12, 2001, 08:36 AM

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


 
d@t@m@n

June 12, 2001, 01:52 PM

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

 
Nexus

June 12, 2001, 03:02 PM

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.

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