btOptimizedBVH 2^21 limit

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Try to add more than 2^21 triangles to a btTriangleMesh
2. Have a collision, or try to debug draw
3. Crash

What is the expected output? What do you see instead?
Running normally. A release version crashes, a debug version hits this assert:
BulletCollision/CollisionShapes/btOptimizedBvh.cpp:101: virtual void 
btOptimizedBvh::build(btStridingMeshInterface*, bool, const btVector3&, const 
btVector3&)::QuantizedNodeTriangleCallback::internalProcessTriangleIndex(btVecto
r3*, int, int): Assertion `triangleIndex < (1<<(31-10))' failed.

What version of the product are you using? On what operating system?
svn r2643. 64-bit linux.

Please provide any additional information below.

In the bullet forums, it's said that the btTriangleMesh can handle a few 
million tris just fine. Yet there's a 2.1M tris limit that's not documented 
anywhere.

Any reason to use a 32bit int for the partId/tri-index storage, and not a 64bit 
one?

Original issue reported on code.google.com by c...@gmx.com on 4 Jun 2013 at 8:19

[GoogleCodeExporter]

The node size is nicely 16 bytes, which is cache friendly.

See bullet\src\BulletCollision\BroadphaseCollision\btQuantizedBvh.h

// 10 gives the potential for 1024 parts, with at most 2^21 (2097152) (minus one
// actually) triangles each (since the sign bit is reserved
#define MAX_NUM_PARTS_IN_BITS 10

Just descrease MAX_NUM_PARTS_IN_BITS, and it should work.
Hope this helps,
Erwin

Original comment by erwin.coumans on 4 Jun 2013 at 9:50

[GoogleCodeExporter]

(Alternatively, split the triangle mesh into multiple parts, each below 2 
million triangles)

Original comment by erwin.coumans on 4 Jun 2013 at 9:51

[GoogleCodeExporter]

That's what I did to work around it, created several TriangleMeshes each about 
1M tris. I don't think the TriangleMesh interface allows you to easily create 
parts in the BVH, but I'm not very familiar with the bullet API.

However this is suboptimal for two reasons:
- I understand having them all in a single BVH is the most efficient
- the character controller gets stuck occasionally in the border between two 
such static bodies

Original comment by c...@gmx.com on 5 Jun 2013 at 9:25

[GoogleCodeExporter]

Actually, with the last patch of issue 198, the char controller works fine. So 
it's only about the efficiency then.

Original comment by c...@gmx.com on 5 Jun 2013 at 3:21

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The two suggestions I gave will still use a single BVH.
Did you try changing MAX_NUM_PARTS_IN_BITS to 0?

Alternatively, you can use a single btTriangleIndexVertexArray and add multiple 
mesh parts using btTriangleIndexVertexArray::addIndexedMesh. Then you can 
create a single btBvhTriangleMeshShape. That is what I meant in comment #2. See 
Bullet/src/BulletCollision/CollisionShapes/btTriangleIndexVertexArray.h

More important: you should not see any performance difference, because the 
Bullet btDbvtBroadphase uses BVH acceleration structures too. In fact, it might 
be even better to split the triangle mesh into smaller parts, and add each 
parts as a static btCollisionObject into the world.

Original comment by erwin.coumans on 5 Jun 2013 at 4:02

[GoogleCodeExporter]

Thanks.

Please consider this bug a documentation issue then - this limit and the 
workarounds weren't documented anywhere. Mentioning them in the related 
classes' descriptions would be good.

Original comment by c...@gmx.com on 6 Jun 2013 at 9:22

[GoogleCodeExporter]

MAX_NUM_PARTS_IN_BITS  and which headerfile will mentioned in the docs for 
Bullet 2.82,

Thanks!
Erwin

Original comment by erwin.coumans on 12 Sep 2013 at 9:49

• Changed state: Fixed