Help on terrain mapping article
by Sander "Tweety" Mar · in Artist Corner · 03/15/2002 (1:47 am) · 5 replies
I have recently finished my very first article. It's about Terrain mapping and how old fashiond Brute Force can be applied to get higher speeds than CLOD or ROAM. I had Jejik (my compangon at Lone Wolves read it. He said its OK but he is not a game programmer. I would greatly appreciate it if any of you guys (with some knowledge of terrain mapping) can read it and give me some feedback before I send it in as a resource of any kind. I have no idea if the article is any good or if it is just me rambling away. :-)
If you want, you can read the article at www.jejik.com/bruteforce.shtml. just follow the BF terrain link in the menu on the left.
Thanks a lot in advance!
Sander Marechal
s.marechal@jejik.com
If you want, you can read the article at www.jejik.com/bruteforce.shtml. just follow the BF terrain link in the menu on the left.
Thanks a lot in advance!
Sander Marechal
s.marechal@jejik.com
#2
First of all there are a few typos that should have been picked up by your spelling checker :).
I thought CLOD was the term used for all CLOD algorithms including ROAM? Perhaps you could indicate which CLOD algorithms you have experimented with.
100m is a pretty small clipping distance, especially for a flight sim - just an observation.
The comparison you use is not a good one. You need to show how the two methods scale. In this case the CLOD algorithm renders a grid of size 512x512 at a slower speed than the BF algorithm (I assume your 2048x2048m landscape is using the 4m grid size). But what happens when you double the size of the terrain? A graph of at least 4 points is needed here before you can draw any conclusions.
Also what was the clipping distance for the CLOD algorithm with your 100m clipping distance you are displaying under 2000 triangles out of a maximum of 500000. So I should have said above "what happens when you double the clipping distance?"
Also I am not sure you have experemented enough with GeoMipMaps - but I am biased because I am working on a GeoMipMap algorithm now. I am currently rendering 1280x1280m terrain at 1m resolution (highest detail level) with no clipping at all and getting around 80fps (using a higher end machine though). Using a brute force approach (but with no optimisations) the frame rate is under 10fps, not surprising since there are over 3M polys to render.
You mention in the article that a BF approach will only be better under certain conditions. If you can determine the level at which BF becomes better and report your findings in the conclusion as well as in the body then it will be a useful article. I hope you will find my criticisms constructive, they were meant to be :)
03/18/2002 (6:15 pm)
The article is well written but I have some problems with the content.First of all there are a few typos that should have been picked up by your spelling checker :).
I thought CLOD was the term used for all CLOD algorithms including ROAM? Perhaps you could indicate which CLOD algorithms you have experimented with.
100m is a pretty small clipping distance, especially for a flight sim - just an observation.
The comparison you use is not a good one. You need to show how the two methods scale. In this case the CLOD algorithm renders a grid of size 512x512 at a slower speed than the BF algorithm (I assume your 2048x2048m landscape is using the 4m grid size). But what happens when you double the size of the terrain? A graph of at least 4 points is needed here before you can draw any conclusions.
Also what was the clipping distance for the CLOD algorithm with your 100m clipping distance you are displaying under 2000 triangles out of a maximum of 500000. So I should have said above "what happens when you double the clipping distance?"
Also I am not sure you have experemented enough with GeoMipMaps - but I am biased because I am working on a GeoMipMap algorithm now. I am currently rendering 1280x1280m terrain at 1m resolution (highest detail level) with no clipping at all and getting around 80fps (using a higher end machine though). Using a brute force approach (but with no optimisations) the frame rate is under 10fps, not surprising since there are over 3M polys to render.
You mention in the article that a BF approach will only be better under certain conditions. If you can determine the level at which BF becomes better and report your findings in the conclusion as well as in the body then it will be a useful article. I hope you will find my criticisms constructive, they were meant to be :)
#3
Phil didn't agree that BF IS the *best* solution. I agree with that. I read through my article again and I agree that it's a bit over the top about the power of BF. I didn't want to present it as a best solution but as a reasonale alternative. I'm going to rewrite a part of the article to reflect this.
Robert stated that 100m clipping distance is pretty small. True, if Raid3D was a flightsim. But it's a Baldur's Gate style strategy. The players get really small at 100m (about 4 pixels) so people are not likely to focus at the horizon at all.
I did try to double the clipping distance as he suggested. With the same scale and detail the framerate dropped from approx. 130 to 50. Quite a big step back I agree but still not horribly slow, but if I were to double it again it would probabely freeze :-)
I also tried doubling the size of the terrain (4096x4096m) keeping the same grid size. Framerate dropped a little bit but not much (to about 110 fps). I guess because all the extra terrain extends well beyond the clipping borders. It only took up more memory.
I'd have to look up which CLOD algorithms I used to test. One of them can be found through Gamasutra but the others I don't know right away. Then I will also try to figure out more specificly at which point BF becomes interesting.
One thing remains true however. BF cannot render the same quality as CLOD can, but the gap has become small enough to take a new look at BF. I think that's really the core of the article. I'm going to rewrite it with the help of your comments. I'll put up a post when I'm done.
One last question for Robert: How do you keep memory usage low with GeoMipMaps? I couldn't solve this problem really well when I tried the algorithm. The amount of prerendered patches became really huge and besides that I also had to keep a real big heighmap in memory.
Thanx again for the comments! And sorry about the typo's. I don't have an english spell check at the moment. Soon to be fixed though :-)
03/19/2002 (12:06 am)
Thanx for the critisism on the article. It's my first one and I want it to be a reasonabely good one.Phil didn't agree that BF IS the *best* solution. I agree with that. I read through my article again and I agree that it's a bit over the top about the power of BF. I didn't want to present it as a best solution but as a reasonale alternative. I'm going to rewrite a part of the article to reflect this.
Robert stated that 100m clipping distance is pretty small. True, if Raid3D was a flightsim. But it's a Baldur's Gate style strategy. The players get really small at 100m (about 4 pixels) so people are not likely to focus at the horizon at all.
I did try to double the clipping distance as he suggested. With the same scale and detail the framerate dropped from approx. 130 to 50. Quite a big step back I agree but still not horribly slow, but if I were to double it again it would probabely freeze :-)
I also tried doubling the size of the terrain (4096x4096m) keeping the same grid size. Framerate dropped a little bit but not much (to about 110 fps). I guess because all the extra terrain extends well beyond the clipping borders. It only took up more memory.
I'd have to look up which CLOD algorithms I used to test. One of them can be found through Gamasutra but the others I don't know right away. Then I will also try to figure out more specificly at which point BF becomes interesting.
One thing remains true however. BF cannot render the same quality as CLOD can, but the gap has become small enough to take a new look at BF. I think that's really the core of the article. I'm going to rewrite it with the help of your comments. I'll put up a post when I'm done.
One last question for Robert: How do you keep memory usage low with GeoMipMaps? I couldn't solve this problem really well when I tried the algorithm. The amount of prerendered patches became really huge and besides that I also had to keep a real big heighmap in memory.
Thanx again for the comments! And sorry about the typo's. I don't have an english spell check at the moment. Soon to be fixed though :-)
#4
Sorry I must have misread the article. For this style of game 100m is probably OK.
"I did try to double the clipping distance ... the framerate dropped from approx. 130 to 50...
Well worth putting this in the article. While I think it is possible to be too verbose I don't think you can really include too much information as long as it is relevant and well presented. Graphs are a great way to get your point across.
"but the gap has become small enough to take a new look at BF"
That is what I think the article should focus on.
"One last question for Robert: How do you keep memory usage low with GeoMipMaps? I couldn't solve this problem really well when I tried the algorithm. The amount of prerendered patches became really huge and besides that I also had to keep a real big heighmap in memory."
I didn't write the engine I'm using (AuranJet), I'm just working on a terrain algorithm for it. I haven't come up against any memory issues yet but the project is still in the early stages. At the moment I am using 100% procedural terrain, using a VERY simple algorithm to calculate heights so I can do that on the fly. I plan to continue with procedurally generated terrain but as the algorithm becomes more complex I may have to precalculate the heightmap, I'm trying to avoid that though.
When I get a couple of problems ironed out I'll try and work out how much memory its using and let you know. One thing that may be helping is the fact that I am using very large MipMap tiles and only a few detail levels for each tile. There is a good eason why I think I can get away with this but I wont say anything until I make sure it works.
I look forward to reading your updated article.
03/19/2002 (12:49 am)
"Robert stated that 100m clipping distance is pretty small. True, if Raid3D was a flightsim. But it's a Baldur's Gate style strategy. The players get really small at 100m (about 4 pixels) so people are not likely to focus at the horizon at all."Sorry I must have misread the article. For this style of game 100m is probably OK.
"I did try to double the clipping distance ... the framerate dropped from approx. 130 to 50...
Well worth putting this in the article. While I think it is possible to be too verbose I don't think you can really include too much information as long as it is relevant and well presented. Graphs are a great way to get your point across.
"but the gap has become small enough to take a new look at BF"
That is what I think the article should focus on.
"One last question for Robert: How do you keep memory usage low with GeoMipMaps? I couldn't solve this problem really well when I tried the algorithm. The amount of prerendered patches became really huge and besides that I also had to keep a real big heighmap in memory."
I didn't write the engine I'm using (AuranJet), I'm just working on a terrain algorithm for it. I haven't come up against any memory issues yet but the project is still in the early stages. At the moment I am using 100% procedural terrain, using a VERY simple algorithm to calculate heights so I can do that on the fly. I plan to continue with procedurally generated terrain but as the algorithm becomes more complex I may have to precalculate the heightmap, I'm trying to avoid that though.
When I get a couple of problems ironed out I'll try and work out how much memory its using and let you know. One thing that may be helping is the fact that I am using very large MipMap tiles and only a few detail levels for each tile. There is a good eason why I think I can get away with this but I wont say anything until I make sure it works.
I look forward to reading your updated article.
#5
To read it, go to Lone Wolves and click left on the "BF terrain" link
in the articles section.
I hope you can give me feedback again on the quality of the article. I plan on sending it in as a resource if it is any good.
Thank you!
04/22/2002 (2:14 pm)
I've updated the article. The introduction paragraphs are still the same, the rest is pretty much different. I hope it's less biased, presents more facts and gives a better overview of both rendering methods (Brute Force and CLOD). To read it, go to Lone Wolves and click left on the "BF terrain" link
in the articles section.
I hope you can give me feedback again on the quality of the article. I plan on sending it in as a resource if it is any good.
Thank you!
Torque 3D Owner Phil Carlisle
I had pretty much the same experience, but i still have reservations on the scalability of it. Its fine for higher end cards with memory to spare. But even on a TNT2 I'd say it wasnt an optimal choice.
I guess if it fills your needs then thats fine, I'd always suggest using brute force for most subjects initially because it MAY work :))
Phil.