DTS objects as terrain. Any thoughts?
by Per Rasmussen · in Torque Game Engine · 04/21/2004 (1:10 pm) · 31 replies
I was thinking: Is it possible to disable the normal terrain and instead use large objects as terrain block. That way you could have large (non-repeating) terrain.
Issues:
Rendering speed: If the blocks are not too large, the built-in frustum culling will make sure that only the visible blocks will be rendered. There will not be any CLOD, though.
Collision detection speed: I assume it will be somewhat slower, but I do not know if it will be significant (?).
Editing: You will not be able to edit the terrain in-game. You can, however, make it in your 3d modeller and then cut it into appropriate slices.
Have I missed something? Would this approach even be possible? Please tell me what you think.
Thanks in advance,
Per Rasmussen.
Issues:
Rendering speed: If the blocks are not too large, the built-in frustum culling will make sure that only the visible blocks will be rendered. There will not be any CLOD, though.
Collision detection speed: I assume it will be somewhat slower, but I do not know if it will be significant (?).
Editing: You will not be able to edit the terrain in-game. You can, however, make it in your 3d modeller and then cut it into appropriate slices.
Have I missed something? Would this approach even be possible? Please tell me what you think.
Thanks in advance,
Per Rasmussen.
About the author
#2
04/21/2004 (1:41 pm)
Please elaborate. Why would you not want that? 
#3
Of course anything is possible and you might get away with using that technique :) What I'm saying is that the performance loss will probably be pretty large.
04/21/2004 (1:51 pm)
Mostly because(as you mentioned yourself) culling get's a bit behind and colission detection won't work as fast. It's just not optimized for the purpose.Of course anything is possible and you might get away with using that technique :) What I'm saying is that the performance loss will probably be pretty large.
#4
Things may work much better with the new Torque hability to use .3ds shapes! :m
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5502
But I have not tried that yet...
04/21/2004 (2:38 pm)
Well, we used DTS shapes for terrain modelling. We needed to model a real highway, 14km, so the torque terrain was not enough. We have 4 big .dts shapes (the more there are, the better), but things are pretty simple. The collision, for example, is limited to the road, it does not include adyacent terrain. We get about 20 fps, with 10 car bots driving on the highway.Things may work much better with the new Torque hability to use .3ds shapes! :m
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5502
But I have not tried that yet...
#5
04/22/2004 (3:02 am)
Why would it be better to load .3ds instead of DTS. Does it render faster?
#6
That apparently works betta ;)
04/22/2004 (4:16 am)
Per: Maybe you know this already, but rather use Diffs than DTS.That apparently works betta ;)
#7
04/22/2004 (4:34 am)
Luis: That's a compliment, not a full replacement.. we did have a highway too, and the city walls were DTS.
#8
04/22/2004 (6:04 am)
Burning: Would diffs be better for this purpose? I don't see why. I mean, you can't really take advantage of portals and fast spaceial identification since there aren't any rooms. Or am I wrong? 
#9
04/22/2004 (8:43 am)
One thing to note, using dts, as opposed to dif, dts will not generate any shadows in the shadow map. So your buildings/highways will not cast shadows when you relight the scene.
#10
04/22/2004 (9:45 am)
Being able to use .dts would make it a lot easier to create curved surfaces for say banked turns, loop de loops, and whatnot, right? I'm working on a racing game where we're running into the problem that all of our tracks are very angular because we're using .dif objects. Is there another way of making curves and hills in something like QuArK or would somewhat large .dts objects work better for us?
#11
That's the single reason why you want to stick with the heightmaps. A reasonably detailed chunk of terrain has oodles of triangles. You _need_ CLOD.
A 256x256 heightmap is roughly 130,000 triangles. You don't want to try that with brute force rendering.
04/22/2004 (9:50 am)
Quote:There will not be any CLOD, though.
That's the single reason why you want to stick with the heightmaps. A reasonably detailed chunk of terrain has oodles of triangles. You _need_ CLOD.
A 256x256 heightmap is roughly 130,000 triangles. You don't want to try that with brute force rendering.
#12
04/22/2004 (4:28 pm)
You should use the heightfield for your base rendering and then supplement it as needed with DTS shapes.
#13
Either way, I wouldn't recommend it to anyone who isn't willing to get neck-deep in C++ code and math.
04/22/2004 (5:35 pm)
This is totally contrary to the designed purpose of DTS. It would probably be less work code-wise to create an exporter for an entirely custom 3D object model type that is optimized for this purpose, and write a new render/collision/etc class in the engine than it would be to retool DTS to work.Either way, I wouldn't recommend it to anyone who isn't willing to get neck-deep in C++ code and math.
#14
Btw, could you specify what would be so bad about my idea (other than what I've already descriped)?
04/23/2004 (3:48 am)
Alex Swanson: In that case, what would you recommend for me? I mean, I don't see any other way to acomplish large (non-repeating) terrain. Btw, could you specify what would be so bad about my idea (other than what I've already descriped)?
#15
04/23/2004 (5:23 am)
But how big is your terrain? Our highway is 14km long and we have no problems moving it! :m And there are no optimizations... no LOD, just 5 pieces of terrain... It would work much better with LOD in each piece and more pieces.
#16
Only if you can't see the divisions between pieces. The sort of LOD you get from DTS meshes would introduce cracks in your terrain, not to mention some nasty popping.
Per: There are terrain rendering papers out there that explain view dependant LOD with streaming data from the disk. If you need large non-repeating terrain, I'd recommend grabbing a skilled programmer and getting to work on a system that supports paging terrain chunks. Here's a link to get you started: vterrain.org/LOD/Papers/index.html
04/23/2004 (8:51 am)
Quote:It would work much better with LOD in each piece and more pieces.
Only if you can't see the divisions between pieces. The sort of LOD you get from DTS meshes would introduce cracks in your terrain, not to mention some nasty popping.
Per: There are terrain rendering papers out there that explain view dependant LOD with streaming data from the disk. If you need large non-repeating terrain, I'd recommend grabbing a skilled programmer and getting to work on a system that supports paging terrain chunks. Here's a link to get you started: vterrain.org/LOD/Papers/index.html
#17
Because of this I had to consider possible alternatives and that is what spawned this thread.
04/23/2004 (9:08 am)
Mark Mozynski: I know. The problem is that this apparently is extremely difficult to implement in torque. As you probably know the documention on terrain is non-existing and it is therefor very hard to make (correct) changes to it. Because of this I had to consider possible alternatives and that is what spawned this thread.
#18
What I'm suggesting is that you rip out the existing terrain and start a new one, with a newer and friendlier algorithm.
The fact is, for a large, detailed terrain, all the best algorithms the graphics community knows depend either on heightmap-type fields, or something called irregular triangular networks (which I wouldn't suggest here).
You're probably not going to find alternatives, since the researchers really haven't come up with any that have proved out to be viable in realtime.
Now, if you've got a more restricted problem, like the flat road example Luis is mentioning, then we might be able to talk about alternatives.
04/23/2004 (10:25 am)
I know. I probably wouldn't suggest making changes to the existing terrain code to support this either, especially not for someone new to Torque.What I'm suggesting is that you rip out the existing terrain and start a new one, with a newer and friendlier algorithm.
The fact is, for a large, detailed terrain, all the best algorithms the graphics community knows depend either on heightmap-type fields, or something called irregular triangular networks (which I wouldn't suggest here).
You're probably not going to find alternatives, since the researchers really haven't come up with any that have proved out to be viable in realtime.
Now, if you've got a more restricted problem, like the flat road example Luis is mentioning, then we might be able to talk about alternatives.
#19
1) DTS objects only support up to 8 collision brushes per object (that is, 8 convex polygons), this means that unless you build the terrain out of *thousands* or little DTS shapes, you will have a tiny terrain, or a terrain with very innacurate collision.
2) Major rendering changes would need to be made to have that many dts models render efficiently.
4) They do not cull visibility.
5) They do not cast or recieve shadows.
6) Even with LOD, the rendering isn't as optimized as the terrain.
DIF would be a much better solution than DTS for terrain creation, if you were only to choose from existing formats. It has:
1) Brush based collision, ensures that all surfaces are colidable.
2) Casts shadows and recieves them.
But still you would have:
1) Culling issues.
2) Even with LOD, the rendering isn't as optimized as the terrain.
3) Major rendering changes would need to be made to have that many dif models render efficiently.
If you wanted the flexibility of working in Max for terrain creation, I really think that the most elegant solution would be to create your own terrain format and give it all the features it needs fromt he ground up. Otherwise, I'd find a workaround for the existing terrain - so that multiple terrain heightmaps could be tiled, or something similar.
I realize what sort of solution you are looking for, but I think that the DTS route will only result in unecessary suffering for you and your team. DIF or some terrain manager implementation with DIFs and DTS detail shapes placed around the world to spice things up will probably get the best results.
04/23/2004 (12:11 pm)
Here's a list of reasons that I can think of:1) DTS objects only support up to 8 collision brushes per object (that is, 8 convex polygons), this means that unless you build the terrain out of *thousands* or little DTS shapes, you will have a tiny terrain, or a terrain with very innacurate collision.
2) Major rendering changes would need to be made to have that many dts models render efficiently.
4) They do not cull visibility.
5) They do not cast or recieve shadows.
6) Even with LOD, the rendering isn't as optimized as the terrain.
DIF would be a much better solution than DTS for terrain creation, if you were only to choose from existing formats. It has:
1) Brush based collision, ensures that all surfaces are colidable.
2) Casts shadows and recieves them.
But still you would have:
1) Culling issues.
2) Even with LOD, the rendering isn't as optimized as the terrain.
3) Major rendering changes would need to be made to have that many dif models render efficiently.
If you wanted the flexibility of working in Max for terrain creation, I really think that the most elegant solution would be to create your own terrain format and give it all the features it needs fromt he ground up. Otherwise, I'd find a workaround for the existing terrain - so that multiple terrain heightmaps could be tiled, or something similar.
I realize what sort of solution you are looking for, but I think that the DTS route will only result in unecessary suffering for you and your team. DIF or some terrain manager implementation with DIFs and DTS detail shapes placed around the world to spice things up will probably get the best results.
#20
Torque's terrain is great but it's not designed for huge streaming environments. I suggest writing a new terrain class if that's what you need. It will be a bit of work, but for any center piece technology (like FarCry's foliage code or Doom3's lighting) you will need custom, game-specific work.
There are plenty of resources available on how to do rendering and collision and general integration into Torque, so it should be a bit of a challenge but not impossible for a skilled coder to pull off.
04/23/2004 (12:15 pm)
Mark's idea is a good one. If you absolutely need huge streaming terrain, you're going to have to write it yourself.Torque's terrain is great but it's not designed for huge streaming environments. I suggest writing a new terrain class if that's what you need. It will be a bit of work, but for any center piece technology (like FarCry's foliage code or Doom3's lighting) you will need custom, game-specific work.
There are plenty of resources available on how to do rendering and collision and general integration into Torque, so it should be a bit of a challenge but not impossible for a skilled coder to pull off.
Torque Owner Stefan Lundmark