It's not surprising that so much time is spent on this.   It takes the mesh and creates a tight sphere-covering to accelerate ray intersection testing.

It's possible to trade space for time by storing the resulting sphere-tree with the mesh source, rather than recalculating it at load time.   But the storage space explosion factor is enormous, and it's not clear whether reading in the sphere-tree wouldn't be slow due to file reading (it certainly is slow to send across a slowish network).

You could get a constant factor by just making a primitive out of a few of the inner loops, or even much better improvement by using CUDA organized parallelized code (nice research project).

Alternatively, and probably much better, change the ray-mesh intersection code (the only client for the sphere-tree) by subclassing the operation by known techniques optimiized for your mesh's properties.  OOP is designed for this!

Steve Wart wrote:

Hi,

I have some large meshes that are taking a long time to activate. It looks like a lot of the time is spent in a method called initBounds, which in turn is spending a lot of time in TBoundSphere>>calcTree:faces:depth:

Have there been any efforts in optimizing this method (e.g. making it a primitive)?

Any suggestions on how to approach this? Slang? FFI? Something more clever?

Steve