Custom 3D collision shape

Can you post what the version of the bullet physics library being used is?

Version 2.77

Download for anyone interested https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/bullet/bullet-2.77.zip

I’ll read the docs for this version.

Have custom 3D collision shapes been added since these posts?

Sadly not for meshes. Bullet physics should easily be able to support it too…

Okay, cheers. What about .convexshape in 3D?

You could try getting it to work, the original post in this thread was my last attempt at it.

If we could have static meshes for levels/terrain that could be enough for many 3d game use cases.

Here is my attempt using @selimanac’s editor with a slightly angled camera. It almost works, but I think the 0 depth makes it freak out a bit.

3D:

Screenshot 2020-03-23 at 08.41.28.png2165×825 131 KB

2D:

Screenshot 2020-03-23 at 08.42.18.png2162×822 154 KB

I’ve also tried to use a custom convex shape in 3D. I made a simple pyramid.

shape_type: TYPE_HULL
data: 0
data: 1
data: 0
data: -1
data: -1
data: 1
data: 1
data: -1
data: 1
data: 0
data: 1
data: 0
data: 1
data: -1
data: 1
data: 1
data: -1
data: -1
data: 0
data: 1
data: 0
data: 1
data: -1
data: -1
data: -1
data: -1
data: -1
data: 0
data: 1
data: 0
data: -1
data: -1
data: -1
data: -1
data: -1
data: 1

Sometimes it works, but with strange fractal geometry inside:

Sometimes it fails with the error “Overflow in AABB, object removed from simulation” and strange geometry outside:

Screenshot 2020-08-16 at 00.09.01.png948×625 115 KB

It actually looks like there is some code that does the job. If someone knows how to work with bullet physics and convert collada models to convex shapes, it would be great

The pitfall I found is that it is recommended to reduce the number of vertices. This is written in the manual:

Screenshot 2020-08-16 at 00.26.09.png1099×234 34.9 KB

I want to bump up this topic. This is actually one small but strongest step for making 3D games.

I saw some pattern in this bug.

After creating the necessary and correct vertices, the unnecessary glitch vertices are created in a random progression. If the progression generated vertexes into the object, then physics works fine and doesn’t need to process glitch vertexes because they are inside the object. If the progression goes beyond the object, then glitch vertices can be very far from the object and physics can’t calculate so huge collisions and turned off the object with the overflow error.

May be the random factor is a bad memory access or a floating point stuff? For example, it can be out of bounds in vertices[i] that gets an undefined behavior with random vertex data.

We pass &convex_shape->m_Data[0] to NewConvexHullShape3D that waiting for an array of floats , is it correct? May be we need to pass just convex_shape->m_Data?

A switch with some 2D convex shape preparing:

if (context->m_3D)
    resource->m_Shape3D = dmPhysics::NewConvexHullShape3D(context->m_Context3D, &convex_shape->m_Data[0], convex_shape->m_Data.m_Count / 3);
else
{
    const uint32_t data_size = 2 * convex_shape->m_Data.m_Count / 3;
    float* data_2d = new float[2 * convex_shape->m_Data.m_Count / 3];
    for (uint32_t i = 0; i < data_size; ++i)
    {
        data_2d[i] = convex_shape->m_Data[i/2*3 + i%2];
    }
    resource->m_Shape2D = dmPhysics::NewPolygonShape2D(context->m_Context2D, data_2d, data_size/2);
    delete [] data_2d;
}

3D shape creating:

HCollisionShape3D NewConvexHullShape3D(HContext3D context, const float* vertices, uint32_t vertex_count)
{
    assert(sizeof(btScalar) == sizeof(float));
    float scale = context->m_Scale;
    const uint32_t elem_count = vertex_count * 3;
    float* v = new float[elem_count];
    for (uint32_t i = 0; i < elem_count; ++i)
    {
        v[i] = vertices[i] * scale;
    }
    btConvexHullShape* hull = new btConvexHullShape(v, vertex_count, sizeof(float) * 3);
    delete [] v;
    return hull;
}

2D shape creating:

HCollisionShape2D NewPolygonShape2D(HContext2D context, const float* vertices, uint32_t vertex_count)
{
    b2PolygonShape* shape = new b2PolygonShape();
    float scale = context->m_Scale;
    const uint32_t elem_count = vertex_count * 2;
    float* v = new float[elem_count];
    for (uint32_t i = 0; i < elem_count; ++i)
    {
        v[i] = vertices[i] * scale;
    }
    shape->Set((b2Vec2*)v, vertex_count);
    delete [] v;
    return shape;
}

I also found an interesting recommendations post for working with btConvexHullShape:

• Use .setMargin(0) to remove the bug with extra padding.
• Use btShapeHull() to reduce the polygon count in btConvexHullShape.

I wonder how painful it would be to update the bullet version. The current version is 2.77.

https://pybullet.org/Bullet/phpBB3/viewforum.php?f=18

Any of the 2 version will probably not be too bad and one of them might fix the issue among potential others.

One feature we need is to be able to use meshes as static physics objects. If we had that I could make most of the 3D games I want to make with Defold.

Probably not very painful.
Unpack the new package, and apply the patches we’ve made. Then rebuild the packages for each of the platforms/architectures.

The code is here: https://github.com/defold/defold/tree/dev/external/bullet3d

For collision meshes, we have ticket #3519 for this.

I managed to fix this issue, take a look:

This is great! For 2D .convexshapes PhysicsEditor works well. Is there a similar tool that can be used to generate 3D .convexshapes?

Not sure there are.
I’d recommend using Blender and having a script to output the vertices into a .convexshape file.

E.g. see defold_mesh.py in this example: Mesh Component

Regrettably defold_mesh.py looks like “real code”, and therefore borderline impenetrable to me. I was wondering how @aglitchman produced this one?

118413451-118ac480-b6a8-11eb-9af8-cb08caf8d87a841×1210 9.47 KB

The green lines are the physics debug view of a convex shape. I produced it using the Convex Hull tool in Blender, then I made the .convexshape file by hands. Yes, this process can be automated with Python scripts!

Three symbols fixed the fundamental bug! Thank you, this is awesome!

@aglitchman Can you describe how you converted your mesh to the .convexshape? I tried exporting a .dae from blender and copying the “mesh-positions-array” (splitting each coordinate up into lines, etc), but I just got a twisty mess. I tried reversing the order of the vertices, but no luck with that either.

Pkeod’s original cube is also twisted, but Astrochili’s pyramid works fine.

Sorry for the late answer but I can give it now.

It’s not very important to have a correct order. For bullet physics the convexshape is a set of vertices without any order or grouped faces.

Only the engine tries to draw the convexshape with green lines from the first vertice to the second, from second vertice to the third etc. So the only reason to keep the order and assemble the array, for example, by going through all the triangles one by one, is for visual debugging.

My pyramid is fine because I prepared it this way by adding 3 vertices per a triangle → 4 triangles → 12 vertices. But in this case just 5 vertices would also work for physics, albeit with messy lines in debug drawing.