Weird problems with 3D dynamic collisions at non (0,0,0) positions

[LesniakM]

Hi! I’m experimenting with 3D games in Defold (so far, I’ve only used Defold for 2D games). I’m currently using version 1.12.3.

I started by tinkering with the “3D third-person game sample.” I wanted to change the rocks to use dynamic collisions instead of static ones. After changing the type and collision masks, some strange things started to happen - the rocks began falling through the ground plane (or other objects) and a message appeared in the console:

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.

I started looking for intersecting objects etc. but found nothing. Somehow I found out, that the problem is collision shape position offset:

After changing its position to (0,0,0) rocks behave correctly:

I couldn’t find any recommendation stating that a collision shape should not be moved away from (0,0,0). In fact, the ability to control its position suggests that this should work without issues.

I was about to report this as a bug, but I checked another version of Defold (1.12.2), and everything behaved exactly the same. So I decided not to report it - perhaps collision shapes simply need to stay at (0,0,0). However, when I tried using a “capsule” shape with barrels (and later with rocks), things became completely unstable - objects started flying around at extreme speeds.

So, in summary:

• I cannot place “sphere” or “box” collision shapes at positions other than (0,0,0) without breaking collisions.
• I cannot use the “capsule” collision shape because everything goes out of control—even with very small capsules, objects bounce at extremely high speeds.

I don’t think the engine itself is this broken, so something must be wrong in my project. Could someone take a look and suggest what I might be doing wrong?

(well, maybe a bit off-topic, but I tried to upload 33.7 MB zip file with whole modified project here and got info that file is too big, however it says that maximum size is 48.8 MB):

I uploaded the file then: Content not found | LimeWire

[LesniakM]

I have investigated the problem further. I tried scaling collections instead of game objects (GOs), and also placing GOs in the root collection of the whole game, but neither approach worked.

To pinpoint the issue, I attempted to recreate it in a much simpler scene. I used the “Basic 3D Project” sample, added collision objects to a cube, duplicated it, and shifted the collision shape from (0, 0, 0) to somewhere else—and everything worked correctly.

Then I moved the camera further away and increased the scale of the objects to 20–50, and the collisions broke again, just like before. Everything works when all collision shapes are at position (0, 0, 0), but it fails as soon as a GO with a collision shape offset from (0, 0, 0) starts to rotate. It can lie flat without issues, but breaks as soon as a force causes it to tilt.

Correct behavior (all collision shapes are at position (0, 0, 0)):

Changing the positions to 0.3 (same for rock):

and collisions breaks:

So yeah, when object are scaled too much AND thier collison shapes are not in (0,0,0) pos, collisions seems to fails with error:

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.

Edit: I tried also scaling to 0.01 - works correcrly. Also setting size of collision shape x50 instead of scaling works correctly. The problem happens only if GO is scaled by factor by factor higher than 1 (tested for x20, x10, x5, x2 – all broken).

Project .zip file (in broken state):

Basic 3D Project.zip (255.0 KB)

I know that maybe scaling things x20 or x50 are not the best thing to do, but I still think it is a bug.

If it not a bug and just limitation of Defold or/and physiscs engine, maybe the “3D third-person game sample.” should be modified in order to avoid such scaling?

[a-daniel]

It seems to be a limitation in Bullet Physics Engine.

void	btCollisionWorld::updateSingleAabb(btCollisionObject* colObj)
{
	btVector3 minAabb,maxAabb;
	colObj->getCollisionShape()->getAabb(colObj->getWorldTransform(), minAabb,maxAabb);
	//need to increase the aabb for contact thresholds
	btVector3 contactThreshold(gContactBreakingThreshold,gContactBreakingThreshold,gContactBreakingThreshold);
	minAabb -= contactThreshold;
	maxAabb += contactThreshold;

	btBroadphaseInterface* bp = (btBroadphaseInterface*)m_broadphasePairCache;

	//moving objects should be moderately sized, probably something wrong if not
	if ( colObj->isStaticObject() || ((maxAabb-minAabb).length2() < btScalar(1e12)))
	{
		bp->setAabb(colObj->getBroadphaseHandle(),minAabb,maxAabb, m_dispatcher1);
	} else
	{
		//something went wrong, investigate
		//this assert is unwanted in 3D modelers (danger of loosing work)
		colObj->setActivationState(DISABLE_SIMULATION);

		static bool reportMe = true;
		if (reportMe && m_debugDrawer)
		{
			reportMe = false;
			m_debugDrawer->reportErrorWarning("Overflow in AABB, object removed from simulation");
			m_debugDrawer->reportErrorWarning("If you can reproduce this, please email bugs@continuousphysics.com\n");
			m_debugDrawer->reportErrorWarning("Please include above information, your Platform, version of OS.\n");
			m_debugDrawer->reportErrorWarning("Thanks.\n");
		}
	}
}

[LesniakM]

I suspected that, so I checked a few other things. When I create an object with a collision shape of, let’s say, 50x50x50, it works correctly. However, scaling up a shape with dimensions of 1x1x1 by x10 does not work.

For some reason, scaling a game object above 1x breaks the physics.

[LesniakM]

My workaround

I tried to set all collision shapes to position (0, 0, 0), which helped for boxes, but capsules were still buggy- they were flying away at extreme speeds on collision.

I also wanted to be able to use, for example, two boxes for a single collision object, which wasn’t possible. So I switched to using nested game objects inside a collection instead of simple GOs. It’s probably not perfect in terms of memory/performance, but it’s good enough.

I adjust the scale of the mesh/model by scaling the “model” GO, while the collision shape is in the “go” GO, whose scale is set to 1.

Collision shape dimensions are simply set by their dimensions.

Of course, since rocks are now a collection, I cannot put them inside the “rocks” GO in the “world” collection, so I created a separate “rocks” collection. As I expected, I still cannot scale individual “rock” collections or the overall “rocks” collection by a factor greater than 1 (0–1 works fine), because it breaks the game exactly the same as described before.

So the behavior is the same, but I can scale just the model and set the collision shape dimensions according to my needs. I can also use capsules now.

Nevertheless, I would really appreciate some feedback from more experienced users on whether this issue is my fault or a bug related to physics.

[a-daniel]

I managed to reproduce the same behavior in a different project 3DPhysicsStuff.zip (3.5 KB) .

In the foreground there are the collision objects that behave as expected.

In the background there are the collision objects with the issues:

• cube disappears after contact (with a message error in the console)
• capsule never stops bouncing even with restitution set to 0 and some linear/angular damping.

[a-daniel]

I opened an issue 3D Physics issues when scaling game objects · Issue #12261 · defold/defold · GitHub

The problems are caused by Bullet3D.

[LesniakM]

Thank you for digging into it!

I’m afraid then this is not an issue for Defold creators but rather Bullet3D. If this is persistent problem, that will not be solved in near future, I would love to have some kind of warning in docs/tutorials like this one: Collision shapes | Defold

[Dragosha]

That’s exactly right. It’s one of the most frustrating issues in 3D development with Defold. Fortunately, static colliders can be placed with any pivot. But as soon as we’re talking about dynamic or kinematic colliders…

[a-daniel]

Defold uses a patched version of Bullet 3D and it can be patched again to fix these issues. I made a PR for it ( Fix 3D Physics bugs caused by scaling game objects. by a-daniel · Pull Request #12267 · defold/defold · GitHub ).