Urban Areas
by Will Burgers · in Artist Corner · 06/14/2005 (11:32 pm) · 7 replies
Hey
I'm building a map out of a real-life street, and I'm trying to think of ways to keep the framerate up considering that there are a bunch of polygons in close proximity. For instance, one building has several wings -- if I split the building into several .dif's, is there a way to unload the ones that aren't visible? Is it possible to create something that acts like a portal, but can be used outside? Any insights would help a lot.
Thanks,
Will
I'm building a map out of a real-life street, and I'm trying to think of ways to keep the framerate up considering that there are a bunch of polygons in close proximity. For instance, one building has several wings -- if I split the building into several .dif's, is there a way to unload the ones that aren't visible? Is it possible to create something that acts like a portal, but can be used outside? Any insights would help a lot.
Thanks,
Will
#2
06/15/2005 (7:02 am)
You can unload them, but you'll have to make engine changes for that. You'll also have to play with relighting scenes to load/unload on the fly. Pathing across multiple interiors loaded/unloaded would be a huge pain. I started working on this but decided it wasn't worth it when it came down to the time I wanted to spend on other pieces of the puzzle.
#3
Tip:
At LOD 3 don't even THINK of modelling the windows, doors etc. Just use the textures
At LOD 2 just model the larger doors or features that are quite large (fancy entrances etc)
At LOD 1 model the windows/doors but strip out any internal details unless they can be seen from the outside
At LOD 0 you should have the whole model.
As matthew said, if you can't see the poly, it doesn't get drawn so your quite safe, you can even use this knowledge to your advantage and add large details that hide complex parts of models until you're up close. A simple banner can hide a fire escape ladder for example.
06/15/2005 (7:59 am)
Externally viewed buidlings are usually very tight on tris. I've got some very dense buildings (about 80) but with LOD and clever texturing they don't cause a problem. Tip:
At LOD 3 don't even THINK of modelling the windows, doors etc. Just use the textures
At LOD 2 just model the larger doors or features that are quite large (fancy entrances etc)
At LOD 1 model the windows/doors but strip out any internal details unless they can be seen from the outside
At LOD 0 you should have the whole model.
As matthew said, if you can't see the poly, it doesn't get drawn so your quite safe, you can even use this knowledge to your advantage and add large details that hide complex parts of models until you're up close. A simple banner can hide a fire escape ladder for example.
#4
I know FruitBatInShades has already answered this, but I'd like to hear it from a GG employee - no offense meant FruitBatInShades :).
Are there any public papers describing Torque culling?
Furthermore, do TGE and TSE implement any DIF/DTS/polygon sorting to help Early Z / Hierarchical Z eliminate hidden pixels?
I'm not only concerned about polygon counts, but also pixel overdraw wasting fill rate, memory bandwidth and pixel shaders.
I've asked about a Z only pass in TSE here.
06/19/2005 (11:35 am)
Matthew,Quote:if an object (be it a dif, dts, particle emmiter, etc) is not in view it doesn't renderDo TGE and TSE cull only whole DIF/DTS objects, or does it also cull individual polygons from partially visible DIF/DTS objects?
I know FruitBatInShades has already answered this, but I'd like to hear it from a GG employee - no offense meant FruitBatInShades :).
Are there any public papers describing Torque culling?
Furthermore, do TGE and TSE implement any DIF/DTS/polygon sorting to help Early Z / Hierarchical Z eliminate hidden pixels?
I'm not only concerned about polygon counts, but also pixel overdraw wasting fill rate, memory bandwidth and pixel shaders.
I've asked about a Z only pass in TSE here.
#5
The only sorting the engine does is for translucent objects so that they will blend correctly. TSE does use a z-only pass for several of its rendering effects.
06/19/2005 (3:56 pm)
It is based on the bounding box. If any of the BB is in view then the object gets rendered...if not then it isn't rendered. Now, interiors also have the ability to portal off sections of itself so that if the portal brush isn't in view then the zone geometry attached to it isn't rendered. DTS's don't have anything like this. Backface culling is also on so any of the polygons that are facing away from the camera aren't being rendered (generally about half of the polygons in your object at any given time). Interiors also go through a hidden surface removal pass when they are compiled into a .dif. For example the polygons where a pillar meets the floor will never be seen so they gets removed from the shape. This is automatically done with interiors whereas an artist wuold have to do it manually with a dts. Now, interiors do lose when it comes to texturing. Swapping textures is expensive when rendering and an interior tends to have anywhere from a dozen to several dozen different textures on its surfaces causing pretty heavy swapping. A dts on the other hand tends to be unwrapped to one or two textures so has minimal swapping (although making those textures too big can hurt also).The only sorting the engine does is for translucent objects so that they will blend correctly. TSE does use a z-only pass for several of its rendering effects.
#6
Just thinking of a spaceship sending down a landing party; it might first see the whole planet, which might have different city objects, and as one came in closer to a particular city, it might open that up and start loading low-LOD boxes for buildings, until one started coming in close, then kick in with localized/higher LOD stuff, down to the street level this person is talking about...
is this possible in Torque? If not, where might one consider hacking?
thanks - Chris
07/03/2005 (2:34 pm)
Sub-question on this topic: does Torque support hierarchical LODs? Like this whole street scene might be contained in something else that didn't get loaded until one were in close.Just thinking of a spaceship sending down a landing party; it might first see the whole planet, which might have different city objects, and as one came in closer to a particular city, it might open that up and start loading low-LOD boxes for buildings, until one started coming in close, then kick in with localized/higher LOD stuff, down to the street level this person is talking about...
is this possible in Torque? If not, where might one consider hacking?
thanks - Chris
#7
I can see how your approach would be useful in the situation you describe - once you get down into a city, you don't want to have to draw the whole thing as one object, just the buildings around you.
I do not think that what you are doing would be very difficult - simply loading different scene objects based on your distance from a point or area. The objects themselves could have LOD, but as you got closer, you'd want that city to break up into individual districts, then the districts into blocks, and eventually have those blocks break up into buildings.
This sounds like an incredibly ambitious project from an art asset production standpoint, but the coding side would probably be fairly reasonable.
07/05/2005 (12:34 pm)
Chris, I don't think that Torque supports LOD in quite the way that you are thinking - heirarchical LOD I assume means that as you move in closer, more objects are "spawned" to replace the higher LOD objects (which are larger, more general forms), rather than having one object with continuous LOD.I can see how your approach would be useful in the situation you describe - once you get down into a city, you don't want to have to draw the whole thing as one object, just the buildings around you.
I do not think that what you are doing would be very difficult - simply loading different scene objects based on your distance from a point or area. The objects themselves could have LOD, but as you got closer, you'd want that city to break up into individual districts, then the districts into blocks, and eventually have those blocks break up into buildings.
This sounds like an incredibly ambitious project from an art asset production standpoint, but the coding side would probably be fairly reasonable.
Associate Matt Fairfax
PopCap