FPS terrain revisited
by David Aiken · in Technical Issues · 12/09/2008 (6:21 pm) · 12 replies
Suppose i was creating a 2k by 2k temperate forest terrain for an FPS with roads, rivers, caves, and rock outcrops (which are handled admirably by the Cliff Construction set). The edges of the terrain area hit the sky box with no need for tiling. Which terrain system is best suited?
As i understand it, currently Atlas 2 is designed primarily for flight simulators and MMORPGs (http://www.garagegames.com/mg/forums/result.thread.php?qt=74746). From the post there were a few limitations with MegaTerrain as of last spring:
>>
It is limited to blended textures only and does not support applying a single large texture across the entire block. It will also repeat any shadows baked into it from buildings over and over and the repeating tiles and will not bake in shadows for buildings outside of the original square. Traditionally it has also been hard to achieve a high texture resolution on TerrainBlocks but that should be a lot better with TGEA 1.7.0.
>>
I believe it is also possible to create "holes" (caves?) in the MegaTerrain geometry, but could be mistaken. I think Arteria uses polysoup DTS for this (with potential overdraw and maybe LOD concerns to watch out for? I plead ignorance..).
Judging by the post, IMHO the MegaTerrain system was the best candidate back then. Is this accurate today?
I would ideally like something along the lines of ET:QW, with the ability to pull a mesh from the DTS modelling pipeline (perhaps based on Terragen or L3DT assets). In-game editing of the terrain is Nice To Have, but i'm comfortable using a modeller like 3DS Max or the like to create mesh/texture it/add caves/apply shaders/add boulders, cliffs etc. Is it possible now/in the future to import a DTS terrain mesh into one or more of the terrain systems.. perhaps making node data available in-game?
As an aside, I believe UnrealEd allows import of 3DS Max files for terrain. Not a criticism.. just an observation - TGEA may well improve on this! I'm not an experienced level editor so any feedback is certainly welcome.
As i understand it, currently Atlas 2 is designed primarily for flight simulators and MMORPGs (http://www.garagegames.com/mg/forums/result.thread.php?qt=74746). From the post there were a few limitations with MegaTerrain as of last spring:
>>
It is limited to blended textures only and does not support applying a single large texture across the entire block. It will also repeat any shadows baked into it from buildings over and over and the repeating tiles and will not bake in shadows for buildings outside of the original square. Traditionally it has also been hard to achieve a high texture resolution on TerrainBlocks but that should be a lot better with TGEA 1.7.0.
>>
I believe it is also possible to create "holes" (caves?) in the MegaTerrain geometry, but could be mistaken. I think Arteria uses polysoup DTS for this (with potential overdraw and maybe LOD concerns to watch out for? I plead ignorance..).
Judging by the post, IMHO the MegaTerrain system was the best candidate back then. Is this accurate today?
I would ideally like something along the lines of ET:QW, with the ability to pull a mesh from the DTS modelling pipeline (perhaps based on Terragen or L3DT assets). In-game editing of the terrain is Nice To Have, but i'm comfortable using a modeller like 3DS Max or the like to create mesh/texture it/add caves/apply shaders/add boulders, cliffs etc. Is it possible now/in the future to import a DTS terrain mesh into one or more of the terrain systems.. perhaps making node data available in-game?
As an aside, I believe UnrealEd allows import of 3DS Max files for terrain. Not a criticism.. just an observation - TGEA may well improve on this! I'm not an experienced level editor so any feedback is certainly welcome.
About the author
#2
Looked about and found a current thread which takes this approach: http://www.garagegames.com/mg/forums/result.thread.php?qt=73216 . It seems like it will work.. eventually.
Judging by the official doc at http://www.garagegames.com/docs/tgea/official/content/documentation/Engine%20Overview/Atlas.html, Atlas is not restricted to heightmaps. I didn't get a feel for the texture support from this doc, but from http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9528 it is capable of handling 64 blended textures.
So i guess you might write a .obj importer that would allow 64 UV-mapped textures. It could then generate the alpha maps based on the UV coordinates. Does this make sense? I'm not sure how the Atlas importer handles textures. I'm also wondering about the positioning of Atlas and Atlas 2. Is the latter intended to replace Atlas, or is it complementary and intended for vast expanses?
12/10/2008 (12:31 pm)
A criticism of the Romans was that their roads were essentially walls flipped on their side. They weren't particularly subtle :>). I guess in this case a road could be just a flattened cliff. Putting a col-x box around a winding road lacks accuracy so a TSStatic with polysoup would seem necessary. Looked about and found a current thread which takes this approach: http://www.garagegames.com/mg/forums/result.thread.php?qt=73216 . It seems like it will work.. eventually.
Judging by the official doc at http://www.garagegames.com/docs/tgea/official/content/documentation/Engine%20Overview/Atlas.html, Atlas is not restricted to heightmaps. I didn't get a feel for the texture support from this doc, but from http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9528 it is capable of handling 64 blended textures.
So i guess you might write a .obj importer that would allow 64 UV-mapped textures. It could then generate the alpha maps based on the UV coordinates. Does this make sense? I'm not sure how the Atlas importer handles textures. I'm also wondering about the positioning of Atlas and Atlas 2. Is the latter intended to replace Atlas, or is it complementary and intended for vast expanses?
#3
12/10/2008 (12:34 pm)
This doesn't mean i'm discarding MegaTerrain, Rene - just curious about Atlas as it seems to be designed with this in mind. 
#4
The current importers are entirely based off 2d maps. Geometry and textures are both chopped up into rectangular tiles, stuffed into a quadtree, and then LODed (geometry using an error metric, textures using simple mipping).
Writing an .obj importer is feasible and, given some familiarity with Atlas, shouldn't be too much work, though you'd probably not be able to couple it to that much of the existing generator code (wouldn't be wise anyway). You would want to watch out, though, that you have some scheme for chopping up your geometry into tiles such that they are amenable to being stuffed into a quadtree. You probably would need to write your own LODing code, too. Watch out for handling tile borders correctly.
The texturing resource you have pointed out is an interesting one. Atlas and Torque have changed quite a bit since that time, but porting it should not be overly much work. Would do away with the clipmapping, too, which would be a good thing given non-heightfield geometry.
Lighting may turn into a problem. You probably would want to have support for Torque's lightmapping. Given level 3 shaders, that could probably be added to above's resource, though you'd probably also have to make some changes to the SG Atlas generator code. IIRC polysoup statics also have some lighting peculiarities.
Ok, that's as much as comes to my tired mind at the moment...
12/10/2008 (5:01 pm)
You're right about Atlas not being restricted to heightmaps. It's a polygon-based system that in theory allows arbitrary geometry including free UV mapping (not just planar as with heightmap-based systems).The current importers are entirely based off 2d maps. Geometry and textures are both chopped up into rectangular tiles, stuffed into a quadtree, and then LODed (geometry using an error metric, textures using simple mipping).
Writing an .obj importer is feasible and, given some familiarity with Atlas, shouldn't be too much work, though you'd probably not be able to couple it to that much of the existing generator code (wouldn't be wise anyway). You would want to watch out, though, that you have some scheme for chopping up your geometry into tiles such that they are amenable to being stuffed into a quadtree. You probably would need to write your own LODing code, too. Watch out for handling tile borders correctly.
The texturing resource you have pointed out is an interesting one. Atlas and Torque have changed quite a bit since that time, but porting it should not be overly much work. Would do away with the clipmapping, too, which would be a good thing given non-heightfield geometry.
Lighting may turn into a problem. You probably would want to have support for Torque's lightmapping. Given level 3 shaders, that could probably be added to above's resource, though you'd probably also have to make some changes to the SG Atlas generator code. IIRC polysoup statics also have some lighting peculiarities.
Ok, that's as much as comes to my tired mind at the moment...
#5
12/10/2008 (5:11 pm)
BTW: If your terrain is such that you can create and *edit* it as one in a standard 3D package, it may be worth thinking about foregoing dedicated terrain rendering altogether and rather just do some form of brute-force mesh rendering.
#6
I've also looked at ET:QW, the Doom3 MegaTexture mod, and Sean Barrett's SVT (the latter two with source, but limited functionality compared to QW). I think the goal is noble, but current hardware (maybe just My current hardware :>) seems to limit the impact of the terrain cover in QW on immersion. Asset creation seems quite similar to the DTS workflow.. diffuse, ambient occlusion, and normal maps generated from a high poly model and a UV map to tie them to the low poly equivalent. Not sure how custom shaders fit in. They do use .obj to move this around. This starts to sound like a virtual texture/geometry system that could be used for everything in a level, though i understand that tweaks were necessary to get the MegaTexture approach to work if the terrain departs from a deformed plane (textures stretching over cliffs...). The Crytek paper at http://ati.amd.com/developer/SIGGRAPH08/Chapter02-Mittring-Advanced_Virtual_Texture_Topics.pdf seems to be a good overview.
John Carmack has since moved on to "ray tracing into a sparse voxel octree".. which really pushes further on the virtualization - requiring significantly more data to represent the same scene as the current triangle-based approach, but allowing real-time ray-tracing because the octrees allow rapid culling of the data for presentation. Everyone will be playing Comanche V :>). Even JC now acknowledges this is next-generation (http://raytracey.blogspot.com/2008/08/voxel-ray-tracing-vs-polygon-ray.html .. and i don't for a moment believe that there is a graphics programmer named "Ray Tracey" :>).
Anyway.. it seems interesting to me so i thought i'd share it. Probably old news to you and the other veteran Torquers. I'm learning the technology so i have some time to dabble.
12/11/2008 (2:41 am)
Thanks - i'll have to look into the implementation a bit more to better understand the pain/gain.I've also looked at ET:QW, the Doom3 MegaTexture mod, and Sean Barrett's SVT (the latter two with source, but limited functionality compared to QW). I think the goal is noble, but current hardware (maybe just My current hardware :>) seems to limit the impact of the terrain cover in QW on immersion. Asset creation seems quite similar to the DTS workflow.. diffuse, ambient occlusion, and normal maps generated from a high poly model and a UV map to tie them to the low poly equivalent. Not sure how custom shaders fit in. They do use .obj to move this around. This starts to sound like a virtual texture/geometry system that could be used for everything in a level, though i understand that tweaks were necessary to get the MegaTexture approach to work if the terrain departs from a deformed plane (textures stretching over cliffs...). The Crytek paper at http://ati.amd.com/developer/SIGGRAPH08/Chapter02-Mittring-Advanced_Virtual_Texture_Topics.pdf seems to be a good overview.
John Carmack has since moved on to "ray tracing into a sparse voxel octree".. which really pushes further on the virtualization - requiring significantly more data to represent the same scene as the current triangle-based approach, but allowing real-time ray-tracing because the octrees allow rapid culling of the data for presentation. Everyone will be playing Comanche V :>). Even JC now acknowledges this is next-generation (http://raytracey.blogspot.com/2008/08/voxel-ray-tracing-vs-polygon-ray.html .. and i don't for a moment believe that there is a graphics programmer named "Ray Tracey" :>).
Anyway.. it seems interesting to me so i thought i'd share it. Probably old news to you and the other veteran Torquers. I'm learning the technology so i have some time to dabble.
#7
Note that in the case of terrains, the usual high-poly to low-poly+maps approach isn't quite so easy anymore. With a character model, you can take a basemesh with a few hundred polys and detail it out to several million polys in ZBrush. With terrain, you're already talking about a basemesh with several hundred thousand if not million polys; detailing would end up in the billion poly range. Not quite as simple.
Wouldn't want to be trying to keep up with what Carmack is cooking up...
One other thing: as a programmer, you can come up with lots and lots of fancy things you could do that would totally rock. Whether you are able to actually have working content creation paths and are actually able to leverage that technology is an entirely different thing--especially if you are working off a resource-constrained situation such as indi- or even hobbyist-level development.
12/11/2008 (6:08 am)
As for megatexturing: Atlas already has unique texturing in place. For more or less planar meshes, clipmapping should also be doing okay (there's some issues with in the current code). With more complex geometry, you could replace the clipmapping renderer with an SVT renderer, if you wanted to.Note that in the case of terrains, the usual high-poly to low-poly+maps approach isn't quite so easy anymore. With a character model, you can take a basemesh with a few hundred polys and detail it out to several million polys in ZBrush. With terrain, you're already talking about a basemesh with several hundred thousand if not million polys; detailing would end up in the billion poly range. Not quite as simple.
Wouldn't want to be trying to keep up with what Carmack is cooking up...
One other thing: as a programmer, you can come up with lots and lots of fancy things you could do that would totally rock. Whether you are able to actually have working content creation paths and are actually able to leverage that technology is an entirely different thing--especially if you are working off a resource-constrained situation such as indi- or even hobbyist-level development.
#8
12/11/2008 (4:41 pm)
Do you know of any demos/screen shots which best show off Atlas unique and/or blended terrain? I suspect you are probably the best person to ask :>).
#9
12/11/2008 (4:59 pm)
A demo (albeit not very impressive one) for blended Atlas terrain comes with stock Torque. For a demo that showcases Atlas unique terrain (and for a demo that best showcases the problems with the current Atlas), you can download the separately available Barricade demo. It has a 4096x4096 terrain textured with a 16384x16384 "unique" texture that took L3DT a good one and a half week to generate on my Dell craptop (I've put unique in quotes as L3DT uses blending to generate the 'unique' texture :)
#10
12/11/2008 (9:25 pm)
Well.. the Barricade terrain looks serviceable from a distance, but the smeared-pastel look up close and the sharply angled terrain contours make it seem rather bland. I'll see what i can do for now.. maybe mixing various elements together is enough to support the gameplay. Thanks for your help!
#11
If you increase the clipmap resolution ($Pref::Atlas::clipMapSize) from the default 512 to 1024 or even 2048, you should get pretty sharp textures in Barricade even up close. Not sure, though, whether we were having lots of LOD dropping issues in the final release; if so, you won't be seeing the highest LOD of the texture with some clipmap sizes.
The terrain geometry is also pretty dense, so there actually shouldn't be that much sharply angled terrain contours, but maybe it's just my memory that's failing on me this early in the day.
Good luck with your game. Absolutely looking forward to seeing another example of Torque being put to good use.
12/12/2008 (12:15 am)
Addendum Atlas in Barricade :)If you increase the clipmap resolution ($Pref::Atlas::clipMapSize) from the default 512 to 1024 or even 2048, you should get pretty sharp textures in Barricade even up close. Not sure, though, whether we were having lots of LOD dropping issues in the final release; if so, you won't be seeing the highest LOD of the texture with some clipmap sizes.
The terrain geometry is also pretty dense, so there actually shouldn't be that much sharply angled terrain contours, but maybe it's just my memory that's failing on me this early in the day.
Good luck with your game. Absolutely looking forward to seeing another example of Torque being put to good use.
#12
http://www.beyond3d.com/content/articles/95/
12/19/2008 (2:16 pm)
BTW i just came across this.. probably old news.http://www.beyond3d.com/content/articles/95/
Associate Rene Damm
Atlas only has a heightfield-based importer right now; a mesh-based importer would have to be written by yourself.
My recommendation would be to go with MegaTerrain. For caves and such, you could stamp holes in the terrain (legacy could always do that) and then fit some DTS or DIF around there.
The only problem I'd see is with the roads. Easiest thing is to paint them on the terrain but with blended terrain, that kind of sucks.
//EDIT: typos