Re: [Algorithms] ROAM
Brought to you by:
vexxed72
From: Lucas A. <ack...@ll...> - 2002-07-31 20:17:33
|
Hi Trent, I'd have trouble taking seriously a book about 3D terrain programming that didn't cover ROAM in some reasonable depth. I admit it isn't likely to teach me much (since I work with Mark), but between ROAM's adaptivity, flexibility, and scalability (not to mention the elegance of the core concepts, and the ease of generalizing it to non-terrain and arbitrary topology surfaces), it really is an important topic. ROAM does unfortunately get a reputation for being difficult to impliment well and tune for high performance, but this is due to the lack of good public implimentations (which will certainly change in the future), and is something you could certainly contribute to if your implimentation is widely read and good enough to set a de-facto standard. Discussion of ROAM derivitives (such as Lindstrom&Pascucci's "Large Terrain Vis Made Easy") and implimentation alternatives (like the prior mentioned output-chunking methods) can also help raise the bar both performance and ease-of-use wise. Good luck with your book, -Lucas Trent Polack wrote: >I was just sitting here, in the middle of coding the ROAM implementation for >my "Focus on 3D Terrain Programming" book for Premier Press. Now, the book >is all about terrain, but focuses more on its applications to game >development than anything else... Which leads me into my question. I have >three main algorithm chapters in the book: > >Chapter 5: Geomipmapping. The algorithm is very GPU-friendly, simple to >implement, and just generally a very good CLOD algorithm. > >Chapter 6: Stefan Roetgger's Quadtree algorithm. While it is far more >CPU-intensive than geomipmapping, this algorithm is a bit more balanced and >"powerful" than geomipmapping. What it lacks in speed, it makes up for in >mesh consistancy and detail. > >Now, chapter 7 is where the dilemma is. I could teach the reader all about >ROAM, but I'm wondering if I should really bother. Its a great algorithm, >and I do not doubt its power, but I really do think its lacking in speed, at >least compared to the previously mentioned algorithms. > >Now, what I was thinking, was that in Chapter 7 I could write about several >different approaches to making a very fast and stable terrain engine, such >as some variations on the geomipmapping algorithm discussed in Chapter 5. >But, I really need some opinions here (Plus, I've been writing almost >constantly for the last three days, and my thought process seems to be >rather broken.), what do you guys think? > >------- >Trent Polack >tr...@vo... >Thought of a lifetime: "NARF!" > > > |