Custom 3D collision shape

Anyone have an idea on how to prepare a custom 3d collision shape? @sven ?

When I try with a custom convexshape I sometimes get

WARNING:PHYSICS: Overflow in AABB, object removed from simulation
WARNING:PHYSICS: If you can reproduce this, please email bugs@continuousphysics.com

WARNING:PHYSICS: Please include above information, your Platform, version of OS.

WARNING:PHYSICS: Thanks.

Here is attempt at making a cube

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

But it looks like this

What I’d like is to be able to define .dae files as collision shapes so objects can use their own geometry for collision, or be able to set a simplified version of their .dae for collision, or be able to have/make a tool which can convert .dae files to proper collision shape files.

I’ve made a note to investigate what the current status is on this. Will check on Monday.
If there isn’t already a ticket I’ll make sure to create one and bring it up asap as it’s certainly something we want, especially considering our current take on 3D and performance.

Added ticket DEF-2927. I can’t give any ETA at the very moment though.

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!