Large model collision follow games_fps example

Questions
1

I have a large model, implement collision detection by follow the https://threejs.org/examples/?q=game#games_fps
It is works well, but have some ploblems at initialization.
At initialization use worldOctree.fromGraphNode( obj ) to convert mesh to triangle.

img
img931×817 30.5 KB

If geometry position array is large, it will block the page render.
Is there any to solve the problem?

2

How large exactly is the geometry? If it’s really huge, the only reasonable way of solving the issue is optimising the geometry and loading only the parts of it that are necessary at the time.

3

objects:1355 vertices:34091 triangles:34839

4

That might be more triangles than the examples octree is intended to handle. The demo model in the example scene only has around 1750 triangles. One solution is to create and load a lower resolution mesh specifically for collisions and use your high resolution mesh for rendering.

Alternatively three-mesh-bvh (a library I maintain) is designed to support high density, high resolution meshes and should be able to be used in a similar way but you’ll have to merge the geometry first. I’ve recently added a basic physics demo inspired by the new three.js games_fps demo which shows basic use for something like this. I haven’t added a first person movement demo yet, though I’ve considered it, so depending on what you want to do it might not be immediately available out of the box.

4 Likes
5

Thanks! :grinning: I will try that.

6

Hello.

I had the same problem after exporting a GLB file from cinema4D.
Then the browser window is black and frozen.
But i think there is something broken with the geometry, because some simple models with low triangles are not working

You can try to import the scene in the Editor: three.js / editor and then export it again. That works for me, because the editor converts it into triangles.

7

Thanks for you replay! I have solve the problem by use three-mesh-bvh from @gkjohnson.

4 Likes
8

Looks like you’re sorted. But for future reference the slow part is building the tree when there are lots of overlapping triangles, the code in the split function responsible:

if ( len > 8 && level < 16 ) {
subTrees[ i ].split( level + 1 );
}

With 8 being the preferred # of tris per cell and 16 being the max number of divisions. If you increase # tries per cell to a higher number the tree will bailout sooner and generate faster at the expense of potentially needing to check more tris for collision. I’m getting ~1.5s for 120000 tris with 40 tris per cell as apposed to 10s+ when set to 8.

1 Like