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

Submitted by Eric, posted on February 14, 2001

Image Description, by Eric

This is a screenshot of my landscape engine. I decided to post this in response to a previous IOTD posting, where the submitter commented on the fact that it's the quality of the texture mapping which makes or breaks a landscape engine.

My landscape engine only has a simple static binary triangle tree LOD system, much like ROAM but without the dynamic LOD depending on how far away the particular part of the landscape is. It may seem pointless to have LOD which doesn't depend on distance, but I wasn't happy with the idea of the landscape morphing around before your eyes as you move across it. Also the WHOLE landscape is drawn every frame, so I needed some way of reducing the detail in large flat areas of land (this is shown in the corner). One final advantage is that you can specify how many triangles you want the landscape to consist of and the LOD system does that, within about 10 triangles.


Image of the Day Gallery


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

February 14, 2001, 06:41 PM

yet. The operative word here is "yet".

A few years ago, the majority of computer users didn't have a 3D card at all. Besides, how many people posting to this list are making games for the majority of users? They're making games (if not just an engine only, or something else entirely) for themselves, and people like them (i.e. the rest of us posting to this list) I'd say it would be a fair majority of the people here who have a T&L card.

Anyway, why does optimizing for T&L ignore the non-T&L people? It still works just as well on their cards - just not as fast as on a T&L card, and isn't that the point of T&L anyway?

Brebion flavien

February 14, 2001, 08:46 PM

It's not the first time someone uses Terragen texturing for their landscapes, so i gotta ask... does anyone know what algorithm Terragen is using ?


February 14, 2001, 08:53 PM

Well, depending on how you architect your engine, you can support both TnL and non-TnL users - for instance, in a terrain engine your quadtree might have staggered leafs. That is, at one fairly granular level you have leaf VB data usable with TnL cards, and down a few levels you also have pointers to the data, ready for use with a CLOD algorithm.

Also, to get maximum efficiency with TnL, you need to send it fairly large VBs - if you did this with a non-TnL card, your system would be veritably overloaded. In Q3A or UT, if you've ever used NOCLIP to step outside a level boundary (or collision screwed up and let you fall through), you probably noticed how the framerate all but died - this is because too many polygons were visible at once, and with the combination of software vertex processing and non-TnL hardware, the system couldn't keep up.

An interesting thing to think about is, given that Q3A levels have fairly low polygon counts, you could actually render a whole level using a single VB and TnL at the same or better framerate than you would get with the hardcore BSP VSD that it does. Interesting huh? But this isn't an excuse to get lazy. We need to keep the BSPs (or whatever VSD you use), but at the same time maximize TnL by including much, much more detail in our worlds. I suppose it's a double-edged sword for level designers - more creative freedom, but also a lot more time consuming.

Indeed, EVERYONE may not have a TnL card, but it wont be long before the market is sufficiently saturated so that TnL-only games are viable. I've talked to numerous industry people, and everyone seems to agree: a game that is just now starting production (i.e., has a projected completion in 1.5-2.5 years) is fine candidate for being TnL only. GeForce1 cards are now DIRT CHEAP, and have great performance (I get 14.4 million triangles per second on my P3-933/GeForce1), GeForce2MX's are quite cheap and Radeon32's have a great price as well. Radeon64s and GeForce2's have sold extremely well in the hardcore market.

Another thing to consider is that GOOD games with heavy system requirements (Q3A, UT) drive hardware sales. That's another discussion entirely though.

So, when we see TnL-only? Soon. Very soon.


February 14, 2001, 10:01 PM

Terragen is a raytracer. It generates it's heightfields using 1 of several available choices, mostly based on Perlin Noise.

to download it. It's free, beta 0.8 is the newest version, and it's currently on hiatus because the author got a Real Job because of it.



February 14, 2001, 10:05 PM

Not touching the vertices is still a good idea for non TnL as well. And, anything computationally intensive is also a no no. ROAM is more loss than gain even on a Non TnL card. So are most schemes which touch vertices directly.


February 14, 2001, 10:09 PM

Thems MY nick initials. Fighting actions!

J/k :) Glad there is another person people can call DP and get confused about.


February 14, 2001, 11:32 PM

Did you say you are rendering the entire landscape? Why praytell?
I think this is an ok landscape, but nothing spectacular. And the reason I say this is not to sound cruel or demeaning. I don't particuliarly agree with your point of view on textures making the world of difference. In fact, textures have nothing to do with the engine. The fact is that you are rendering this entire(relatively small) plot of landscape out. This may be fine when your heightmap data is 64x64 but when you have an expansive landscape that is suitable for playing somehting other than streetfighter, you will have to make leaps and bounds in the area of LOD.


February 15, 2001, 12:08 AM

Does static LOD lead to considerable frame rate variation (due to big contrast between flat & hilly areas)?

CLOD complicates everything and can look terrible, but it does give nice & steady framerate (in my experience, on non-TnL cards).

Remember when Michael Abrash said software quake traded off speed against consistent framerate? Is this at all similar to no LOD, static LOD, CLOD?


February 15, 2001, 04:28 AM

Hosing the card with tris???

