Terrain features/wishlist discussion
by Tim Holt · in Torque Game Engine Advanced · 08/24/2007 (10:49 am) · 11 replies
I started working out a "what I wish terrain was like" list here, and I invite others to add to it and comment. I don't see this as a "how to make Atlas better" post at all - but more like "how would you design a terrain system for a game?" thread.
Features that would be nice in a terrain system...
Infinite
You should be able to create terrain that is essentially infinite, and limited only by the disk storage required to hold all the data. See Tiling next.
Tiling
The world data should be tiled. That is, broken into a series of smaller finite sections of some fixed size. This tile size can vary depending on how much stuff a developer wants to stick in a tile. If you are creating a world that is 16x16km across, perhaps you want to work with 1x1km tiles. But if it is 160x160km across, then 10km tiles.
Tiles have multiple advantages over the "one big hunk of terrain" approach, including...
* They can be used to represent non-rectilinear areas. Imagine trying to create terrain for a huge "C" shaped island.
* They can be edited individually by developers allowing easier world construction.
* The world can easily be expanded by adding new tiles.
* Tiles can be swapped in and out of memory as needed, thus allowing "infinite" terrain.
* Game content (trees, buildings, NPCs and other objects) can be associated with a tile and also swapped in and out of memory as the user moves around.
* Creating and managing terrain data (height maps, overlay images, etc.) becomes much simpler. It's easier to edit 4 images at 8192x8192 than 1 at 32767x32767.
Holes
The ability to make a hole in the terran so that you can have a cave or other "thing" that punches through the terran surface.
Geodata Aware
There are already a lot of standard ways for managing real world geographical data out there, and I think that game developers should start using these methods. A GeoTIFF image for example is not just an image, but an image with associated meta-data that describes what the image is and more importantly what the geographical bounds (lat/lon) of the image are. DTED is a standard for creating heightmaps of varying resolutions.
Rather than the typical process of "Here is a big image that is a height map and I have to tell the game just what the scales are", I'd rather say "Here is a DTED file of my terrain and 5 GeoTIFFs that overlay it in various ways. Figure it out." It's not that hard to create fake game-world data in these formats, assuming you are mapping something with a typical Cartesian coordinate system. And clearly it makes importing of real world data trivial.
A game engine that brilliantly handles this kind of data is Delta3d (http://www.delta3d.org).
Terrain Editing
An integrated editor that allows editing of terrain data while also editing world contents is a must. There is nothing worse than trying to place a building for example on a rough piece of ground, and having no way to flatten the ground out. Though there are a number of very good terrain editors availble, they only work for creating the initial terrain data. Terrain editing has to be integrated in with world editing so that one can paint bare dirt around the base of a building that is in a grassy field, or flatten the land where a path will be and so on.
Automatic
A terrain system should be automatic and not require massaging of parameters or settings to work. The only tweaking required should be for optimization. Using geo-reference data such as GeoTIFF and DTED as input can greatly help, as it already has all the information about pixel size, height extents, map extents and so on.
Features that would be nice in a terrain system...
Infinite
You should be able to create terrain that is essentially infinite, and limited only by the disk storage required to hold all the data. See Tiling next.
Tiling
The world data should be tiled. That is, broken into a series of smaller finite sections of some fixed size. This tile size can vary depending on how much stuff a developer wants to stick in a tile. If you are creating a world that is 16x16km across, perhaps you want to work with 1x1km tiles. But if it is 160x160km across, then 10km tiles.
Tiles have multiple advantages over the "one big hunk of terrain" approach, including...
* They can be used to represent non-rectilinear areas. Imagine trying to create terrain for a huge "C" shaped island.
* They can be edited individually by developers allowing easier world construction.
* The world can easily be expanded by adding new tiles.
* Tiles can be swapped in and out of memory as needed, thus allowing "infinite" terrain.
* Game content (trees, buildings, NPCs and other objects) can be associated with a tile and also swapped in and out of memory as the user moves around.
* Creating and managing terrain data (height maps, overlay images, etc.) becomes much simpler. It's easier to edit 4 images at 8192x8192 than 1 at 32767x32767.
Holes
The ability to make a hole in the terran so that you can have a cave or other "thing" that punches through the terran surface.
Geodata Aware
There are already a lot of standard ways for managing real world geographical data out there, and I think that game developers should start using these methods. A GeoTIFF image for example is not just an image, but an image with associated meta-data that describes what the image is and more importantly what the geographical bounds (lat/lon) of the image are. DTED is a standard for creating heightmaps of varying resolutions.
Rather than the typical process of "Here is a big image that is a height map and I have to tell the game just what the scales are", I'd rather say "Here is a DTED file of my terrain and 5 GeoTIFFs that overlay it in various ways. Figure it out." It's not that hard to create fake game-world data in these formats, assuming you are mapping something with a typical Cartesian coordinate system. And clearly it makes importing of real world data trivial.
A game engine that brilliantly handles this kind of data is Delta3d (http://www.delta3d.org).
Terrain Editing
An integrated editor that allows editing of terrain data while also editing world contents is a must. There is nothing worse than trying to place a building for example on a rough piece of ground, and having no way to flatten the ground out. Though there are a number of very good terrain editors availble, they only work for creating the initial terrain data. Terrain editing has to be integrated in with world editing so that one can paint bare dirt around the base of a building that is in a grassy field, or flatten the land where a path will be and so on.
Automatic
A terrain system should be automatic and not require massaging of parameters or settings to work. The only tweaking required should be for optimization. Using geo-reference data such as GeoTIFF and DTED as input can greatly help, as it already has all the information about pixel size, height extents, map extents and so on.
#2
08/24/2007 (12:24 pm)
Delta3D's site throws a virus warning in AVG and McAfee when viewed in IE. Strange. It also pops up an ActiveX notice to run in IE. 
#3
Much of your features under "tiling" is already being done by Atlas. Some work needs to be done so that the edges of multiple Atlas terrains blend a bit better, but otherwise Atlas is a very viable solution in this area:
08/24/2007 (12:25 pm)
Tim:Much of your features under "tiling" is already being done by Atlas. Some work needs to be done so that the edges of multiple Atlas terrains blend a bit better, but otherwise Atlas is a very viable solution in this area:
- Atlas is already memory paged, not just in whole "tiles" but is smaller bits of each tile called a "chunk," this makes it more memory efficient
- Game content is not tied to when an Atlas chunk is swapped in and out, but they are governed by network "scoping" rules and thus swap themselves in and out. However, the server still needs to keep all game objects in memory. Some people have begun to look at more client-managed, disk-swapped content
- Atlas terrain streaming/paging is also already multi-threaded so it isn't tied to the game's framerate
#4
I do agree with Mark, some of the requests features listed so far can be done in Atlas in some way, but I think Tim's goal here is to take this from a design level, instead of an implementation level right now.
08/24/2007 (6:33 pm)
I highly respect Tim's approach to this thread--so instead of trying to push "wish list" concepts into the Atlas model, I'd suggest we leave this as an "open sky features list" of a hypothetical terrain model if that makes sense to everyone :)I do agree with Mark, some of the requests features listed so far can be done in Atlas in some way, but I think Tim's goal here is to take this from a design level, instead of an implementation level right now.
#5
08/24/2007 (6:45 pm)
Support for flowing liquid features (rivers, waterfalls, lava streams etc.) would be *very* nice. ;)
#6
Actually glad you mentioned that. Waaay back in the stone-age( Back when the cool new featiure was Mode-X, not DirectX), actually tried doing up a lil rpg engine from scratch.
What I did back then was keep a set of heirarchal listings for data kind of like this:
Class GlobalMap
{
maparea * currentzone;
maparea * boundaryzones[8];
}
Class maparea
{
assetlisting * objects;
tilelisting * visualtiles;
}
Class tilelisting
{
char * bitmap;
char * hieghtmapmod;
}
yadda yadda yadda. Point being, if you want to start adressing that type of thing as a part of the terrain solution, it's best to take the design up to a higher order of the design tree, and incorporate true zoning before terrains even touched... at that point, the solutions part and parcel of the whole design philosophy.
Just my .02 on that one.
08/24/2007 (7:04 pm)
* Game content (trees, buildings, NPCs and other objects) can be associated with a tile and also swapped in and out of memory as the user moves around.Actually glad you mentioned that. Waaay back in the stone-age( Back when the cool new featiure was Mode-X, not DirectX), actually tried doing up a lil rpg engine from scratch.
What I did back then was keep a set of heirarchal listings for data kind of like this:
Class GlobalMap
{
maparea * currentzone;
maparea * boundaryzones[8];
}
Class maparea
{
assetlisting * objects;
tilelisting * visualtiles;
}
Class tilelisting
{
char * bitmap;
char * hieghtmapmod;
}
yadda yadda yadda. Point being, if you want to start adressing that type of thing as a part of the terrain solution, it's best to take the design up to a higher order of the design tree, and incorporate true zoning before terrains even touched... at that point, the solutions part and parcel of the whole design philosophy.
Just my .02 on that one.
#7
Basically what I'm saying is that Torque already does a lot of object-swapping and I think any improvements to it could be made within the structure of Torque's Ghosting system.
On a completely different note. What is the current technical limitation(s) from simply expanded the size of the Legacy terrain system? Why is the height map sized fixed at 256x256? Can a larger "composite" terrain be built by tiling many height maps together?
08/27/2007 (8:15 am)
At this point we should probably clarify what kind of object swapping is desired. Right now, Torque already does a lot of Object "scoping" that isn't tied to any terrain, just a distance around the player. For GameBase-based objects (they have datablocks) this makes for really efficient ghosting. Where the ghosting could be improved for a large-scale RPG game is in the "static" objects of Interiors and TSStatic's. However, simply removing the ScopeAlways network flag from a TSStatic makes it ghost like all other objects.Basically what I'm saying is that Torque already does a lot of object-swapping and I think any improvements to it could be made within the structure of Torque's Ghosting system.
On a completely different note. What is the current technical limitation(s) from simply expanded the size of the Legacy terrain system? Why is the height map sized fixed at 256x256? Can a larger "composite" terrain be built by tiling many height maps together?
#8
Big 'here here' on the following:
* Dynamic lighting
* Self Shadowing
08/30/2007 (3:12 pm)
MMmmmmm....Big 'here here' on the following:
* Dynamic lighting
* Self Shadowing
#9
Its the lightmap based lighting (DIF, static DTS, self shadow) that does not work on Atlas2
08/31/2007 (1:20 pm)
Dynamic lighting works on terrain (Atlas as well as legacy)Its the lightmap based lighting (DIF, static DTS, self shadow) that does not work on Atlas2
#10
Just thought you'd want to know.
08/31/2007 (5:54 pm)
From the TGEA 1.0.3 changelogQuote:- atlas terrain lightmaps
Just thought you'd want to know.
#11
08/31/2007 (8:14 pm)
Awesome. =) 
Torque 3D Owner J.C. Smith
Personally the things I'd like to see from Atlas are:
In the I can't believe it can't do this yet category
- React to sunlight
- Allow lightmaps to be cast on top of it
- Self shadow
In the "wouldn't it be great" category
Have the ability to use a different detail map for each tile type when using blended terrain. I've made a few attempts at doing this and never could get it working. This could be used to add bumpy surfaces to rock cliffs, grassy textures to grass or pebbles to a road, etc.
In it's current state atlas is cool and all, but I can't imagine anything but a cartoon or simple graphics game shipping without the ability to have shadows from their buildings. It's easier said than done, and it's the reason a lot of people are sticking with the very dated Legacy terrain.