Creating Cityscapes

#1 The visual appearance of a city, a city landscape, can be accomplished if I understand your question. Although I have not tried this myself yet, I have given it a lot of thought. Try using the mission object sky. It uses several sky textures. If I remember, there are four base textures that you can place a city image underneath the sky line. One problem, the sky in these textures are distorted so you may have to find a technique to distort the city image also.

Good Luck.

#2 Actually, I was thinking more along the line of creating something l similar to Grand Theft Auto. I created some buildings using Maya, howerver, I can't seem to figure out how to import it into Torque.

#3 You want to build the city as a number of DIF files (i e, in QuArK or a similar "MAP" editor). You want to place portals aross the streets, stretching between the house corners. That way, you can get culling to work for you, and reduce the depth complexity and overdraw you'd otherwise get in a large city.

#4 Portals don't work unless they are enclosed (like a door to a room).

#5 Is there a format, I can export from Maya and import into Torque? I noticed from an old post, someone mentioned a plug in call Maya2DTS. But this only works for earlier version 5 of Maya (which no one seems to use anymore).

#6

Quote:Portals don't work unless they are enclosed (like a door to a room).

The solution is usually to either put a big portal across the top of the buildings (and make all the other portals connect to that), or to build an invisible (but sealing) roof on the town, and paint it using the skybox. Exactly how that's done in stock Torque I don't know yet -- worst case, you have to do it yourself.

Regarding maya exporter: check out the tutorials for art, right on the torque SDK site. Beware, though, that "DTS" shapes are for actors like vehicles and players, and decoration. They do not allow you to create collision meshes that are suitable for architecture.

#7 I've experimented with portalling open ceiling areas, and it didn't seem possible. An "invisible" ceiling causes strange redering and prevents any natural sunlighting from affecting the level, which presumably you would want. I never tried sticking an actual portal object over the top of the city... but I assume given the way portals work, you cannot use a portal as the connecting piece for another portal.

Also, for a large generic city, .dts objects are entirely suitable as long as you don't plan on going inside the building. There is no sort of backface or occlusion culling done by default, though you can add your own occlusion routines.

Without modifying rendering, the best you can do is put together the city in pieces, so you get frustrum culling benefits, and make good use of LOD and fogging. In the end though, TGE does not have the most modern or efficient renderer, so you're probably not going to be able to pull of a huge cityscape without some manner of smoke and mirrors.

#8 There's also a problem in TGE with it having to track too many objects. I've had good luck with sectioning the buildings off into city blocks (each block = 1 DIF)--but your mileage may vary.

#9 If the zone builder can't deal with "invisible" sealing geometry, then that ought to be added. That shouldn't be a hard feature to add to anything that already supports portals. A DMF city with portals would be a LOT more efficient (CPU-wise) than buildings made out of DTS meshes, and would probably scale a lot better to long viewing distances, too.

#10 Go for it, J. :)

In the scenario you have (ie, a portico or something) it usually makes more sense to put the portals on the walls rather than having a big one across the top. Imagine a roman villa with a courtyard in the middle - you'd put portals on the different arches, not across the top of it.

#11

Quote:
In the scenario you have (ie, a portico or something) it usually makes more sense to put the portals on the walls rather than having a big one across the top.

Think of Daly City. If you haven't been there, think of very dense single-family housing urban sprawl in a mostly rectilinear grid, with very small strips of lawn between the houses. Suppose you stay outside the buildings.

The problem is that, because you're in the street, you have to have a portal (or something) in the sky, else there's no way you can get the portaling system to cull the house behind the house that's right in front of you (and the one behind that, ...). You have to place portals at each intersection to make an urban scene like that work. Here's where the tools problem comes in: for those portals to actually create any zones, you have to "seal" the sky somehow.

Good-old Doom I (you know, before real 3D) had a property where any piece of geometry could be marked "skybox." It's slightly bewildering to me that the Torque art path doesn't.

My game prototype is all in the woods and meadows, though, so I'm unlikely to add this on my own just yet :-)

#12 Dense urban visualization is it's own special problem. If you can make assumptions (like Doom) you can get performance wins. If you're just flying overhead it's a lot harder. It's also a wholly specialized area of design - Torque isn't designed to do a dense, constrained environment, so the default stuff that comes with it doesn't optimize around that.

You could always write a custom object to render in a specialized way for that kind of scene - sort of like Atlas is specialized for rendering terrain efficiently - and be able to run very performantly.

#13

Quote:If you can make assumptions (like Doom) you can get performance wins. If you're just flying overhead it's a lot harder.

No doubt.

Right now, we're talking about a street scene, with infantry that doesn't fly.

DIF has all of the capabilities needed, if we could just make it match up a "ceiling" portal with a "wall" portal as closing geometry. The portal-based rendering will do the rest.

Even better would be if it did the good-old Doom I trick of marking a surface "render as skybox" -- again not hard to do, and solves the problem nicely. SpaceMonkey could probably implement that himself, if he tried.

#14 Although it would take some time, either converting 3ds max objects into DIF, or just use DTS objects based on the models from www.3drt.com might be the way to go.

Although the models themselves aren't perfect, they're great starters... and the textures are also great starters.

As much as I hate to give out trade secrets like this, it's actually the best way to go, at least when it comes to an indie getting started.

#15

Quote:just use DTS objects

You understand the problem with having a grid of 50x50 DTS objects, each of which has large faces that can fill the screen, right? And you understand why a properly portaled DIF file would could that problem, right?

#16

Quote:
As much as I hate to give out trade secrets like this, it's actually the best way to go, at least when it comes to an indie getting started.

I really hope you are sarcastic :)

#17 If your buildings actually have insides which can be entered then i understand how portals are critical,
but if they're basically just exteriors, i don't understand how they'll help.

we're using a lot of urban environments where i work;
for now our approach is just to LOD the heck out of DIFs,
but for the future we're thinking of implementing antiportals, which seem like the right tool for the job.

#18 Like I said - a little bit of custom code will go a long way in this scenario. If you can make assumptions you can get performance wins.

Implementing an antiportal system should be pretty easy - see how occlusion culling is done against terrain for an example of how you'd hook it in.

Doing other scene management stuff might also be smart.

The absolute key here is to analyze, analyze, analyze - you don't want to invest three weeks on this stuff only to find out that it runs SLOWER!

#19 @stefan - :P

@hplus - There are several ways to solve this problem.

BSP Trees

LOS Culling with visibility tables - Reduces LOS queries by as much as 80% and is highly relevant to your application.

Fast Occlusion Culling for Outdoor Environments - Also highly relevant.

Occlusion Culling

#20 I worked with a engine at large studio on a unnannounced title several years ago. This is the type of pipeline I miss in general because I like building assets in real 3D apps as opposed to CSG methods. My memory is a little fuzzy of the details but here is the gist of things.

Created assets in Maya with LOD's and collision objects. Export out assets into the engine straight from Maya. Ive already done a pipeline that let me build a MIS out of DTS's in Maya using the level tools but its kinda ghetto now id have to rebuild it to use Maya 8.

I believe octrees were used but im not 100% sure in this particular engine. I think they were really culled based on distance and the viewing fustrum. Also I think they assets were tagged with a metric to what was really important to have right then and now and what could be faded in. Then the assets were streamed in(first time we ran the app if the geometry was new it would rebuild the stream data before running the actual game) based on what was visible. Even with caching not really implemented and a brute force visibility it worked pretty well unless you were moving rather fast or you whipped the camera 180. Just with that we were playing missions in an open city. I dont remember if we use a different approach for interiors but the assets were built the same way and we were able to go inside without load times.