How well does this scale to distances? Has anyone got screenshots with distant mountains in them which this kind of scheme? (Not sarcasm).

Faster hardware is making the code simpler but I still can't see a way of getting solid geometrical distant mountains without CLOD (though I've love to hear idea's about how I might do that)

Any idea's?



February 15, 2001, 05:51 AM

This is the way i'm working.

Subdivide your big terrain into 32x32 patches (or 16x16, etc...). For each of these patches you have 5 levels of detail (from 1x1 to 32x32). For each level of detail precalculate the IndexBuffer with strips in a cache friendly way. You have to precalculate the cases where patches of diferent LOD are joined (joint patches).

So, for each frame:

1. Use yor quadtree to reach the leaf inside the frustum.
2. For each visible leaf, choose the LOD. Load vertices into your dynamic VB. Render the strips....

And so on...

On PII350 GeForce1 i'm getting a trouhput of 5 millions/sg with a grid of 1024x1024.

Actually i'm working in Oclusion Culling for terrains. I'd like to meet other people working on this.

I expect to show shots of my demo here soonly.

Phil Carlisle

February 15, 2001, 06:27 AM

I agree completely with Eric, that basically, ROAM pops too much to look nice if you do it dynamically. Having said that, static LOD needs to be done in some way, and OAM (after all its not realtime anymore) is as good as most.

If you generate strips/fans, and optimise those for the vertex cache, you should be somewhere near correct.

On the point about consistant framerates, you can simply triangulate down to n triangles per patch (assuming a 32x32 patch size) with roam, then store these as static data in compiled vertex arrays (or vertex buffers). I like ROAM because it fixes the T cracking, so I'd consider using it for exactly the same reason Eric is. Either that or go for the system Willem uses in his geo-mip-mapping.

I dont quite understand the non-culling though Eric. Are you using a single ROAM based buffer? or patches? if so, why not cull the patches with a quadtree? (actually, I am starting to dislike the quadtree's because of the inconsistant framerate).

Nice shot anyway.


Alex J. Champandard

February 15, 2001, 07:25 AM

> Terragen is a raytracer.

But not really... it uses polies. Shame really.


February 15, 2001, 07:26 AM

i see you create the terrain texture with terragen right?
but do you create a single texture and just texture it over the entir terrain or what? how do u do that?


February 15, 2001, 07:36 AM

Terragen? how did you made terragen export its textures?
I was triying it, too, but with no result.


February 15, 2001, 08:24 AM

I thik this, too.
I made very bad experiences with lod techniqes modifying the vertexes/mesh topology ... the fastest algoritm is the algorithm, which does nothing!

I use in my landscape-engine small boxes, with precomputes meshes.
I posted a pictures some time ago, whith this landscape. I have a voodoo3 and a K6II-500 the landscape is runnig at 50 fps and I can look very far.

I think precomputed lod is much faster the dynamical generated one.
(the only problem are "gaps" between single patches, but ist is not a big problem to solve (dynamic lod can be used here- a very fast special case))

I have 2 texture-units in my card -> I can do 1 texture and 1 lightmap at se same time (per vertex lighting looks crumpy, because of static lod!) use "uniqe" textures!! how many bocks can yo see at the same time ? 12,25,50 ? what are 50 textures in the texture buffer! not much! simply use a cache for the blocks you can see.
It is very fast!


February 15, 2001, 09:49 AM

Here are thoughts on how I am implementing terrain:

- 32x32 patches of height.
- Organized in a quadtree for culling. The quadtree will be 3d bounding boxes though (meaning I throw in y as well).
- Use OAM, static rtin, whatever the hell it is called to remove unessecary detail.
- standard frustum and far clip culling (I want fog in because I think it does look realistic at a distance, a far distance ).
- I am thinking of ray-tracing to the quadtree cubes to determine visibility. This should provide a good, dynamic occulsion method. And as it is a quadtree, you should be able to cull large portions of hidden patches quickly.

watcha think?

Jonas Risbrandt

February 15, 2001, 10:48 AM

I am using Willems method and I am very pleased with the results so far.
I store the vertex data in 33x33 patches. Then I store indices for an arbitary patch and its different lods (the geo-mip-maps) im my terrain class an re-uses them for all the patches. Ofcourse its all in vertex arrrays and then redered with tri-strips and tri-fans (for crack-fixing).

I think that crack-fixing was not a big problem. The only problem I have now is collision detection and raytracing to the sun (for the flare effect) since I don't store any triangles at all. But I'm working on that part :)


February 15, 2001, 09:38 PM

Actually, after a brief period of hating it, I like the ROAM algrithm. Sure, you have to recalculate the vertex list every frame, but in return you get CLOD. Which looks really great as long as you keep the error


February 15, 2001, 10:05 PM

You shouldnt have an inconsistant framerate using quadtrees. Perhaps you are not implementing them correctly?


February 16, 2001, 02:57 PM

A simple alternative is to have several precalculated LOD height maps. This is quick and simple and allows lowend user and highend users good playable options.


February 21, 2001, 06:20 AM

Does anyone know who posted this image...? :-)

This thread contains 51 messages.
First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.