Occluders

#1 Interiors behind interiors?
Those aren't rendered at all since every modern 3d engine has occlusion culling - so there shouldn't be any problem with that... or am I misinterpreting your question?

#2 If you mean within an interior a properly done and leak-free room should occlude all except what is seen via a portal.

If you mean an interior blocking another interior (like a building in front of another building), I'm not sure. Melv's fxfoliage has an occlusion formula. I don't know about interiors, terrain, etc.

-Eric F, MRT

#3 no i'm refering to an interior standing on the terrain occluding another interior standing on the terrain, no portals involved in this example.

if you turn on wireframe rendering using setInteriorRenderMode(1);
then you'll see that all interiors will still be drawn even if you're standing in front of another interior that clearly blocks the others.

if there was some sort of occluder support in torque, you could place several
invisible occluders in the world which would avoid everything behind it being drawn..

#4 No, Torque doesn't have any occluders. You aren't missing anything.

#5 outside of very very very contrived circumstances there is no way to manually do this in any terrain based engine because unless you are contriving a situation where you are extremely limiting where the player can be it would work.

that said is it a REAL performance problem in your mission have you profiled you mission to be SURE this is a problem?

If it is it would be fairly straight foward to add it to the occusion culling at render time.

That said, this is some of the "negative cruft" left over from tribes2, none of the tribes2 maps I have seen had crap loads of buildings near each other so this was definately not an issue when that code was written the design did not call for it.

Heavly urban environment MIGHT benefit and might not depending on what some profiling and testing might show.

#6 I would think that correct use of interior LOD would make this less of an issue, or not one at all.

-Eric

#7 Sort of, Eric. Situations where you have a lot of large buildings close together are going to benefit the most from occluders. LOD is going to help more with buildings sparsely placed around the map.

I'd wager good money that anyone who's interested in an outdoor big city game (Something like GTA3 or Crazy Taxi) will get a pretty good performance boost from occluder support.

So, it'll probably be implemented once the proper combination of game type and technical skill come together.

#8 well exactly, if you have a lot of buildings packed together occluders help a lot
LOD helps a lot too ofcourse

the good thing about the combination is that if you would look down on the 'city block' you would be so high up that you'll be using lower LODs and when you're on street level the occluders prevent too much high detail buildings to be rendered..

so they compliment eachother perfectly

also, keep in mind that occluders can also be used for objects..
that way all the objects behind buildings won't be drawn either
especially nice if you have a lot of trees behind a building for instance

#9 It'd be reasonably easy to go through the scene graph and create an occlusion volume from each large building, effectively creating a shadow volume that instead of shading just removes other objects from the graph.

Of course, you'd have to be sure that the occluders were actually chosen well, for instance large single structure buildings are fine, but ones with any sort of none uniform outline could give problems.

If youre into a big city game, you probably also want to look into instancing and Impostors.

Phil.

#10 There's a neat and simple extension I've been meaning to try with Torque, it allows you to switch to an occlusion testing mode, render the object's bounding box, and determine if it's visible or not. If it's that important, perhaps you could investigate this as a quick rejection method?

#11 Hardware occlusion culling sounds good, but it tends to cause lots of pipeline stalls, since you need to read back from GL. I haven't tried myself, but I understand it's often easier and faster to do occlusion testing in software.

#12 If you're trying to use a hardware occlusion query try make it so you don't mind getting the result a few frames later. It's not something you should be waiting for then reacting too.

To be fair with more modern hardware there's plenty of bandwidth in the stages before it would get Z-culled anyway, so i'd not worry too much (although I guess as pointed out about it's not hard to fix). Unless you're trying to save some FPS for lesser machines.

#13 I figured it went without saying that it wasn't something that should be done per-frame, and also, the extension specification itself specifies that it is not a replacement for scene graph techniques.

It was just a suggestion. More often than not I see people requesting certain features, and people endlessly pound them with "but you don't need that, just do this." I thought I'd offer an alternative and let the person figure it out on their own for once.

#14 I'm sorry if I came across flamish, I was just intending to point out a potential pitfall with that extension. When it's supported and used correctly, it does work well, though I still think it's easier to go with software.

Here's a good starter reference for software occlusion culling: www.gamasutra.com/features/20020717/bacik_01.htm