BVH: Optimize preparation of geometry data. about yuka HOT 3 CLOSED

There are some minor side issues like the constructor parameters documentation ordering for BVH.js doesn't match the ordering of the function parameters.

You're right, primitivesPerNode and depth are mixed. Fixed here 96e6e9f. I'll updating the website later.

MeshGeometry.toTriangleSoup() is currently only called in BVH. How about BVH.fromMeshGeometry() only performs the conversion if the geometry is indexed. In this way, the caller can pass in a non-indexed geometry and does not trigger further processing overhead. Something like:

if ( geometry.indices !== null )  geometry = geometry.toTriangleSoup();

I would not worry about the fact that other app logic might change the vertex data. I don't think this is a problem here.

from yuka.

That's what i did on my end as well. Oh, it looks like you are refering a new primitives = new Array() clone anyway. So, it wouldn't matter even if the original data was mutated..

Anyway, for real-time performance critical stuff, I actually use another BVH implementation (benraziel's) that uses only a single densely packed monolith typed array on the tree itself, while each BVHNOde only uses startIndex to endIndex approach.

from yuka.

Solved via 328e3f1.

from yuka.