question about node's query flag

[steve3d]

I know this query flag means occlusion query. it's a method to optimize the visibility test of objects in scene.

So I have a very big scene, many objects(instanced) in this scene. How can I set this query flag?

 

If I set this flag on every object, the fps increased(sometime), but some time the fps drops below 5.

 

How can I correctly use this occlusion query? should I enable the query for all objects? or only a sub set of objects?

 

If this should be only set to a subset of objects, then what kind of objects should have this flag enabled?

[ulf.schroeter]

If this should be only set to a subset of objects, then what kind of objects should have this flag enabled?

 

As occlusion queries produce a certain performance overhead on their own, activating them for a lot of light-weight (in regard to render load) objects (e.g. with just 50-500 triangles) is not a good idea.

 

The key in this situation is to group several spatially close (simple) objects into a larger cluster e.g. several tree/bulding nodes into a tree/bulding group an activate queries for the group node only. The query will then use the aggregated bounding box for occlusion testing and - if occcluded - will avoid rendering larger amounts of geometry.

 

In case of heavy-weight single node objects (e.g. very complex character/model mesh with large trinagle count or heavy shaders) activating queries on node-instance level still should be used.

[steve3d]

for example, I have a scene composed with road, pier, buildings around the road, currently , there are lots of piers and buildings, so I created 2 world-cluster, one is for piers, and another for buildings. in your suggestions, I should only activated the query flag for this two world-cluster, no need to enable query for the pier and building instanced objects. and also, I should enable the query for the road objects, because the road objects are very complex, about 2k-6k triangles per object.

 

am i right?

[ulf.schroeter]

for example, I have a scene composed with road, pier, buildings around the road, currently , there are lots of piers and buildings, so I created 2 world-cluster, one is for piers, and another for buildings. in your suggestions, I should only activated the query flag for this two world-cluster, no need to enable query for the pier and building instanced objects. and also, I should enable the query for the road objects, because the road objects are very complex, about 2k-6k triangles per object.

 

am i right?

 

Unfortunately, I don't think it is as easy as that.

 

1) optimize geometry view frustum culling

 

This needs some kind of splitting/organizing your world scene into multiple spatial/hierarchical groups, so large parts of the world geometry can be clipped efficiently against view frustum (reason for spatial splitting) without testing thousands of individual object bounding boxes (reason for hierachial grouping)

 

If you put all your individual objects in 1 or 2 WorldCluster objects there is no real spatial splitting/grouping of your scene. WorldCluster object has more or less size of your scene (=will always be visible in view frustum), so culling has to be done for all individual WorldCluster node references.

 

 

2) optimize view frustum occlusion filtering

 

to filter occluded geometry within the view frustum use occlusion queries for groups of spatially close objects to cull larger chunks of geometry. Also have a look on new WorldTerrainOccluder object which might be a very efficient solution for your urban environment scenario (search forums/documentation)

 

 

3) optimize visible scene render performance

 

use LOD for objects in the distance to reduce render load, use things like shared texture atlas for multiple objects to reduce render batch count, ...

[ulf.schroeter]

Also have a look on new WorldTerrainOccluder object which might be a very efficient solution for your urban environment scenario (search forums/documentation)

 

Hi Steve,

 

here's a simple sample for usage of WorldOccluderTerrain for urban environment culling. Blue boxes visualize blocking occluder height map pixels ( in this sample the heightmap geometry fitting is far to coarse to effectivly cull nearby geometry for a certain view point, but it shows the usage principle )

 

 

Regards

Ulf

[steve3d]

well, your project can use any type of terrain, and don't need to be a real-life terrain.

 

70% of our work is creating a real-life environment. that would be very difficult to create a accurate height map.

[ulf.schroeter]

well, your project can use any type of terrain, and don't need to be a real-life terrain.

 

As we are doing some real-world simulations we also have to use real-life terrain (e.g. on the screenshot you can see an urban street environment used for driving simulation).

 

Usage of WorldOccluderTerrain is not limited to terrain rendering. Actually it's a higly efficient general voxel occluder, where every texel is comparable to WorldOccluder box shape. In urban environments its not the terrain that occludes the scenery but large buildings. The idea is to code conservative building occlusion volumes as height voxels into WorldOccluderTerrain and use this as occluder for your complex architectural environment.

 

Same effect can be achieved with WorldOccluder(Mesh) objects but for certain sceneries I would expect WorldOccluderTerrain to be more efficient. Of course occluder heightmap generation is not always easy and most of the time will need some kind of automatic preprocessing.