Atlas Terrain - looking for guidance
by David Dougher · in Torque Game Engine Advanced · 08/21/2005 (7:32 am) · 11 replies
OK I have spent almost a month now working on the Atlas terrain and it seems that I must be missing something fundamental in how it functions. I have seen the pictures where an entire mountain is shown in loving detail, but I cannot get terrain to display with that level of height no matter what I do.
I have seen a couple of discussion where people are suggesting that the maximum you can go on the height is 1.0/256 -- anything higher will not work - has anyone confirmed this? If so what is the point of using Raw 16 files? Any 8 bit format would do.
So far I have tried using Photoshop7, Photoshop CS, Paint Shop Pro, L3DT, and I even bought a registered copy of Terragen so I could match up with the examples. I have tried evey power of two format from 512 to 32768 (and yes I know they have to be one pixel bigger on a side for the heightmap). As size goes up success rate goes down. I've managed to get a 2048 terrain to work once but it looked horribly flattened. Most of the time I get out of bins messages, min/max exceeded messages or chu files that are about 80K for a 130MB input file.
How about if somebody walks through how you make terrain taller, what the major error messages mean, what the limits are and most importantly, what to do to fix them.
I have seen a couple of discussion where people are suggesting that the maximum you can go on the height is 1.0/256 -- anything higher will not work - has anyone confirmed this? If so what is the point of using Raw 16 files? Any 8 bit format would do.
So far I have tried using Photoshop7, Photoshop CS, Paint Shop Pro, L3DT, and I even bought a registered copy of Terragen so I could match up with the examples. I have tried evey power of two format from 512 to 32768 (and yes I know they have to be one pixel bigger on a side for the heightmap). As size goes up success rate goes down. I've managed to get a 2048 terrain to work once but it looked horribly flattened. Most of the time I get out of bins messages, min/max exceeded messages or chu files that are about 80K for a 130MB input file.
How about if somebody walks through how you make terrain taller, what the major error messages mean, what the limits are and most importantly, what to do to fix them.
About the author
Owner - Pariah Games, Adjunct Professor - Bristol Community College, Mentor - Game Design - Met School Newport, Mentor - Game Design - Met School Providence
#2
My understanding of the scale is that the smaller the value the higher the terrain can be. So if you submit a value of 1.0/2*2*2*2*2*2*2*2 or 1.0/256 or 0.00390625 (I've seen it several different ways in the documentation and discussions on the subject) you get approximately the maximum height range reachable by the old 8 bit terrain.
To increase the terrain beyond that range you would use values like 1.0/512 or 0.001953125. Assuming the first yields a height of 256 meters, then the second should yield a height of 512 meters. To achieve the kinds of heights portrayed by things like the St. Helen's display you would have to assume a height of several thousand meters. So you would do for something like 1.0/2550. (The height of Mt St. Helens in meters) This would yield a value of 0.000392156
As for the error metric I have experimented with number from 2.0 to 100 with little effect.
As for the command call - I am using the dialog resource box in the GG forums for submitting the info rather than trying a command line. It can be found here...
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=8236
Thanks for the inut so far.
08/21/2005 (10:07 am)
Yup I am assuming it must be something like that.My understanding of the scale is that the smaller the value the higher the terrain can be. So if you submit a value of 1.0/2*2*2*2*2*2*2*2 or 1.0/256 or 0.00390625 (I've seen it several different ways in the documentation and discussions on the subject) you get approximately the maximum height range reachable by the old 8 bit terrain.
To increase the terrain beyond that range you would use values like 1.0/512 or 0.001953125. Assuming the first yields a height of 256 meters, then the second should yield a height of 512 meters. To achieve the kinds of heights portrayed by things like the St. Helen's display you would have to assume a height of several thousand meters. So you would do for something like 1.0/2550. (The height of Mt St. Helens in meters) This would yield a value of 0.000392156
As for the error metric I have experimented with number from 2.0 to 100 with little effect.
As for the command call - I am using the dialog resource box in the GG forums for submitting the info rather than trying a command line. It can be found here...
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=8236
Thanks for the inut so far.
#3
The best solution I found for it all was to use a nice sized heightmap, say 2048, and a small square size, say 1 or 0.5. The thing is, your probably getting high mountains and such with full detail but things may be so stretched out that all the changes in height are too gradual to tell.
Also if you need something bigger do smaller scale features on the heightmap. Like instead of a couple giant mountains on it, put a ton of really tall but very steep hills. When you stretch this out to make your terrain, the super-steep slope and sharp-point peek stretches out to mountain proportions.
I tried for so long trying to get a big mountain range but only got really big, smooth hills. I tried the things I just mentioned and now I can get very detailed, jagged mountins and cliffs of any size.
Oh, and I always just leave my error metric at 2 and height scale of 1/256. Seems to work just fine for me.
08/21/2005 (10:46 am)
I've had major trouble with this before until i realized my problem was squareSize versus heightmap size and feature scaling. Height scale had some decent effects, but still not enough. The best solution I found for it all was to use a nice sized heightmap, say 2048, and a small square size, say 1 or 0.5. The thing is, your probably getting high mountains and such with full detail but things may be so stretched out that all the changes in height are too gradual to tell.
Also if you need something bigger do smaller scale features on the heightmap. Like instead of a couple giant mountains on it, put a ton of really tall but very steep hills. When you stretch this out to make your terrain, the super-steep slope and sharp-point peek stretches out to mountain proportions.
I tried for so long trying to get a big mountain range but only got really big, smooth hills. I tried the things I just mentioned and now I can get very detailed, jagged mountins and cliffs of any size.
Oh, and I always just leave my error metric at 2 and height scale of 1/256. Seems to work just fine for me.
#4
Try and see if you can get the terrain to stretch even more by changing the scale, and then do the opposite. That's what I did, but unfortunatly I can't remember the details, and I'm not at home :( sorry.
I *think* I went below 1.0/256 before seeing what I wanted. Hopefully someone else can give you better info.
08/21/2005 (10:46 am)
Seems like what you're doing should have a positive effect on the result.Try and see if you can get the terrain to stretch even more by changing the scale, and then do the opposite. That's what I did, but unfortunatly I can't remember the details, and I'm not at home :( sorry.
I *think* I went below 1.0/256 before seeing what I wanted. Hopefully someone else can give you better info.
#5
The legacy terrain has the exact same vertical range as the Atlas terrain, barring any scaling. There's a fixed 16 bit range.
Input height values are multiplied by the scale value in the input step.
Then the error metric is applied.
Then everything is chunked (with binning etc) and written out to disk. If there are too many polygons or too few, it will error at you.
If you want a higher terrain, use a bigger scale. If you want more or less detail, decrease or increase the error metric.
I realize that this is really too hard for most people, so the next update will have some big improvements in the area of .CHU creation.
Ben
08/21/2005 (4:34 pm)
Hi guys,The legacy terrain has the exact same vertical range as the Atlas terrain, barring any scaling. There's a fixed 16 bit range.
Input height values are multiplied by the scale value in the input step.
Then the error metric is applied.
Then everything is chunked (with binning etc) and written out to disk. If there are too many polygons or too few, it will error at you.
If you want a higher terrain, use a bigger scale. If you want more or less detail, decrease or increase the error metric.
I realize that this is really too hard for most people, so the next update will have some big improvements in the area of .CHU creation.
Ben
#6
Bcack to TSE...
So, as I now understand the scaling, if the greyscale pixel height was say 8, then it would be multiplied by the value of the vertScale. If that value is expressed as a fraction, say 1/256, then you would get a height of 8/256. If I make the denominator large then I am actually making the terrain height shorter. For example, if I made the denominator 512 as in my example above then I would get 8/512 which is smaller. So to make the terrain higher I should make the denominator smaller, say 128. yielding 8/128.
Next, the error metric - if I want more detail I should decrease the error metric. If I want less detail I should increase the error metric. This explains why the procedure would be to initially set the error metric to something very large and then decrease it until you get an error like an out of bins. As you decrease the error metric the detail will improve -adding polygons - but at some point the number of polys will exceed the magic 65535 number and you will break.
Also, as I understand it the squaresize should have no effect on the generation of the terrain, since it is coming into play after the terrain calculations are done, however, if you have a small squaresize number you potentially increase the number of polygons that are trying to be rendered to the screen pushing up the framerate and straining the video card.
Finally, the treeDepth indicates the shape of the Quadtree that holds the chunks of the terrain. A deeper tree means more search time to get to a chunk, but a thinner tree means more memory is consumed and potentially more chances to exceeed the 64K breaking point.
So to improve my chances of getting a taller terrain I should reduce the fractional component of the scaling to something like 1/192 or 1/128. Then I should increase the error metric initially to make sure that the terrain processes successfully and after it does, I should reduce the error metric in successive tests until I see a failure. From this I can determine the highest level of detail which does not cause the terrain to exceed the polygonal limits.
One question. Does increasing the depth of the tree convey any advantage in reducing the chance of a polygon overload? It would seem that you could trade tree depth (and speed) for increasing the chances of avoiding the 64K limit.
08/21/2005 (6:38 pm)
Thanks for taking time on a Sunday to reply. Apologies to all for the misinformation on 8 bit for the old terrain. I was specifically thinking about how the older terrain accepted 8 bit heightmaps and the examples all use 256 as the base for the scaling division.Bcack to TSE...
So, as I now understand the scaling, if the greyscale pixel height was say 8, then it would be multiplied by the value of the vertScale. If that value is expressed as a fraction, say 1/256, then you would get a height of 8/256. If I make the denominator large then I am actually making the terrain height shorter. For example, if I made the denominator 512 as in my example above then I would get 8/512 which is smaller. So to make the terrain higher I should make the denominator smaller, say 128. yielding 8/128.
Next, the error metric - if I want more detail I should decrease the error metric. If I want less detail I should increase the error metric. This explains why the procedure would be to initially set the error metric to something very large and then decrease it until you get an error like an out of bins. As you decrease the error metric the detail will improve -adding polygons - but at some point the number of polys will exceed the magic 65535 number and you will break.
Also, as I understand it the squaresize should have no effect on the generation of the terrain, since it is coming into play after the terrain calculations are done, however, if you have a small squaresize number you potentially increase the number of polygons that are trying to be rendered to the screen pushing up the framerate and straining the video card.
Finally, the treeDepth indicates the shape of the Quadtree that holds the chunks of the terrain. A deeper tree means more search time to get to a chunk, but a thinner tree means more memory is consumed and potentially more chances to exceeed the 64K breaking point.
So to improve my chances of getting a taller terrain I should reduce the fractional component of the scaling to something like 1/192 or 1/128. Then I should increase the error metric initially to make sure that the terrain processes successfully and after it does, I should reduce the error metric in successive tests until I see a failure. From this I can determine the highest level of detail which does not cause the terrain to exceed the polygonal limits.
One question. Does increasing the depth of the tree convey any advantage in reducing the chance of a polygon overload? It would seem that you could trade tree depth (and speed) for increasing the chances of avoiding the 64K limit.
#7
Yeah, a deeper tree can help. Bear in mind that there is a maximum polygon density, so subdividing after a certain point won't do you any good.
08/21/2005 (7:00 pm)
Actually, the depth of the chunk tree has very little to do with search times or anything; mostly to do with load times as it has to load all parent chunks before it can load a child chunk. Also controls how finely you can texture things.Yeah, a deeper tree can help. Bear in mind that there is a maximum polygon density, so subdividing after a certain point won't do you any good.
#8
Now if I have issues with the conversions I'll know where to start looking for solutions. And I think everyone will look forward to the next round of TSE improvements!
08/21/2005 (9:18 pm)
Excellent - thank you for the clearing up my befuddlement.Now if I have issues with the conversions I'll know where to start looking for solutions. And I think everyone will look forward to the next round of TSE improvements!
#9
This first image is a 1024 heightmap with 1 square size, 1/256 height scale, 2 error metric, and 4 tree depth.
[IMG]http://img377.imageshack.us/img377/1880/normal9ke.th.jpg[/IMG]
This is the exact same thing, only with 4 square size.
[IMG]http://img250.imageshack.us/img250/7719/stretch7np.th.jpg[/IMG]
Same height and everything, but the stretching causes it to lose detail and appear flat.
And here is a different 1024 heightmap with same settings, 4 square size, but there are more, smaller scale details on the heightmap.
[IMG]http://img375.imageshack.us/img375/5592/dense2al.th.jpg[/IMG]
Still a bit flat, although I could've easily made things more compact, and could've increased the heightscale a bit. But when your making these terrains, make sure to check if your stretching it too much with square size as this shows the major difference in appearence you can get. And I wouldn't worry about speed because I couldn't notice any change in FPS from a large or small square size.
08/22/2005 (7:24 am)
Btw, just so everyone understands what I was saying above about squareSize, here is a small demonstration. Since this is what was causing me quite a bit of trouble, someone else may like it explained too.This first image is a 1024 heightmap with 1 square size, 1/256 height scale, 2 error metric, and 4 tree depth.
[IMG]http://img377.imageshack.us/img377/1880/normal9ke.th.jpg[/IMG]
This is the exact same thing, only with 4 square size.
[IMG]http://img250.imageshack.us/img250/7719/stretch7np.th.jpg[/IMG]
Same height and everything, but the stretching causes it to lose detail and appear flat.
And here is a different 1024 heightmap with same settings, 4 square size, but there are more, smaller scale details on the heightmap.
[IMG]http://img375.imageshack.us/img375/5592/dense2al.th.jpg[/IMG]
Still a bit flat, although I could've easily made things more compact, and could've increased the heightscale a bit. But when your making these terrains, make sure to check if your stretching it too much with square size as this shows the major difference in appearence you can get. And I wouldn't worry about speed because I couldn't notice any change in FPS from a large or small square size.
#10
out beyond the beta documents (Not a complaint just an observation). It's sweet but I am struggling with
it.
08/22/2005 (9:57 am)
I am just now getting into Atlas. Again we have a documentation issue where some things are spreadout beyond the beta documents (Not a complaint just an observation). It's sweet but I am struggling with
it.
#11
08/22/2005 (11:01 am)
TDN will have some better organized docs on Atlas, and the next update I do to it will fix a lot of issues with usability. 
Torque Owner Stefan Lundmark
To me it sounds like you need to mess around with the scale some. I had these exact problems when my error metric was too small or too large, and the terrain was stretched. Hopefully that's what's causing you grief, if not.. can you post an example where it does not work, including the command line calls to create the terrain?