a terrain question

It depends on how you implement it. I doubt that Microsoft''s PMesh implementation is top notch (from the rest of D3DX), although it is better than Roam in concept. Personally I think it is rewarding to make something of your own kind . Ideally, I would implement PMeshes by myself , it be something fun for me to do hehe.

-------
"Programming is like sex make one mistake, and you have to support it forever."
Homepage: http://students.washington.edu/andrey

The advantage of the CLOD or ROAM would have to be big enough to make me start exploring the incredibly complicated CLOD

[edited by - malyskolacek on August 5, 2002 9:46:11 AM]

There was actually a featured article here on gamedev analysing this exact question, so i suggest you check it out
I think it was called "The second life of brute-force terrain mapping" or something like that.


--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.

brute force techniques suck bigtime.
only the most fastest cards can acually render a brute force terrain with a good fps.

i too made a quadtree terrain. but i used opengl and used ROAM. what a coincidence.

what is a progressive mesh? i am not too familliar with d3dx.

Its my duty, to please that booty ! - John Shaft

Actually, bruteforcing works very well most of the time, it all comes down to how accurate your culling is.
And progressive meshes aren''t D3D-specific in any way, they''re meshes with different LODs.
Read the article i posted about to get some accurate info on pros and cons of bruteforcing.


--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.

The current issue of game developer magazine talks about LOD techniques as well...

Never say never...

There is a similar discussion going on in the graphics programming forum.

I think it is a bit naive to say one algorithm is better than the other. Each are suitable for different situations. For a first person or third person game where you can see in to the far distance and the horizon, it is (for now anyway) impractical to use brute force simply because of the sheer number of trianlges which will be visible. Plus the fact that far trinagles are not contributing to the final image and might as well be used somewhere else (models?)

On the other hand using CLOD and ROAM for RPGs or RTSs where you really can''t see so much into the distance but usually a fixed area around the player, is silly. Examples of this is could be Dungeon Siege or WC3. There are a few reasons 1)most of the visible patches would be at the same level of detail 2)The camera is relatively close to the player and therefore his/her surrounding terrain. ie you want to show as as much detail as possible and 3)Since the number patches that are visible at one time is more or less a constant, by using brute force we are able to render the patches as long strips which believe you me, is very very fast.

Please note that I base these observation on personal experiments. I have writte both a ROAMing engine and a brute force one. My finding is RAOM is really required for first person games, but brute force method is faster and more logical for a third-person/limited view game

Thanks

My CLOD implementation was smacked around by my current brute force implmentation, and the CLOD wasnt even textured, while the brute force is multi-textured, with a second layer for terrain shadows. And this is on a p3 500.

Z.

It is true that at some point sending vertices will be faster than processing them (in CLOD). Nowadays the problem is still sort of in bandwidth, but is quickly shifting to other things. It is unsafe to brute force, but maybe sometime it will be used. It depends on whether bandwidth will start becoming an issue again.

-------
"Programming is like sex make one mistake, and you have to support it forever."
Homepage: http://students.washington.edu/andrey

malyskolacek: How many polys are you drawing per frame to get such a high fps? Plus what''s this in DX9 you mentioned?

---

Read about my game, project #1
NEW (7th August): demo #3 is now released, with a new screenshot.

---

John 3:16

Brute force is the worst way to render terrain. I am using the following algorithm: I pick a starting point, I push it in a queue. Then for each point in the queue I test it''s visibility. If it''s visible, I draw it and push it''s 4 (or 8) neighbours in the queue. The algorithm stops when I don''t have any more points in the queue. It can be improved: don''t push a new point in the queue if it is farther than a certain limit.
For me it works just fine...

Hi again

I think some of us maybe confused about the actual meaning of brute force. In my understanding ( emphasis on ''my'' ):

brute force does *NOT* mean that you render the whole terrain every frame. It just means that you render the terrain at a fixed level of detail (which would possibly be the resolution of your heightmap.)

ANY sensible terrain algorithm (whether brute force or CLOD or something else) would in some way subdivide the terrain information in order to do frustum and other sorts of culling. And in anycase you need to subdivide the terrain into patches otherwise texturing will become very hard, if not impossible. So just because a brute force algorithm is used, it does not mean that the invisible portions of the terrain is rendered.

Sorry if I just stated the obvious.
Thanks

That''s correct Poya. Bruteforcing does NOT mean you draw every tri...

--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.

And then, the patches can have progressive meshes (LOD''s) that are "precomputed" and rarely changed. Another brute force.

Should be pretty efficient - actually I am trying this out right now.

Regards

Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)