Atlas terrain not Culling

#1 This is expected behavior.

Most engines do not do occlusion culling based on terrain elevations... it is a complex issue. If you want to solve it you can start by looking at the existing research.

There was a drawn pixel query added to DX that allowed for a more robust occlusion test, but it sadly isn't implemented in many cards.

#2 One of the "easier" methods to implement is to create a "render blocker" (cull) class that you can place manually as objects in your game. That would allow you to place user controlled culling areas underneath terrain (and even inside buildings and such) to customize your culling how you want.

#3 Did TGE ever cull objects based on Terrain? Or is this something new to Atlas?

#4 @Stephen:

The term used in some engines (e.g. Unreal) is anti-portal.

You can read more here

And google it here

#5 I forgot about Unreal antiportals.

This is a concept that could be adopted for Torque, but like Unreal they would have to be manually placed in a level. This wouldn't be so bad in most cases as you only get wins from this when the aniportal is used to block a large area of the screen... like a mountain range dividing the map.

Someone should take a crack at implementing this.

#6 Thanks for the replies guys:

Is it possible to have a bit more detail regarding this solution?

Quote:One of the "easier" methods to implement is to create a "render blocker" (cull) class that you can place manually as objects in your game. That would allow you to place user controlled culling areas underneath terrain (and even inside buildings and such) to customize your culling how you want.

Specifically which type of datablock and what settings are required?

thank you

addikt

#7 You'd have to write a new class, and integrate it with the rendering and scene management code. It is -not- stock.

#8 Am I right when I assume that TGEA does real culling only within DIFs where it is "easy" to do due to the way the they are constructed?
And the rest bases on oct tree "culling"?

#9 What I would really like to know is if its possible to have a seperate 'view distance' for atlas and objects/models. We want to be able to see the terrain via long distance, but cull objects/models a lot earlier. This will give us the illusion of a large world while maintaining decent performance. Is this possible, has anyone done it, and can anyone do it ? ;)

addikt

#10 This is new turf for me... but I'm looking at SceneState::isObjectRendered and wondering if you could compute the visible area of the bounding box you could then clamp a certain value as "visible". Right now it seems to operate just on frustum culling.

Making this change would cull objects whose bounding box that are partially or totally obscured in the scene wouldn't be rendered. It would take some tweaking and careful world placement, since wide, flat objects whose bounding box extends just above the visible horizon wouldn't be occluded.

You could then apply a similar test to an atlas chunk box....

If this is possible, the question simply becomes...

How could you test how many pixels, or a percentage, of a bounding box are actually rendered in the scene?

EDIT: Ummm... Does SceneState::isObjectRendered apply just to portals? Should SceneGraph::treeTraverseVisit be more appropriate?

#11 Bryce: I believe the LOD selection code that selects the LOD to draw fudges a screen space value you could use to determine the size of object. Although, not sure thats what you need.

#12 We've been busy trying to shove an alpha release out the door, so I haven't had much time to go back to this.

@Phil: That's definately in the right direction, although I'm aiming for how much of the bounding box is actually viewable in the frustum. My theory is that if you cannot castRay to two points of the bounding box, the object is probably occluded, therefore cull it. It's not exact, and you'll still render fully occluded objects with large bounding boxes, and if you have a number of objects within the immediate vicinity that could be quite a number of castRay's.

For instance, fxFoliageReplicator makes the following call:

CollisionResult = gClientContainer.castRay(	FoliageStart, FoliageEnd, FXFOLIAGEREPLICATOR_COLLISION_MASK, &RayEvent);

Could you not apply the same theory to culling and cull all objects that cannot be raycast? Maybe I misunderstand what gClientContainer.castRay does....

EDIT: spelling

#13 I'd strongly recommend doing castrays for occlusion. Better to try and hack in occlusion querying or something. Castrays are slooow.

#14 I got an alpha occlusion test fleshed out engine-wise. It sorta works using bounding boxes, but still renders objects whose bounding box passes the alpha test but is still visually obscured in the frustum. If you have a forest of trees just over a hilltop (like we do)... no occlusion. Having billboarding back in would make the process a no brainer.

Moreover it may eventually solve object occlusion, but not terrain. The way it looks like Atlas chunks are processed, it would require a seperate occlusion pass. Theoretically not a big deal, but it just feels like there should be a better way to handle Atlas chunks than an alpha test on the lowest LOD.

This is just a little too ambitious given the state of our project. :)

#15 For atlas I would take the current system and expand it with a PVS generation process which are used to render terrain chunks and drop ones not visible anyway from this position.
I don't know how much work this actually would be I've to say so it might be a serious amount of work or a piece of cake.

If you restrict it to chunk or subchunks decision areas when calculating PVS, you should actually get a performance boost and not take forever to calculate the PVS.
You could even use this PVS data for object culling early drop mechanics.