• Advertisement


This topic is now archived and is closed to further replies.


This topic is 5451 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Has any one tried to code ROAM into DX9 or any DX API? If so.... How did it work? What language were you using? What externals were included? What vid cards did you test it on? Did you optmize the original algo in any way? How do you like your eggs? Sunny side up or over easy? Which came first, chicken or egg? How can I stop typing in question form? Can you help me? Can someone come take my keyboard from under my fingers? Would you like me to go on? Is Saddam really dead? Where is Rancho Cucamonga? Troy Larson Programmer/ Writer/ Level Design Wicked Sky Software

Share this post

Link to post
Share on other sites
No, I haven't seen a ROAM engine coded in DirectX yet. I actually had a hard time finding any terrains coded in DirectX (aside from simple brute force). Everything is OpenGL. It would seem, DirectX coders are more stingy with their code. Or maybe it's just that DirectX is a less mature API. There is a DirectX engine in one of the Programming Gems books (2 I think), but it is more like brute force than ROAM.

I initially looked at ROAM when I started building my demo terrain but I opted for a partial quadtree Rottger implementation instead. ROAM is very CPU intensive which is growing more and more taboo. The MO these days is to get heaps of polygons to the video card as quickly as possible. In Trent Pollack's book, Focus on Terrain Programming, he talks about a ROAM 2 which is supposed to be more processor friendly, but I don't think the whitepaper has been released yet. Also, ROAM relies on triangle fans which don't work well in DirectX (due to limitations on VertexBuffers).

It could definitely be done, I'm just not sure it would be worth the effort (at least from a practical POV). After spending all this time working on my Rottger, I'll probably opt for something closer to brute force when I get ready to start my engine.

If you build a ROAM, I'd love to see the code. If you want to see my directX Rottger, my most recent code is in my CVS. Keep in mind, though, this is really rough demo code (for the sole purpose of learning).

bpopp (bpopp.net)

[edited by - bpopp on April 21, 2003 11:48:09 AM]

Share this post

Link to post
Share on other sites
Original post by bpopp
...he talks about a ROAM 2 which is supposed to be more processor friendly, but I don't think the whitepaper has been released yet.

Ignoring the DirectX vs. OpenGL bullshit, here's the ROAM2 page:


It _is_ more processor friendly, and somebody on another forum who has a Radeon 9700 (*sniff* *sniff*) has clocked the demo app approaching closely the Radeon's theoritical triangle throughput.

PS. I brute-force, too.

[edited by - Assen on April 21, 2003 12:29:42 PM]

Share this post

Link to post
Share on other sites
I have done Roam under DirectX 9 and C++.

> How did it work?

There are a few articles on this, and I mostly followed them the ones I went off were the ones on www.gamasutra.com, and www.flipcode.com, and Los Alamos Laboratory Article (see below). Although they address some of the issues they didn''t address what was the most challenging thing, which was the ability attach ''atches'' to already built patches without getting holes in terrain. Being able to do this without rebuilding all the patches involved was kind of tough to achieve, but not certainly not impossible.

As far as DX9 I wanted to just get my algorithm to work, and I just had allocated a vb of a set size for each patch and then had went through all the leafs and wrote them to the vb, then rendered; this is not most efficient but my goal was not that.

As far as heightmapping I had used Bezier patches unlike height maps, reasoning is simple, there is no big differences except that I wanted to work with Bezier patches, rather than bitmaps. Although bitmaps are a better choice if you want to be able to easily define your terrain. (These things are trivial)

> What language were you using?

C/C++. DirectX.

> What externals were included?


> What vid cards did you test it on?

My laptop Geforce 4 MX Go, Geforce 4 MX, ATI Radeon 9700 Pro.

> Did you optmize the original algo in any way?

As I said I had to implement "attachments" as in the ability to re-attach patches as if when the character is moving about an infinite world, unless you want a static terrain level for stuff like FPS games (where the world is static) or do it like Morrowind. It''s not an optimization as it is a much needed feature in some types of games. Also for me it is hard to understand your concept of the "original algo." Although in my implementation I had used:

- Node memory manager
- A not too fancy variance calculation
- Had used some but not overly a lot of recrusiveness

Some articles are:

But before looking at ROAM you may want to look at other terrain algorithms, for instance I''ve heard that ROAM is not really the best for some things; and likely the best choice is specialized. I wish I remmember where that article was that critisized ROAM; but I can''t find it atm.

Homepage: http://students.washington.edu/andrey

Share this post

Link to post
Share on other sites

  • Advertisement