enableMeshFrustumCulling [SOLVED]

[makkar]

Hi,

The documentation is a bit scarce on this command:

shape.enableMeshFrustumCulling ( hObject, bEnable )

Sure, logic tells me that if some triangles of a large mesh are not inside the camera frustum, they will not be rendered.

Is there any practical knowledge, background, cases to avoid and such use-case, about this function? On what platforms is it good to use? Above what triangle size should it be used or shouldn't?

[dpharaoh]

The case I can think of actually is to use this command to turn it OFF for very large objects that you dont ever want culled. I could be mistaken!

[NiCoX]

This function has been made for low-end devices that have a slow triangle culling unit and/or a slow CPU/GPU transfer rate. Typically the game "Voodoo Dice" is using it for the floor (that is a runtime-merged big mesh), on handled devices version (mobile and console).

[makkar]

And what if I have 50000-100000 triangles in my large flat building model that surrounds a central court? If I stand in the center, only about 30% of that mesh is visible at one time. Would it be practical in this case, too? Naturally, not on a handheld, but on a PC.

[NiCoX]

In this case I would cut the building into blocks and let the object level frustum culling do the job. Because the GPU (especially on a PC) will be faster for clipping, and the meshes will stay in GPU. When using triangle level frustum culling, the triangles list must be re-uploaded each frame to the GPU, that can cause additional slowdown. All is a question of balance between CPU and GPU. Depends if you app is CPU or GPU bound, and if GPU bound if you are vertex bound, or pixel bound, etc. The triangle level frustum culling applies to GPU vertex bound cases.

[makkar]

...Depends if you app is CPU or GPU bound, and if GPU bound if you are vertex bound, or pixel bound, etc...

This alone was not self-explaining, but anyway I will rather split my meshes then.
Thanks again!

[makkar]

So if the mobile app is already struggling with navigation mesh based pathfinding ( which is using CPU), but otherwise runs well without navigation, enableMeshFrustumCulling would place even bigger load on the CPU, right?

I am thinking about using this function for the only hi-poly model in the scene, a large one-piece terrain model of 15-20000 triangles. Or would it be better to slice it up into smaller chunks and let object level frustum culling work? Or just leave it in one piece....

Edit: forgot to mention that the game is aimed at higher end devices, so generally the framerates are quite good even with so many triangles, but all optimization is welcome to allow performance be spent elsewhere.

[NiCoX]

enableMeshFrustumCulling would place even bigger load on the CPU, right?

Yes

I am thinking about using this function for the only hi-poly model in the scene, a large one-piece terrain model of 15-20000 triangles. Or would it be better to slice it up into smaller chunks and let object level frustum culling work? Or just leave it in one piece....

There is unfortunately no fixed rules. Depends on the CPU and GPU load. If you the GPU is overloaded, using enableMeshFrustumCulling can greatly help, if not, that will just increase CPU load, possibly overloading it. Same for splitting into chunks: that will help GPU culling, but will add draw calls in the worst cases...

[makkar]

How can I make sure that shape.enableMeshFrustumCulling is actually working on a mesh?
Or make sure that it isn't enabled? In the Editor I try to follow the number of "GFX Draw Faces" in the Performance Reporter, and the value does change.

But it seems to me that

shape.enableMeshFrustumCulling ( hObject, bEnable )

sets culling regardless of the true/false parameter, and false won't disable it, Draw Faces will not jump up to the original higher values. Is this a bug?