Speed up rendering?

[chpatrick]

Thanks for a great library!

I was thinking, could this approach also be used to speed up rendering of large meshes? IIRC Three doesn't render meshes whose bounds don't intersect the frustum, so if a large mesh was partitioned as it was here it would also lead to improvements in rendering speed. You might even get the fast raycasting behavior for free if you turn a Mesh into an Object3D hierarchy.

[gkjohnson]

Great to here it! And that's not a bad idea.

THREE does do frustum culling as it renders but doesn't use any type of acceleration structure for that (it just checks every mesh) so you'll start to run into different performance bottlenecks as you add more meshes. If we were to break up a large mesh into smaller ones you might run into issues with the number of draw calls needed or becoming vertex bound because the broken up meshes can no longer share vertices that they could when rendering a single mesh.

There may be some others ways to use this structure to do some per-triangle culling, though. In #77 I'm adding a few functions to perform some shape casting (spheres, boxes) and gather up all the triangles that intersect with the object. You could imagine using a frustum and only rendering the triangles that are in the view by either creating a new index array or using geometry groups to limit what's rendered. Something like MultiDrawArrays would be useful here, but unfortunately that's not available in WebGL. There'd be some work in making it as fast as possible and you'd want to do some benchmarking to ensure the performance penalty of checking the frustum is worth it, though. I'd have to think about it more but maybe there'd be a way to do occlusion culling, as well?

Do you have an example of what you'd like to use it for?

As an aside I was working on a dynamic scene-based oct tree hierarchy awhile ago which I may pick it back up after what I've learned with this project.

[gkjohnson]

Closing in favor of #144