Updating Terrain/buildings -- ideas
by Luc Jordan · in General Discussion · 07/22/2002 (5:11 pm) · 0 replies
First off, like a lot of you here I plan on making a game with Torque. Some Day, when my life will allow it. Meaning I don't even own a Torque license and shouldn't be allowed on the site, much less allowed to post, so I should really just crawl into a hole and die but, having said that, I have some ideas, musings, and ramblings that I thought I would share with you.
The Torque engine's strongest point graphically has been its terrain engine. In fact, that and the excellent networking are what qualifies it as a triple-A engine even when stacked up against the latest unreal builds and competitors like NDL and Renderware. However, newer games are challenging the Torque engine for dominance even in the area of terrain.
There are several problems with the current method used for terrain. Well, problems is entirely the wrong word. Rather, looking towards the future, there will BE problems if things are not changed:
1)It is a fixed size that repeats. Due to the method used to construct terrain files and load them into memory, it is not really feasible to enlarge this size by much.
2)The lighting. Lightmaps must be rendered. This can complicate things for many reasons; if you want a day/night cycle, for instance, you either do without shadows or you leave the static shadows and hope no one notices or you render multiple shadowmaps. None of these solutions is very ideal.
3)Map construction on load. This is tied in with the basic way terrain is created in Torque, but eventually -- perhaps not for a long time but eventually -- this will have to go. The problem is that you have to load it all into memory, you take the ruleset and the heightmap and create the whole map and load it into memory. This is a great solution for Tribes but it is not a very general-purpose one, for instance for a Flight Sim or for an MM game. This means that if you want a bigger map, the loading times will become astronomical, and cutting it up into chunks and creating/loading it piece by piece as necessary will create the same type of periodic slowdowns people saw in Morrowind. Even if the terrain fiels were created on installation and loaded fully constructed, that would not be an ideal solution.
Meanwhile I was looking at the benchmarks for the ATI 9700, and I realized -- the future is getting here FAST. As crazy as it sounds when a single game has yet to come out that *really* uses DX8, DX9 compatible cards are coming out in full force, and there are rumblings that Microsoft will be creating their next OS to be, at a minimum, DX9 compliant.
Well, the more I thought about it the more I came to the conclusion that the one thing in Torque that must be improved is the terrain engine. Someone, maybe GG, needs to see about the future of the terrain engine as quickly as possible.
Other things -- for instance, the way buildings are imported, or player models -- are secondary, and anyways it's pretty easy to add bump mapping to a weapon or vertex shaders, etc. But the terrain is a much hairier issue. It's Torque's real ace-in-the-hole, it's a much larger and more complex system than the interiors or player models.
But issues like terrain complexity, map size, terrain size, loading issues etc -- those are going to have to be addressed eventually.
Now, if DX9 is going to be accepted and games actually written for it, we have Hardware Displacement Mapping available to us. Why not use that for the basis of the terrain engine?
I see HDM integrating into Torque very nicely. I mean, the idea is that it does in real-time what Torque right now does partly at the loading screen and partly in-game -- it takes a heightfield and converts it to a landscape, and it adjusts the LOD on the fly to get the highest quality at the lowest processor cost.
Admittedly, I don't know what issues might be involved in integrating a rule-based terrain system with an HDM-based map -- is it possible to apply those rules on the fly, etc -- but if it could be made to work, it would be a Holy Grail for a terrain engine. Basically, the map would be as large in size as a Tribes 2 map is to download -- you have the heightmap and the rules -- but that's as large as it would ever be, really; as long as you have the terrain tile textures, the heightmap and the rules for applying the textures that's all you would have to load into memory. (Actually, wouldn't the textures and heightmap go straight to the vid card? Well, anyways, we're talking huge savings). The video card would handle everything else. It's insane, but this is something that would look better AND take up less space.
A 1024x1024 256-color bitmap is 1MB in size. 4MB for 24 million colors. I don't know how much precision you would need for a heightmap -- 256 shades of gray, for instance, would probably be enough -- but either way, that's an extremely complex map for that amount of memory space, since that's all the bigger it would get! It would never take up as much space as the terrain mesh does. Just think of the memory savings DAoC would have using HDM. :)
What do you guys think? I'm obviously just thinking aloud and throwing out some musings here, so feel free to deconstruct me or just ramble on your own.
The Torque engine's strongest point graphically has been its terrain engine. In fact, that and the excellent networking are what qualifies it as a triple-A engine even when stacked up against the latest unreal builds and competitors like NDL and Renderware. However, newer games are challenging the Torque engine for dominance even in the area of terrain.
There are several problems with the current method used for terrain. Well, problems is entirely the wrong word. Rather, looking towards the future, there will BE problems if things are not changed:
1)It is a fixed size that repeats. Due to the method used to construct terrain files and load them into memory, it is not really feasible to enlarge this size by much.
2)The lighting. Lightmaps must be rendered. This can complicate things for many reasons; if you want a day/night cycle, for instance, you either do without shadows or you leave the static shadows and hope no one notices or you render multiple shadowmaps. None of these solutions is very ideal.
3)Map construction on load. This is tied in with the basic way terrain is created in Torque, but eventually -- perhaps not for a long time but eventually -- this will have to go. The problem is that you have to load it all into memory, you take the ruleset and the heightmap and create the whole map and load it into memory. This is a great solution for Tribes but it is not a very general-purpose one, for instance for a Flight Sim or for an MM game. This means that if you want a bigger map, the loading times will become astronomical, and cutting it up into chunks and creating/loading it piece by piece as necessary will create the same type of periodic slowdowns people saw in Morrowind. Even if the terrain fiels were created on installation and loaded fully constructed, that would not be an ideal solution.
Meanwhile I was looking at the benchmarks for the ATI 9700, and I realized -- the future is getting here FAST. As crazy as it sounds when a single game has yet to come out that *really* uses DX8, DX9 compatible cards are coming out in full force, and there are rumblings that Microsoft will be creating their next OS to be, at a minimum, DX9 compliant.
Well, the more I thought about it the more I came to the conclusion that the one thing in Torque that must be improved is the terrain engine. Someone, maybe GG, needs to see about the future of the terrain engine as quickly as possible.
Other things -- for instance, the way buildings are imported, or player models -- are secondary, and anyways it's pretty easy to add bump mapping to a weapon or vertex shaders, etc. But the terrain is a much hairier issue. It's Torque's real ace-in-the-hole, it's a much larger and more complex system than the interiors or player models.
But issues like terrain complexity, map size, terrain size, loading issues etc -- those are going to have to be addressed eventually.
Now, if DX9 is going to be accepted and games actually written for it, we have Hardware Displacement Mapping available to us. Why not use that for the basis of the terrain engine?
I see HDM integrating into Torque very nicely. I mean, the idea is that it does in real-time what Torque right now does partly at the loading screen and partly in-game -- it takes a heightfield and converts it to a landscape, and it adjusts the LOD on the fly to get the highest quality at the lowest processor cost.
Admittedly, I don't know what issues might be involved in integrating a rule-based terrain system with an HDM-based map -- is it possible to apply those rules on the fly, etc -- but if it could be made to work, it would be a Holy Grail for a terrain engine. Basically, the map would be as large in size as a Tribes 2 map is to download -- you have the heightmap and the rules -- but that's as large as it would ever be, really; as long as you have the terrain tile textures, the heightmap and the rules for applying the textures that's all you would have to load into memory. (Actually, wouldn't the textures and heightmap go straight to the vid card? Well, anyways, we're talking huge savings). The video card would handle everything else. It's insane, but this is something that would look better AND take up less space.
A 1024x1024 256-color bitmap is 1MB in size. 4MB for 24 million colors. I don't know how much precision you would need for a heightmap -- 256 shades of gray, for instance, would probably be enough -- but either way, that's an extremely complex map for that amount of memory space, since that's all the bigger it would get! It would never take up as much space as the terrain mesh does. Just think of the memory savings DAoC would have using HDM. :)
What do you guys think? I'm obviously just thinking aloud and throwing out some musings here, so feel free to deconstruct me or just ramble on your own.
About the author
