Game Development Community

Pros and Cons of tiled difs vs. one big map

by Randy Condon · in Torque Game Engine · 06/10/2006 (4:30 pm) · 13 replies

I'm creating a world that is a series of canals (think Venice, Italy). I've created a variety of .dif files that are 50x50 meter sections of the canals. These can be pieced together to create the canal system.

One construction method is to place these tiles within the mission files.
Another would be to piece them together in QuArK, and export one big .dif.

Can anyone describe the pros and cons of one system over the other, specifically display performance.

Thank you for your responses.

#1
06/10/2006 (4:35 pm)
If you use separate difs, the engine can render them far more efficiently, it can use LODs on the ones farther away, etc... If you use one huge dif, I think you would always end up rendering the whole thing, even if you can't see the whole thing.
#2
06/10/2006 (5:19 pm)
Portals can keep the Dif from being always rendered.
#3
06/12/2006 (1:20 pm)
Portals on a city-like open DIF? Is that pratical?
#4
06/12/2006 (2:57 pm)
Nope, you can't portal an open area with .dif as far as I've been able to figure. Portals block out exterior lighting, so you couldn't use the sun to light the mission, and they need to be sealed off on all sides, so it'd require some crazy mapping hack with an invisible ceiling.

Doing it as a segmented mesh is better, it will allow you to have both LOD optomizations, and general frustrum culling on areas of the city not in view. Probably would want to write a script to place all the pieces of the city though. Some people have even done dynamic level generation using .dif pieces.
#5
06/12/2006 (9:14 pm)
Paul is essentially correct in his conclusion, but not for quite the right reasons:

The optimizations for collision and rendering for dif objects are based on being inside the interior. Portals don't actually block exterior lighting, but they do allow the optimization code to determine what should and should not be rendered based on line of sight within the interior itself.

BSP optimization doesn't do much for you from outside the interior, so in this particular case you can use any of the techniques described above, or even use dts shapes for the outside of the buildings if you do not plan on actually entering the buildings.

Unfortunately, the statement about having "general frustrum culling" from a camera viewpoint outside of an interior is not correct--the only object outside of interiors that does render culling is the terrain itself.
#6
06/12/2006 (10:48 pm)
What do you mean only terrain is culled based on the camera? All .dts objects are culled based on if their center is in the viewport or not, don't .dif objects do any of this? Or are all .dif objects in a mission always being rendered unless they're in a portalled off zone???
#7
06/12/2006 (10:53 pm)
I believe he means culling polygons. such as backfaces and what not.

a DTS isn't rendered if he bounding box isn't in view. But if the bounding box is in view, it draws every polygon.
#8
06/12/2006 (11:45 pm)
Yes yes yes, and so, you could get the same benefit from having the .dif objects chopped up into multiple pieces, correct? If the city is built in sections (multiple .difs) then only the sections in the viewport will be rendered, right? That's all I meant by frustrum culling gains.
#9
06/13/2006 (7:59 am)
Ahh, I thought you meant actual render culling, as in blocking (not rendering things behind a particular object for example). The only object (outdoors) in the game that literally culls (as in objects "behind it" aren't rendered) is the terrain itself.
#10
06/13/2006 (9:27 am)
Note if your objects are expensive to render (eg skinned players) you may get a rendering speedup by doing actual raycasts to select parts of the object's bounding box to determine if it's actually visible, versus just in the viewing frustrum.

we have a lot of player characters in outdoor areas, and in the case when say you're facing a wall and there's a lot of people on the other side of the wall, this provided a large speedup.
#11
06/13/2006 (9:42 am)
Refering to the title of the thread: if you divide your world in different DIFs then these can cast shadows on each other, but the light of one DIF won't affect the others.
#12
06/13/2006 (12:47 pm)
I've found that the memory footprint was greatly reduced by using large difs as opposed to many smaller ones. I was creating a system of connected roads. There are also lots of funny things that can happen with overlapping difs, like lighting problems, for example.
#13
06/13/2006 (9:34 pm)
Well, this generated a whole heaping helping of useful information. I would like to thank all who have responded.

Since I have the 3D tiles created, I'll proceed with a layout and see what transpires. I did create a quick&dirty little utility to place the tiles. I'll also experiment with some simple visible set implementations to limit the amount of tiles displayed.