|
Author Topic:   ROAM/Tread Marks-type engine with source.
Bryan T
Member
posted April 04, 2000 04:35 PM            
My article finally made it out. It's on www.GamaSutra.com. Here are the pertinent links: http://www.gamasutra.com/features/20000403/turner_01.htm http://www.gamasutra.com/features/20000403/ROAMSimple.zip

I have dedicated this article to Seumas and his work. He was very encouraging and helpful while I was learning the algorithm. Unfortunately the editors decided 'Seumas' was the incorrect spelling and 'fixed' it for me, I will try to have this corrected.

I hope this project will help any newcomers to this board, the code was designed from the ground-up to be read by someone trying to learn the algorithm.

The honorarium for the article will also be donated to the fund in Seumas' honor.

--Bryan

IP:

malakai
New Member
posted April 06, 2000 12:07 PM            
I noticed alot of people intrested in ROAM on this board. Have you all had a look at Alex Pfaffe ROAM implementation at: http://www.oz.net/~ddg/

It has a merge and a split queue, and some other 'complicated' things. Just thought i'd FYI you all.

-malakai

IP:

jester
New Member
posted May 03, 2000 01:31 PM            
Hi,

I've been porting the ROAM implementation from your Gamasutra article and I've run into a problem and I was wondering if you have any ideas.

The recuse Tessellator generates a large (approx 50%) triangles which have no size ie the left, right and apex points all have the same coordinates. I don't know why this should be happening. Any ideas?

IP:

Bryan T
Member
posted May 03, 2000 01:39 PM            
Jester,

What is the depth of your tree at that point? And the size of the terrain?

If you keep tesselating too far down, you'll get triangles that have no size. This could be mitigated by using floats for the coordinates but then you get into CPU speed issues.

Make sure that you are not tesselating a 1024x1024 landscape any more than 13 levels deep. I think I actually stopped around 12 in the demo.

Let me know if this fixes it.
--Bryan

IP:

jester
New Member
posted May 04, 2000 02:39 PM            
Bryan,

Read your message, read my code, read your message, read my code.
Cried for a while.
Fixed my code, now it works.

I've just read the GDC paper from Jonathan Blow. I was really intrigued by the 'future work' and using techniques from wavelet enoding.

Did a quick search and found a program and associated files on something called 'Binary Tree Predictive Coding'. http://www.engr.mun.ca/~john/btpc.html
I've only glanced over it but it might be useful.

Have a look, you know more about the ROAMing stuff than I do.

Cheers for the help,
Jester.

IP:

Olly
New Member
posted May 11, 2000 04:25 PM            
hi there!
just in case anyones interested :
another ROAM-engine at
www.geminirealms.f2s.com

bye, olly

IP:

Blackscar
New Member
posted May 24, 2000 02:01 AM            
Hi Brian,

I was just wondering, how would you go about taking one texture and stretching it over the entire map? I've tried several things, but nothing seems to work. Could you please help me?

Justin Eslinger
(P.S) I emailed you the same question but was unsure if your email was the same. Not trying to be a nagger or anything.

IP:

Whirlwind
Member
posted May 25, 2000 12:17 PM            
Cool article. I was wondering about how to implement a terrain engine in a game engine for a demo I am writing for a contest and your article will help out greatly - probably with the post demo version of the engine, but it will still help .

I probably will ask a bunch of questions when I get around to adding tunnels/caves to the alogarithm. I am thinking of a seperate tree for the tunnel, or a branch.

IP:

Bryan T
Member
posted May 26, 2000 03:56 PM            
Blackscar,

