Scene culling

#1 Yes, portals are important to Torque. here is a very thorough site that documents how to use portals to make zones, and use detail brushes to stop the fracture of your map.
But, to be honest, 1700 faces is nothing, it shouldn't cause any problems... unless you've done some bad things, like use a lot of different textures (slows the renderer down because of the state changes), use giant textures (large textures are just plain slower than small ones, even if they are all in video memory), or make your map in such a way that the faces get split into tons of little faces.

http://holodeck.st.usm.edu/vrcomputing/scenebuilding/chapter05.shtml

#2 1700 faces, brushes, triangles...? How are you getting the count?

#3 Even if there were errors in the interior the fact that the player is facing a hill and the camera can't see the object should not the engine cull everyting beyond the hill?
There are 6 textures used for the whole thing. Does the engine not sort polys in texture order?

Thanks for the link JMac I'll have a look.

@Ben Map to Dif reports this.

STATISTICS
- Total brushes: 250
+ structural: 250
+ detail: 0
+ portal: 0
- Number of zones: 1
- Number of surfaces: 1727

#4 Terrain does occlude objects when everything is done properly, and the textures you are using certainly doesn't sound as if it were the issue, so I'm betting here that your problems would be alleviated with proper use of portals, and/or a good check that the model exported well and doesn't violate any major requirements of TGE .dif objects.

#5 I can't see how to make portals in Hammer yet. Link to tutorial for torque seems to be broke. The models are just boxes for now, Im laying out the size and placement for the artist so the geometry shouldn't be a problem I check every dot and they are all connected,(no leaks)
Does it matter that the majority of the map is under the terrain?

#6 If you're not portalizing, then all of the map will be rendered all the time. This can be a performance hindrance! Simply having geometry under the terrain isn't a big deal, of course.

#7 Yeah Ben I assumed the portal thing and soon as I get some info on that I'll change it, why does it still render when it's totally obscured? If the camera is facing a hill or a wall every thing beyond that should not be rendered if the scene is rendered front to back. I looked in the engine for scenegraph sorting but can't find it.

#8 Howard,

I'm not sure you understand how the interiors work. Each portalized segment of the interior is treated as a discrete chunk of geometry, drawn in a single call to OpenGL. It would be complex and inefficient to cull individual triangles; it is up to the content creators to produce content suitable for the engine.

In the days of Quake 1, it made sense to check each triangle; in the days of fast GPUs, it makes a lot more sense to submit batches of geometry to the card and let it deal with it. Naturally, that requires that you strategically fragment your batches, which is what portals are defined for.

This is basic stuff - I'm surprised you've been on the site so long and it's never been an issue till now.

#9 I'm not talking about individual triangles Ben. If you have an object with a bounding box you can quickly cull the entire object if it doesn't fall within the view frustum or is obscured by another object. The entire interior can be rejected for render reguardless of it's size or the number of portals if it can't be seen. The engine must be doing something like that because if I turn the camera away from the object the framerate goes up. So that brings us to your definition of a portal. What do you define a portal as ? Is it the bounds of the object ? Is it an opening in the object? Is it each room of the object? Is it the Quadtree, OctTree nodes list? Define portal and how do I make one?
The subject never came up before because we never had this size of an interior. A one room shack has never been and issue for our testing, now that we have an object with some size the problem appeared. And thanks once again for reminding me of how ignorant I am.

#10 Howard,

holodeck.st.usm.edu/vrcomputing/scenebuilding/chapter05.shtml#_por

#11 Torque actually does frustum culling and culling of objects covered by terrain.
Maybe this resource explains stuff: www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=3751

Maybe the problem arises because some of the interior is under the terrain, while another part is not. However that wouldn't explain the fps drop, when you're looking away from the interior, i.e. the interior should be culled by frustum culling.

#12 @Stefan Lundmark thats what I would expect portal is. Unfortunately we dont use Quark. I just looked at Cartography shop and I dont see any tool in there for defining a portal either.

@Stefan Rampp You must have misunderstood, we get increase in fps when NOT looking toward the interior. The fact that some is under the terrain may be an issue, not sure how torque handles that. If it's under then there are no occlusions and would render all, the portals should stop that. Do you know if the dif files have a bounds box for fast check against frustum?

Thanks to both of you for help.

#13 Ah yes, I should take more time to read texts... ;-)
As far as I know, interiors, like all other objects have a bounding box, of which a representation can be seen in the world editor. I'm not sure how Torque handles raycasts against of a terrains underside, since this is probably happening with underground interiors. Have you tried to move the whole interior above ground to see if you get a fps drop then? If you do, you've probably found the problem. A look into TerrainBlock::castRay could also shed some light into this issue.

#14 Howard

In Cartshop choose Torque from the Object Category list and portal from the object list. Click once on the map view in a roughly suitable location and a small square appears. Press enter and the small square turns into a default sized portal brush. Move/resize as required and you have a portal. In the textured view they are a bright red/transparent chequer style with PORTAL written all over them.

#15 @David, you mean "Object Category" on the right hand side of the display? Torque is not listed.

#16 Figured out I needed the demo of the plugin as well. I see the portal creation but gives me error "File version not supported". At least it's there.

#17 The demo of Cshop will not allow you to save your work, so I would guess there is something in Cshop that would disallow you from exporting as well.

#18 A trick I've used to solve this, besides just proper portals: LOD0 contains your entire level, and is viewed only when the player is close. Thats the LOD that requires proper portals. LOD1 however, pixel set to just a bit further away, you can completely cut out everything that is below ground, leaving only the above ground entrance. There's probably 80% of your triangles, completely gone from the scene. Then of course LOD2+ you're cutting down on the details of the above ground aspect. With this method, I was able to place huge amounts of these half and half levels.
Another minor trick for city levels in general with any buildings you have that are not enterable, and are basically just textured boxes. Fill them with terrain, as close as you can. eg, grab as many terrain triangles as you can that are 100% inside that building, and pull them up to just inside the top. Basically, you're making a mountain with 90 degree sides. Doing this will allow the fairly awesome terrain occlusion code to cut out quite a bit of your city, as neither dts nor dif objects will occlude anything behind them (stock that is).
Cheap tricks, but used properly with a properly designed city, you will be amazed at the additional amount of candy you can now populate the place with.

#19 @ Howard - Sorry - I took it from your post that you were using CShop to model :/

#20 @Eric: so are you saying that making these 90 degree mountains are more efficient in culling than having a simple block per skyscraper on regular terrain?