BVH: Optimize preparation of geometry data.

[Glidias]

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

Also, from fromMeshGeometry() method could consider additional approaches (in the event of already referencing non-indexed geometry for the parameter, to avoid cloning the Meshgeometry via the toPolygonSoup() call). I understand that cloning does provide stability in case the original mesh geometry may had been altered via some other apps, but I guess seperating out fromMeshGeometry() into two seperate functions (.. ie. another function that avoids calling toPolygonSoup() cloning/conversion process, may be considered to allow bypassing additional cloning for certain application cases.

[Mugen87]

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.

[Glidias]

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.

[Mugen87]

Solved via 328e3f1.