You can set the texture generation coordinates to strech a texture over the entire landscape by moving the glBegin/glEnd calls up to the Render() level. This makes the auto texture coord generation occur in context for one texture. (May have to fuss with the auto texture generation vectors in Utilities.cpp too, I've not tried it myself)

Most games now are getting to the size such that this is no longer acceptable. Tread Marks used 64x64 patches each with their own texture. TRIBES 2 is using some really nifty texture LOD and procedural generation to get infinite levels of detail (as is Black&White). Again, not streching one texture over the landscape.

You should look into this before deciding on a single texture over the landscape.

--Bryan

IP:

Rob V
New Member
posted May 27, 2000 02:06 AM            
Hi all,

I've been looking at this roam stuff and particularly Bryan's article (Gama articles are so much easier to read than theory-heavy papers).
Anyways, I've been trying a few things with the demo in the article and have a few questions.
Firstly, is it possible to do the priority queue optimisations when the triangle coordinates are only known implicitly through the tree structure? (What I'm getting at is how do you make your split/merge decisions view dependent when you don't know the location of the triangle you are dealing with?) I am assuming that in the roam paper they store the coordinates somewhere, but they don't seem to mention it.
Also, assuming priority queues are used, is it possible to keep the error metric calculations to a proportionate number? The roam paper recalculates the error for every leaf triangle and Bryan's code calculates for every triangle in the whole tree on every frame. This seems really wasteful if only 1% of these will be split/merged.
I hope someone has some insight into these matters.
Rob V.

IP:

Blackscar(2)
New Member
posted May 27, 2000 04:04 AM         
Brian,

Thanks for the reply! I'm staying with my brother over the weekend so I won't be able to try it out. Anyhow, 64x64 patches? Would you do this by a data structure (1024x1024 which holds 1 = water, 2 = land, etc) and then put the appropriate texture on? Or would you see how high the z is and load the appropriate texture?

Thanks again,
Justin Eslinger

(sorry for making another account, I had registered at home and didn't copy my password oh well :P)


IP:

Blackscar(2)
New Member
posted May 30, 2000 01:20 AM         
AHH!! I get it now

Thanks alot Bryan!!!

I'm making a test game called "Mage's Rage" or "Mage Bash" or something of the sort. It will be a multi-player deathmatch of nothing but mages. I will post a link to the site after I get it going smoothly.

It will be using the ROAM technique that you had on Gamasutra. Thanks alot! I understand it alot better now.

Justin Eslinger
(Satified customer, heeheheh)

IP:

Bryan T
Member
posted June 06, 2000 02:23 PM            
Rob V,

I've not implemented a priority queue method with ROAM, but here's some info based on my experience with a quadtree method.

I kept the two-pass rendering, one pass for splitting, the other for rendering. During the initial split pass, I put everthign in a priority queue. Then each additional frame I decided if too much changed (in which case it would be faster to do a full tree traversal) otherwise I split and merged from the queue.

This caused the tree to be modified optimally, only checking nodes which are likely to have split or merged.

Now, the second pass was done just as it always was: a recursive traversal of the tree that rendered the leaf nodes.

ROAM does indeed store the vertex coordinates. I refuse to do this. I feel the implicit storage is the way to go, and it saves an incredible amount of space. The problem is that you're trading storage space for traversal time.

It is possible with large enough terrains that this traversal time is too much, and storing the vertexes would be worth it. (of course, with a large enough terrain, storing the vertexes may be impossible due to it's shear size)

--Bryan

IP:

amosl
New Member
posted June 13, 2000 03:38 AM            
Hi Bryan,

I am now writing a ROAM implementation for a scene-graph based engine using VisKit.
I planned to use the scene hirarchy to represent each square with a geometry node, and add a new node when a split is made. This approach gave me alot of trouble, since for each level the split is to 4 smaller quads, not one at a time like in your code.
It looks like there is a better way, only I can't figure it out.
Do you have any idea about representing terrain geometry in a scene graph ?

IP:

Oiler
Member
posted June 13, 2000 01:06 PM            
amosl,

Your in luck as I have already created a ROAM plugin using Viskit (I called it vkSector). What I did was derive from vkGeom. Then from my code I manipulate the vertex arrays in the vkGeom at run-time as you can change the lengths of these arrays as you please. Then everything is all encapsulated. All I have to do is put a vkSector in my scene give it a height map file(If I dont it creates a fractal)and the rest is handled by the vkSector. Then there is no need to micro-manage many nodes in the scene.

If you have any more questions don't hesitate to ask as the viskit docs are a little thin.

IP: