Bullet: Bumpy RigidBody to static trimesh collisions #21341

cosmicchipsocket · 2018-08-24T02:40:20Z

Godot version:
2db4942

OS/device including version:
Arch Linux (rolling release)

Issue description:
Collisions between basic Bullet primitives and trimesh collision shapes generated from an imported model cause sliding objects to pop into the air whenever they cross triangle boundaries. I would expect the object to slide smoothly over the mesh. Until this is fixed I can't really work on my game any further.

(This GIF shows the puck falling through the floor. I know this is already covered by #20408, but I am experiencing problems beyond that issue's scope)

I tried changing the margin on both the puck and the trimesh, but this only made problems worse.

Steps to reproduce:
Download example project, hold Space for a bit, then release

Minimal reproduction project:
bumpy_trimesh_collision.zip

The text was updated successfully, but these errors were encountered:

Chaosus · 2018-08-24T10:21:39Z

cc @AndreaCatania

AndreaCatania · 2018-08-26T10:28:10Z

Can you try to split all parts, and make a smaller one to avoid precision error?

Also when you have this kind of trimesh shape you have to increase the physics frames from 60 to 240 or so to make it more stable

cosmicchipsocket · 2018-08-26T15:11:02Z

Splitting all parts will just make the object pop into the air upon crossing the seams, even with primitives like cubes (I've observed this in my own game). I also shouldn't need to increase the physics framerate to resolve this - the physics engine should simply make crossing over the individual triangles smooth. Not to mention, increasing it to 240 doesn't completely solve the issue, it just makes it less severe.

It seems to be an issue with edge filtering. A few pages related to the issue elsewhere:
https://github.com/bulletphysics/bullet3/issues/288
https://pybullet.org/Bullet/phpBB3/viewtopic.php?t=2611

erwincoumans · 2018-08-31T03:09:29Z

Yes, you need to use the

#include "BulletCollision/CollisionDispatch/btInternalEdgeUtility.h"
btTriangleInfoMap* triangleInfoMap = new btTriangleInfoMap();
btGenerateInternalEdgeInfo(trimesh, triangleInfoMap);

gContactAddedCallback = MyContactAddedCallback;//or add it to an existing callback

bool MyContactAddedCallback(btManifoldPoint& cp,	const btCollisionObjectWrapper* colObj0Wrap,int partId0,int index0,const btCollisionObjectWrapper* colObj1Wrap,int partId1,int index1)
{
	btAdjustInternalEdgeContacts(cp, colObj1Wrap, colObj0Wrap, partId1,index1);
	return true;
}

There is a very old demo that show how to use it:
https://github.com/bulletphysics/bullet3/tree/old_demos/Demos/InternalEdgeDemo

AndreaCatania · 2018-08-31T07:44:44Z

@erwincoumans There is a bug in the btAdjustInternalEdgeContacts.

Here the implementation:
#21618

The bug is that I use a compound shape and the function take the compound shape and cast it to a trimesh.

erwincoumans · 2018-08-31T16:17:42Z

I added a check for the expected mesh type before casting.
bulletphysics/bullet3#1853
The edge utility doesn't deal with btCompoundShape though. Please avoid wrapping a mesh inside a compound shape or consider writing a patch to the internal edge utility to support this case.

AndreaCatania · 2018-08-31T19:01:34Z

I can't avoid use a compound due to Godot requirements, but I can write a patch to support that case

erwincoumans · 2018-08-31T19:17:55Z

Why is it a requirement? Do you need a transform or is it required to have multiple shapes? We could add a btTransformShape (better performance as btCompoundShape).

AndreaCatania · 2018-08-31T20:57:28Z

It's required to have multiple shapes, I could use the btTransformShape when only one shape is used but support compound is necessary anyway

…

On Fri, Aug 31, 2018, 21:18 erwincoumans ***@***.***> wrote: Why is it a requirement? Do you need a transform or is it required to have multiple shapes? We could add a btTransformShape (better performance as btCompoundShape). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21341 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH9MR8V9M7g8oxcEsqyA1CBrqJg5QV9iks5uWYvwgaJpZM4WKpud> .

cosmicchipsocket · 2018-08-31T22:06:18Z

Some more background, at least from a Godot user perspective:

In Godot, objects are placed within a scene tree. For a physics object, you create a RigidBody or StaticBody (or similar) object. These objects do not contain shapes by themselves. Instead, you add one or more CollisionShape objects as children. These shapes are used together to form the compound shape. This means it's possible to do something like have a trimesh shape and a cube shape be part of the same object. It's not exactly ideal from the perspective of Bullet, but it is something that the user can do.

An easy fix would probably be to show a warning in the tree when a user has multiple CollisionShapes with one being a trimesh shape, since we already show a warning when there are no CollisionShapes. But if the Godot project wants to keep options open, the fix should probably be within Bullet, assuming there are no major performance concerns.

AndreaCatania · 2018-09-05T10:40:58Z

@erwincoumans I've created the function godotContactAddedCallback and added to contact callback

gContactAddedCallback = &godotContactAddedCallback;

This function is called with colObj1Wrap that wrap btTriangleShape and not btScaledBvhTriangleMeshShape or compund as I expected.

When I create a trimesh shape I use btScaledBvhTriangleMeshShape. Do you know why it happens?

erwincoumans · 2018-09-05T22:33:26Z

This is expected: during the dispatch, there will be temporary collision shapes generated (btTriangleShape) that get passed to the narrowphase and contact callbacks. You can still access the original collision shape, if you want to do filtering.

The btCollisionObjectWrapper colObj1Wrap->m_shape may point to btTriangleShape,
but the colObj1Wrap->m_collisionObject->getCollisionShape still points to the original shape.

Can you double-check?

AndreaCatania · 2018-09-06T05:39:16Z

oh ok, so can you please confirm that this function is called 1 time (for each step) per body even if it has more then 1 shape? (I want to avoid multiples useless update) Thanks you!

AndreaCatania · 2018-09-06T06:24:43Z

So after checking better the function I saw that is not possible to fetch compound and send just the single shape from outside, so I changed the Bullet function (You can find it below):

The problem is that the generated hash: int hash = btGetHash(partId0, index0); doesn't refer to any trimesh info and the function stops here: if (!info)

void btAdjustInternalEdgeContacts(btManifoldPoint &cp, const btCollisionObjectWrapper *colObj0Wrap, const btCollisionObjectWrapper *colObj1Wrap, int partId0, int index0, int normalAdjustFlags) {
	if (colObj0Wrap->getCollisionShape()->getShapeType() != TRIANGLE_SHAPE_PROXYTYPE)
		return;

	if (colObj0Wrap->getCollisionObject()->getCollisionShape()->isCompound()) {

		const btCompoundShape *cs = static_cast<const btCompoundShape *>(colObj0Wrap->getCollisionObject()->getCollisionShape());

		for (int i(cs->getNumChildShapes() - 1); 0 <= i; --i) {
			btBvhTriangleMeshShape *trimesh = 0;
			const btCollisionShape *s = cs->getChildShape(i);
			if (s->getShapeType() == SCALED_TRIANGLE_MESH_SHAPE_PROXYTYPE) {

				trimesh = ((btScaledBvhTriangleMeshShape *)colObj0Wrap->getCollisionObject()->getCollisionShape())->getChildShape();
			} else if (s->getShapeType() == TRIANGLE_MESH_SHAPE_PROXYTYPE) {
				trimesh = (btBvhTriangleMeshShape *)colObj0Wrap->getCollisionObject()->getCollisionShape();
			}

			if (trimesh) {
				btCollisionObjectWrapper subWrap(colObj0Wrap->m_parent, trimesh, colObj0Wrap->m_collisionObject, colObj0Wrap->getCollisionObject()->getWorldTransform() * cs->getChildTransform(i), partId0, index0);
				btAdjustInternalEdgeContacts(cp, &subWrap, trimesh, colObj1Wrap, partId0, index0, normalAdjustFlags);
			}
		}
	} else {
		btBvhTriangleMeshShape *trimesh = 0;
		if (colObj0Wrap->getCollisionObject()->getCollisionShape()->getShapeType() == SCALED_TRIANGLE_MESH_SHAPE_PROXYTYPE)
			trimesh = ((btScaledBvhTriangleMeshShape *)colObj0Wrap->getCollisionObject()->getCollisionShape())->getChildShape();
		else
			trimesh = (btBvhTriangleMeshShape *)colObj0Wrap->getCollisionObject()->getCollisionShape();
		btAdjustInternalEdgeContacts(cp, colObj0Wrap, trimesh, colObj1Wrap, partId0, index0, normalAdjustFlags);
	}
}

/// Changes a btManifoldPoint collision normal to the normal from the mesh.
void btAdjustInternalEdgeContacts(btManifoldPoint &cp, const btCollisionObjectWrapper *colObj0Wrap, btBvhTriangleMeshShape *trimesh, const btCollisionObjectWrapper *colObj1Wrap, int partId0, int index0, int normalAdjustFlags) {

	if (!trimesh)
		return;

	btTriangleInfoMap *triangleInfoMapPtr = (btTriangleInfoMap *)trimesh->getTriangleInfoMap();
	if (!triangleInfoMapPtr)
		return;

	int hash = btGetHash(partId0, index0);

	btTriangleInfo *info = triangleInfoMapPtr->find(hash);
	if (!info)
		return;

erwincoumans · 2018-09-06T14:23:27Z

The function is called for each contact point separately, to correct its normal.
I don't have much time to look into this. I would suggest to be more subtle about the use of btCompoundShape, and allow single collision shapes in Godot to directly use certain collision shapes that are NOT wrapped in btCompoundShape. Then only those shapes (bt(Scaled/Bvh)TriangleMeshShape) that are not wrapped support the internal edge utility, others don't. So once you combined multiple collision shapes into a compound, you loose some features (until if/when we fix this).

It is a bad choice to always force shapes to be wrapped in a btCompoundShape, even for a single collision shape that doesn't have any transform offset etc.

AndreaCatania · 2018-09-06T14:43:08Z

Ok I can optimize that case

AndreaCatania · 2018-09-06T16:38:15Z

Optimized following the advice of erwin, and also implemented the use of function: btAdjustInternalEdgeContacts

but doesn't solve the problem #21808

AndreaCatania · 2018-09-06T16:50:31Z

would be interesting test it inside PyBullet... can you please give me the blender file of this shape?

erwincoumans · 2018-09-06T17:40:34Z

Did you generate the internal edge information? Do you have the trimesh as an .obj file? If so, it is easy to reproduce inside PyBullet. We use the internal edge utility as option in PyBullet.

…

On Thu, 6 Sep 2018 at 09:51, Andrea Catania ***@***.***> wrote: would be interesting test it inside PyBullet... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21341 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAsR3Lbt8Hr2Em_Fj5o-EupJcGouSnayks5uYVKlgaJpZM4WKpud> .

AndreaCatania · 2018-09-06T17:48:01Z

Yes I do it. Could be due by the fact that I use btTriangleMesh to generate btBvhTriangleMeshShape?

@cosmicchipsocket Do you have the blender file of this trimesh shape?

AndreaCatania · 2018-09-08T07:40:10Z

@erwincoumans I know that you don't have time to support us but I really don't know why this happen..
Also another issue: #21409 say that this bug appeared after the margin pull request was merged.

Do you know if margin could introduce this behaviour? also increasing timestep from 60 to 120 make the problem completely disappear.

AndreaCatania · 2018-09-08T07:53:46Z

I've checked if the problem was introduced by #e5bfa98d0fa6a1acb1d385534c51b8006ef64142, but that PR just increased that problem...
Is like that the primitive shape is not able to correctly depenetrate the trimesh surface.

AndreaCatania · 2018-09-08T08:26:14Z

Change margin of trimesh shape to 0 seems to reduce drastically this problem, but I'm wandering if the normal (so the order of vertices in the triangle) is a significant information for bullet...

Could be that the margin is applied toward the triangle face direction?
Should I use margin in ConcaveShape?

cosmicchipsocket · 2018-09-10T23:03:13Z

I was hoping that #21808 would fix the issue but now it seems to have gotten worse. Nine times out of ten I can't even make it to the half-pipe without being flung off to the side.

cosmicchipsocket · 2018-09-11T02:56:04Z

Here's the Blender file

TestTerrain.zip

AndreaCatania · 2018-10-05T13:23:50Z

This fix your issue: #22759
I've added inside the project settings this parameter "smooth_trimesh_collision" when you check it the concave collision become as expected.

Let me know and thanks you for your report!

abrenneke · 2018-10-05T13:50:30Z

That's awesome @AndreaCatania - when would we want smooth_trimesh_collision to be set to false?

AndreaCatania · 2018-10-05T13:58:33Z

When you don't need to walk on a trimesh, or if you don't have any problem walking on it with that parameter set to false.

cosmicchipsocket · 2018-10-07T17:04:21Z

It's not 100% solved but much improved. Half-pipe feels right but the puck still catches on a couple triangle edges in the first part. Setting physics FPS to 120 mostly eliminates these issues.

cosmicchipsocket · 2018-10-07T17:35:21Z

Wanted to share this clip. Thank you for your hard work improving the physics.

AndreaCatania · 2018-10-07T19:03:32Z

I'm glad to see this clip, and also thanks you 😁

…

On Sun, Oct 7, 2018, 19:35 Cosmic Chip Socket ***@***.***> wrote: Wanted to share this clip. Thank you for your hard work improving the physics. [image: quarterpipecropped] <https://user-images.githubusercontent.com/34800072/46584795-cca14a80-ca35-11e8-9651-dad6a69f4938.gif> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21341 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH9MR5hYimDrTdF7khhjPWEapjHGRaooks5uijt3gaJpZM4WKpud> .

…ndicated in godotengine/godot#21341 (comment) and https://stackoverflow.com/a/47499337/4228964

Zylann · 2020-07-24T12:12:02Z

Can we document physics/3d/smooth_trimesh_collision? Someone asked about it on my repo, it's nowhere to be found in docs and I have no idea what it is.

AndreaCatania · 2020-07-27T08:56:18Z

Imagine a triangle mesh with two big triangles. Your object (a box) is on a triangle - sliding toward the other triangle. When it touch the edge of the other triangle it generates a normal that doesn't follows the surface (0,1,0) but follows the edge direction (0.5, 0.5, 0).normalize() making the object jump a little bit.

The physics/3d/smooth_trimesh_collision make sure to fix the collision normal in that case.

Note that, to fully use this feature, also the trimeshshape COM must be 0,0,0.

jes · 2020-07-27T15:11:40Z

I think I am running into the same problem here, in 3.2.stable from Ubuntu 20.04.

I have enabled physics/3d/smooth_trimesh_collision but I still hit an invisible bump at the join between 2 triangles: https://www.youtube.com/watch?v=NzZOowfcAAw

AndreaCatania · 2020-09-19T13:22:34Z

@Zylann

Can we document physics/3d/smooth_trimesh_collision? Someone asked about it on my repo, it's nowhere to be found in docs and I have no idea what it is.

godotengine/godot-docs#4040

AndreaCatania · 2020-09-19T13:23:24Z

I think I am running into the same problem here, in 3.2.stable from Ubuntu 20.04.

I have enabled physics/3d/smooth_trimesh_collision but I still hit an invisible bump at the join between 2 triangles: https://www.youtube.com/watch?v=NzZOowfcAAw

If that still the case, try to open a new issue with a sample project.

meigel · 2020-09-19T18:39:04Z

@Zylann

Can we document physics/3d/smooth_trimesh_collision? Someone asked about it on my repo, it's nowhere to be found in docs and I have no idea what it is.

godotengine/godot-docs#4040

Very nice! Where do I find the page tutorials/physics/collision_shapes_3d.rst in the online documentation?

Paavs-Git · 2020-09-19T20:03:34Z

Very nice! Where do I find the page tutorials/physics/collision_shapes_3d.rst in the online documentation?

That Pull Request has not been merged yet, so it's not yet in the online documentation.

braydenplumb · 2021-02-22T10:09:21Z

I am starting to see this exact issue pop up again in Godot v3.2.3. I am trying to use a rigid body with a sphere collision, and a concave polygon tri-mesh collision for a racing game, but every time the sphere car controller hits an edge in the collision, it just keeps jumping up. It's very similar to both @jes and @cosmicchipsocket video. I've tried both Bullet and GodotPhysics with the smooth_trimesh_collision option selected, and the collision margins dropped to .001 with no success so far.

2021-02-22_02-07-34_Trim.mp4

jes · 2021-02-22T10:12:18Z

I seem to recall that my problem was at least partly down to having a really low mass for the vehicle. What's your vehicle mass set to? You might find the problem gets better if you increase it by 10x or 100x.

braydenplumb · 2021-02-22T10:14:28Z

It's set to a mass of 1500, which I feel like should be more than high enough, if not too high. I've tried setting it higher and it only slightly helps, but is still very prominent unfortunately.

braydenplumb · 2021-02-22T10:18:43Z

I'm thinking that the smooth_trimesh_collision may have just been a temporary solution, and something in the 3.2.3 update caused it to break. It might be worth me trying out the project in an earlier version of Godot to see if it's still there.

wissem-cood · 2021-05-19T08:56:49Z

@cosmicchipsocket

Hey !

Hope you're doing fine, i'm having the same issue that you got ( 5 years ago hahah )
I'm actually using ammo.js, a javascript library based on a bullet compilation..
Unfortunately, there's no info about this issue, and i'm stuck, can't go further and it's so frustrating, because i really don't know how i'll solve this problem !

I did this

btGenerateInternalEdgeInfo(trimesh, triangleInfoMap);

gContactAddedCallback = MyContactAddedCallback;//or add it to an existing callback

bool MyContactAddedCallback(btManifoldPoint& cp,	const btCollisionObjectWrapper* colObj0Wrap,int partId0,int index0,const btCollisionObjectWrapper* colObj1Wrap,int partId1,int index1)
{
	btAdjustInternalEdgeContacts(cp, colObj1Wrap, colObj0Wrap, partId1,index1);
	return true;
}

But in javascript so it looks like this :

const triangleInfoMap = new Ammo.btTriangleInfoMap();
Ammo.btGenerateInternalEdgeInfo(this.shape, triangleInfoMap);

//Ammo.addFunction gives me back a pointer
const gContactCallback = Ammo.addFunction((cp, colObj0Wrap, partId0, index0, colObj1Wrap, partId1, index1) => {
	Ammo.btAdjustInternalEdgeContacts(cp, colObj1Wrap, colObj0Wrap, partId1,index1);
	return true;
})

the thing is, i don't know where to set my callback, is it on the physicsworld.setContactProcessedCallback ??
i already tried with physicsworld.setContactProcessedCallback, but it's doesn't seem to work 😢

I would love to talk with you and maybe you can share with me your experience and solutions for this!
Thanks a lot in advance ❤️

Chaosus assigned AndreaCatania Aug 24, 2018

Chaosus added bug topic:physics labels Aug 24, 2018

Chaosus added this to the 3.1 milestone Aug 24, 2018

AndreaCatania mentioned this issue Sep 5, 2018

[WIP] Fixing trimesh precision #21618

Closed

AndreaCatania mentioned this issue Sep 8, 2018

Jittery physics (object does not come to rest) (regression from 912131f) #21409

Closed

AndreaCatania mentioned this issue Oct 5, 2018

Some physics fixes for 3.1 #22759

Merged

akien-mga closed this in #22759 Oct 7, 2018

wacyym mentioned this issue May 22, 2020

Missed smooth_trimesh_collision property Zylann/godot_voxel#145

Closed

FlorentMasson added a commit to FlorentMasson/ammo.js that referenced this issue May 22, 2020

add support for adjust internal edges for btBvhTriangleMeshShape as i…

0c82440

…ndicated in godotengine/godot#21341 (comment) and https://stackoverflow.com/a/47499337/4228964

AndreaCatania mentioned this issue Sep 19, 2020

Correctly showed smooth_trimesh_collision into the Project Settings. #42193

Open

bluecorn745 mentioned this issue Mar 2, 2021

[Bullet] 3D RigidBody collisions with static collision shapes still bumpy #46596

Open

godotengine / godot

Sponsor godotengine/godot

Bullet: Bumpy RigidBody to static trimesh collisions #21341

Bullet: Bumpy RigidBody to static trimesh collisions #21341

Comments

cosmicchipsocket commented Aug 24, 2018 • edited

Chaosus commented Aug 24, 2018

AndreaCatania commented Aug 26, 2018

cosmicchipsocket commented Aug 26, 2018 • edited

erwincoumans commented Aug 31, 2018 • edited

AndreaCatania commented Aug 31, 2018

erwincoumans commented Aug 31, 2018 • edited

AndreaCatania commented Aug 31, 2018

erwincoumans commented Aug 31, 2018

AndreaCatania commented Aug 31, 2018

cosmicchipsocket commented Aug 31, 2018

AndreaCatania commented Sep 5, 2018 • edited

erwincoumans commented Sep 5, 2018

AndreaCatania commented Sep 6, 2018

AndreaCatania commented Sep 6, 2018

erwincoumans commented Sep 6, 2018 • edited

AndreaCatania commented Sep 6, 2018

AndreaCatania commented Sep 6, 2018

AndreaCatania commented Sep 6, 2018 • edited

erwincoumans commented Sep 6, 2018 • edited

AndreaCatania commented Sep 6, 2018

AndreaCatania commented Sep 8, 2018

AndreaCatania commented Sep 8, 2018

AndreaCatania commented Sep 8, 2018

cosmicchipsocket commented Sep 10, 2018

cosmicchipsocket commented Sep 11, 2018

AndreaCatania commented Oct 5, 2018

abrenneke commented Oct 5, 2018

AndreaCatania commented Oct 5, 2018

cosmicchipsocket commented Oct 7, 2018

cosmicchipsocket commented Oct 7, 2018

AndreaCatania commented Oct 7, 2018

Zylann commented Jul 24, 2020

AndreaCatania commented Jul 27, 2020

jes commented Jul 27, 2020 • edited

AndreaCatania commented Sep 19, 2020

AndreaCatania commented Sep 19, 2020

meigel commented Sep 19, 2020

Paavs-Git commented Sep 19, 2020

braydenplumb commented Feb 22, 2021

jes commented Feb 22, 2021

braydenplumb commented Feb 22, 2021

braydenplumb commented Feb 22, 2021

wissem-cood commented May 19, 2021

cosmicchipsocket commented Aug 24, 2018 •

edited

cosmicchipsocket commented Aug 26, 2018 •

edited

erwincoumans commented Aug 31, 2018 •

edited

erwincoumans commented Aug 31, 2018 •

edited

AndreaCatania commented Sep 5, 2018 •

edited

erwincoumans commented Sep 6, 2018 •

edited

AndreaCatania commented Sep 6, 2018 •

edited

erwincoumans commented Sep 6, 2018 •

edited

jes commented Jul 27, 2020 •

edited