How to create a full-scale city in Torque?

#1 Yes we made a simple city demo. You need to make your own world database. Then you need to make city blocks that click together like lego. Using your world database you then edit what actual city blocks reside in each grid square. Also, like GTA limit your texture size and reuse textures. You'll probably need some sort of disk caching system as well to stream new assets in place rather than holding all items in memory.

#2 Thanks Andy. Thats the kind of system I was planning on implementing, but I got a little confused by the different formats torque accepts. So did you use DTS or DIFs for the buildings? Should each city block be one unique mesh or are the blocks basically pointers to an array of static meshes?

#3 Andres torque was not designed to handle a dense city environment. you're definitely going to want to implement some kind of high-level scene management system where city parts can be tagged and referenced for reuse. rather than going for something like gta:sa where you have a large streaming world, youre much better off going for something like gta3 or vice city where the entire city is divided into blocks and each block is loaded separately.

#4 I have to make a massive forest, so its sorta the same thing for the city. My question should i use the fxfoliagereplicator or should i make my own database. I've already have tried to put hundreds of trees together and that jut slows it down. Also when you say database you just mean another folder in the shapes that can be opened in torque???

#5 Mikey, I am fairly new to torque but I'll give you my understanding of the level caching system. You create the level in a modular fashion so there are basic building blocks that can be pieced together. For the case of a city, each building could be concidered one of these blocks, a piece of street/sidewalk another, traffic lights, etc. You then lay out the city inside toque either in a seperate file or on another scene (is that the word?) from the main level. Within script you iterate through all the items in the scene and output their values to a text file (.i.e. item type, model, position, scale, rotation, any game parameters, etc.). This file will be the level cache or database which the engine streams from. Then starting with an empty world, the game engine will calculate the players position, facing angle, etc. to determine which objects should be visible and then load those onto the scene. Any other objects not flagged during this check will be unloaded from memory or at least culled from the viewport. A good amount of this could be pre-calculated, I assume. Im not exactly sure how one would implement this in torque, but thats the basic idea. If I am totally off on this assumption, please feel free to correct me.

For a massive forest I dont think that would be too useful, unless you needed pinpoint accuracy of the tree placement like for a VR simulation. For a forest is just like doing grass or other details which can be procedurally generated from code. I would assume you need to optimize the LOD meshes and maybe have them swap out into 2D billboards once they are too far from the camera. I haven't used fxfoliagereplicator, so I can't really help you there, though.

#6 For a forest, Ben Garney has the answer with his Forest Pack.

However, it's done in his spare time, and I have no idea on the status at this point.

Andres, make sure you make your modular system based on powers of two (like 128x128, etc) and change your grid settings to powers of two (8,8,8 is a good size, though you can go larger if your pieces are larger). then you can go into EditorGui.cs and Editor Gui.gui and change a few "snap to" lines to make it so when you press it moves it on the grid. You can also change rotation to be at nice intervals, like 15, 45, 90, etc.

#7 Andres the technique you have outlined above would seem ok, but theres a few things that would make the approach impractical, especially in torque. Actually, I have been researching techniques which can be used for rendering a real-time city environment myself lately. Im considering the idea of implementing a rendering routine which would be tailored for rendering city environments and releasing it as a product. it's very tricky to get an optimized dense city scene, which is why you don't see many indie games with them. (and please no one post a plug for beyond virtual, ive tried the starter kit and the performance is so lousy id feel guilty recommending it to anyone)

the main problem with your proposed system is the memory management. I'm not sure, but i think it would be very inefficient to load and delete object memory often like that. this is not the way objects should be culled.

one thing to consider is the player usage. imagine a city scene with a lampost. the player can turn and look at the lampost and turn away. if the player wanted to, he/she could keep turning in complete circles over and over again at some speed. with a system where objects are loaded and deleted this would be a helluva load on the system, having to dynamically load and delete objects whenever the player decides to turn.

youll want to write a system which performs the balancing act of not only rendering a city, but allowing the player to easily move and rotate about without too much processing overhead or RAM use. the idea is to have all the objects loaded in memory which can possibly be seen, use a high-level system or some kind of hierarchy to determine which objects can be seen at that particular instant in time, and clip them against the view frustrum.

when it comes to torque and torquescript, this would be even more difficult. individual poly culling is impossible thru script and object culling remains undefined as well. one thing I've thought about is manipulating torques "scoping" mechanism programmatically by displacing objects far away from the client if you know they shouldnt be considered for rendering. understand that true scene culling can only be done at the api level in directx or opengl. anything done at the script level would be some serious script hackage. btw, hacks are a good thing as far as I'm concerned. :)

#8 Eric: Thanks. I didn't know about the grid snapping, sounds useful.

Sean: I understand there would be memory overhead. From what I've read about how the pros do it is to store different LOD textures in memory and swap them out. So the most common textures (character model, street, brick, etc.) always stay in memory. Then all the unique textures have a few versions at different details. The low resolution version may only be 32x32, but its enough to look convincing from a far distance. Then you swap the textures out at run-time depending on which "zones" the player is in (precalculated to avoid excessive line-tests). The actual meshes could probably stay in memory and just have thier visibility off. I dont see why it would be an issue, especially with modern 3d cards. I was more interested in the "correct" way of doing it in Torque.