ROAM article -- terrain
Author
Hello, during the summer I worked on a terrain demo, with water, particle engine, sky, etc... that incorporated "everything" but a LOD algorithm. The code was mainly mine, and because of this it made me feel quite proud having programmed the apllication, for the most part. I am currently thinking and starting to write a new terrain engine/demo, but with much code based on the following article - http://www.gamasutra.com/features/20000403/turner_pfv.htm
My question is, have any of you ever used a large amount of code to base yours off of, such as this? I could never, atleast at the time being create my own implementation of the ROAM algorithm. I plan on using the ROAM implementation code, and hopefully further enhancing it, as I go along. Sorry for the ramble, I''m just curious to here some insight into this topic.
I''m working from the same article, it''s pretty good. It took me a while though before i really understood the whole ROAM algorithm.
As for the code; i just look at it, or change stuff and see what happens, etc. I don''t just want to copy/paste the code into my "engine", i really want to understand what''s happening and then write my own. I wouldn''t feel half as "proud" if i just copied it. And you got something to show-off to your friends.....;-) "LOOK! *I* wrote this !!!"
If you are gonna copy it, make sure you understand it. It''s not cool to have a big chunk of code in your engine of which you know nothing about.
I''d really like to see a demo when it''s finished ............
Crawl
----------------------------
"Quotes are cool" - Me
Check out my game Asteroidz, it rules !!!
As for the code; i just look at it, or change stuff and see what happens, etc. I don''t just want to copy/paste the code into my "engine", i really want to understand what''s happening and then write my own. I wouldn''t feel half as "proud" if i just copied it. And you got something to show-off to your friends.....;-) "LOOK! *I* wrote this !!!"
If you are gonna copy it, make sure you understand it. It''s not cool to have a big chunk of code in your engine of which you know nothing about.
I''d really like to see a demo when it''s finished ............
Crawl
----------------------------
"Quotes are cool" - Me
Check out my game Asteroidz, it rules !!!
Author
I understand the concept behind each and every function used within the ROAM implementation, but I do not see many other ways of re-writing the code. I know of certain sections, where I could increase the speed of the code, change the method of drawing, etc...but, I seriously doubt I could create and implement the ROAM algorithm, without being able to mainly base it upon the code presented in the article. My original terrain demo screenshots can be viewed at
http://www.geocities.com/tryforfulluse/water_lil_jpg.jpg
http://www.geocities.com/tryforfulluse/terrain_green_jpg.jpg
http://www.geocities.com/tryforfulluse/terrain_giant_jpg.jpg
http://www.geocities.com/tryforfulluse/terrain2_jpg.jpg
http://www.geocities.com/tryforfulluse/paradise_island.jpg
Thanks for replying.
http://www.geocities.com/tryforfulluse/water_lil_jpg.jpg
http://www.geocities.com/tryforfulluse/terrain_green_jpg.jpg
http://www.geocities.com/tryforfulluse/terrain_giant_jpg.jpg
http://www.geocities.com/tryforfulluse/terrain2_jpg.jpg
http://www.geocities.com/tryforfulluse/paradise_island.jpg
Thanks for replying.
Conventional wisdom is that triangle level optimization like ROAM will not help performance on current video cards; it will actually degrade performance. Since the terrain is constantly being recalculated, the whole thing has to be resent to the card every frame. Instead, you should use object level culling and level of detail, since the geometry can be precalculated and stored on card. Then all you have to send is which object you want drawn. Consider dividing the terrain into patches with multiple levels of detail instead. Of course if you just want to learn ROAM out of curiosity, ignore what I just said.
see the optimization articles on the nVidia developer website, like page 20 of:
http://developer.nvidia.com/docs/IO/1369/ATT/Hardware_TnL.pdf
see the optimization articles on the nVidia developer website, like page 20 of:
http://developer.nvidia.com/docs/IO/1369/ATT/Hardware_TnL.pdf
My "brute-force" terrain tests were pretty fast but i always believed it could be faster....
I've actually done this... but you get cracks in the terrain. And because your not slowly tesselating(spell-check) traingle by triangle but huge chunks of traingles you get really ugly pop-ups. I got the idea out of a dutch article named "Geo Mip-Maps"....
GEO MIP-MAPS (or whatever): www.geocities.com/reversepopculture/terrain.zip
Still in DirectX (i've been converted to OpenGL not long ago). The texture routine is crappy, the controls too. It was just a test to see if my terrain routine worked.
EDIT: The link to the zip file didn't work right.....
----------------------------
"Quotes are cool" - Me
Check out my game Asteroidz, it rules !!!
[edited by - Crawl on March 22, 2002 3:00:09 PM]
quote:Original post by invective
Consider dividing the terrain into patches with multiple levels of detail instead.
I've actually done this... but you get cracks in the terrain. And because your not slowly tesselating(spell-check) traingle by triangle but huge chunks of traingles you get really ugly pop-ups. I got the idea out of a dutch article named "Geo Mip-Maps"....
GEO MIP-MAPS (or whatever): www.geocities.com/reversepopculture/terrain.zip
Still in DirectX (i've been converted to OpenGL not long ago). The texture routine is crappy, the controls too. It was just a test to see if my terrain routine worked.
EDIT: The link to the zip file didn't work right.....
----------------------------
"Quotes are cool" - Me
Check out my game Asteroidz, it rules !!!
[edited by - Crawl on March 22, 2002 3:00:09 PM]
quote:Original post by invective
Conventional wisdom is that triangle level optimization like ROAM will not help performance on current video cards; it will actually degrade performance. Since the terrain is constantly being recalculated, the whole thing has to be resent to the card every frame. Instead, you should use object level culling and level of detail, since the geometry can be precalculated and stored on card. Then all you have to send is which object you want drawn. Consider dividing the terrain into patches with multiple levels of detail instead. Of course if you just want to learn ROAM out of curiosity, ignore what I just said.
For terrain sizes commonly used in games (that is, poorly detailed), maybe. Flight simulators or other applications with larger and/or more detailed terrain definately see an improvment, on video hardware much more impressive than anything consumer''s use.
ROAM isn''t an obsolete algorithm, not yet anyway.
masterg - Your terrian demo looks awesome. I''m pretty new to this stuff but I want to be able to build terrians like that and have been reading over all the tutorials I can find. I have a question though..
Do you ever go into your terrains as a little object and move around them as if it was a large world? That''s what I want to do.
Do you ever go into your terrains as a little object and move around them as if it was a large world? That''s what I want to do.
Author
Thankyou for all the information you (all of you) have shared with me. I am reading the Nvidia pdf file as of now, and will look into dividing the terrain into sections with different LOD''s; but, i plan on developing atleast 1 terrain engine using the ROAM algorithm, because of the amount of reading I have done on it, it would seem a waste not to.
mr2071: Thank you for your comment, that terrain demo I wrote during our summer
( I havent done much programming for a while, getting back into it) It is one rendered heightmap, that I allow the user to interact with, by using some crap collision detection. I have lost the source code & latest version of the application, but here is one version I found if you care to look at it http://www.geocities.com/tryforfulluse/terrain.zip
Again, thank you for your insight, everyone
mr2071: Thank you for your comment, that terrain demo I wrote during our summer
( I havent done much programming for a while, getting back into it) It is one rendered heightmap, that I allow the user to interact with, by using some crap collision detection. I have lost the source code & latest version of the application, but here is one version I found if you care to look at it http://www.geocities.com/tryforfulluse/terrain.zip Again, thank you for your insight, everyone
quote:Original post by Crawl
I''ve actually done this... but you get cracks in the terrain.
Its possible to make it completely seamless, but it takes some effort as you have to design your tiles to interlock with lower detail level tiles. There is an article on this in one the of the game programming gem books (you might want to go to the bookstore and take a look at it).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
