|
Author Topic:   Quadtree/ROAM Program w/source released
Chris C
Member
posted November 25, 1999 03:45 PM         
Hi,

I've decide to release my implementation of a continuous level of detail terrain/heightfield renderer that uses both a top-down quadtree based algorithm and an implementation of the frame-coherent ROAM (Real-Time Optimally Adapting Mesh) algorithm, allowing you to flip between the two to compare them.

Be warned that the source is a bit on the messy side (particularly the ROAM parts), but it's quite liberally commented so I hope it might be possible for someone to learn something from it!

The source includes routines for view-frustum culling and efficient priority queues which may also be of interest.

You can find more details and the download at:
http://www.dcs.warwick.ac.uk/~csuhm/downloads.html

I hope someone finds this useful,

Cheers,
Chris

IP:

Cthulhu
Member
posted December 02, 1999 05:34 AM            
This is what I got:

You do not have permission to access the item you requested (http://www.dcs.warwick.ac.uk/~csuhm/downloads.html).

This may be because the item is only available to users within the University or sometimes because the owner has temporarily removed access rights.

IP:

MarkBatten
Member
posted December 02, 1999 08:36 AM            
Well, I was able to download it, so I'd say try again. There doesn't seem to be any general limitation.

IP:

Chris C
Member
posted December 03, 1999 08:03 AM         
Hi,

You may have caught me updating the page..! I have checked that you can download the file/access the pages outside of the university network, so I don't think that would have been the problem.

Cheers,
Chris

IP:

Chris C
Member
posted December 03, 1999 10:08 AM         
Whoops!

I've discovered that after updating the page I forgot to set the access rights... Sorry! It should be fixed now.

Chris

IP:

Cthulhu
Member
posted December 04, 1999 11:24 AM            
Works now.

IP:

bdiscoe
Member
posted January 02, 2000 06:07 PM            
I downloaded the source code today and tried to build it under MS Visual C++ 6.

The only tricky points were the two LCC-specific functions used (_bsf and _rdtsc). I replaced _bsf with a small C function and _rdtsc with the Win32 function timeGetTime().

After fixing a small bug and some compiler errors (use of reserved words 'near' and 'far'), it does build and run.

However, it doesn't run very well... in QUADTREE_MODE, all i see is a close-up view of a couple faces, spinning. In ROAM_MODE, a wireframe view renders for a few seconds, then the program dies in roamAllocateTri() (runs out of triangle stack space).

Has anyone had better luck with it?

IP:

LDA Seumas
unregistered
posted January 03, 2000 04:36 AM           
This might not apply in this situation, and it's just a gut feeling I have, but you might want to be very careful when replacing RDTSC with timeGetTime(). The reason is that (AFAIK) the RDTSC assembly instruction returns ticks of the processor's clock, so e.g. 600,000,000 ticks per second on a 600mhz machine. timeGetTime() returns milliseconds, so only 1,000 ticks per second. This being a difference of over 5 orders of magnitude, it may screw up timing code if you simply replace one with the other.

My apologies in advance if this was taken into consideration already, but I thought I'd mention it (on behalf of my gut) just in case.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

bdiscoe
Member
posted January 03, 2000 05:53 AM            
> you might want to be very careful when
> replacing RDTSC with timeGetTime()

Yeah, timeGetTime() returns milliseconds, so i just changed the code to divide by 1000.0f instead of 2e8 which isn't my clock frequency anyway Also, i don't think MSVC support 64-bit ints (barfed at "long long"). Fortunately, Cookson was only using RDTSC for time reporting, not for actual use in the algorithm.

-Ben

IP:

bdiscoe
Member
posted January 03, 2000 05:56 AM            
BTW, i spent more time working on Cookson's code, fixing a few bugs and uninitialized values, and now it actually renders both the Roettger and ROAM algorithms correctly! Just in case anyone wants to spare themselves the same labor, i'd be happy to send it.

-Ben

IP:

MarkBatten
Member
posted January 03, 2000 09:07 AM            
Now that it's working, what's the performance like?

IP:

bdiscoe
Member
posted January 03, 2000 04:46 PM            
Well, it's a little hard to tell performance because i have a fast machine, and Cookson chose a rather small dataset (513*513). Basically, it's instantaneous. I plan to try to bring his code into my Terrain library framework to do a real side-by-side comparison with other algorithms on larger datasets.

-Ben

IP:

Chris C
Member
posted January 10, 2000 10:20 AM         
Sorry to hear about the compile problems and bugs, although they are not unexpected! Sigh, if I was going to write it again today, I'd do it all so differently...

If Ben could send me his changed source, I'll put a patched up version for download, which should prevent people from any more painful experiences.

I haven't the time to do much more work on the source - I'm aiming to develop a hybrid algorithm from what I've learnt implementing this little project, in my spare time instead.

Cheers,
Chris

IP:

Chris C
Member
posted January 19, 2000 09:09 PM         
I've put up a new version of the source for download - it now compiles under MSVC++ (tested with v6), has various bugfixes and has been tidied up a little!

There should be no problems compiling as long as you've got the GLUT dll's, headers and libs, so you can tweak it with ease.

You can download the new release at http://www.dcs.warwick.ac.uk/~csuhm/downloads.html

Cheers,

Chris

IP: