Problems with TriMeshes

[JanK]

Hi

I'm using bullet mainly for ray-casting in a game-like application, but also for camera-control.

My data is one huge triangle mesh (something like 3 million triangles), it represents a 40 km^2 city.
I upload it like this: http://bulletphysics.org/mediawiki-1.5. ... gle_Meshes

All i want to do is prevent the camera to fly through walls. So first i tried the new character controller. However it wouldn't smoothly slide along walls, it kept hanging and actually moving walls UPWARDS. Also i couldn't disable gravity on it. I checked the forums and found that this apparently is a known problem.

So i switched to a rigid-body sphere for my collision shape. I control it via forces and damping. The movement works well enough, but the collisions are still very buggy.


The problem seems to be edges between triangles. When my sphere slides along the ground or walls it consistently "hangs". But it's not the application, that hangs, because i can keep looking around etc., it's only the sphere that suddenly stops moving. After some time it pops away from the edge with great velocity. If i stop applying forces to the sphere while it hangs, it recovers faster. This happens A LOT.

Sometimes i want to disable collisions, so i set the flag NO_COLLISION_RESPONSE on the sphere (because you can't change filter masks on the fly). However collisions are obviously still computed and although the sphere does not COLLIDE and bounce anymore, the "hang"-bug still occurs! If i fly through a wall SLOWLY no collision happens, but when the sphere becomes faster (maybe one meter/sec, btw. the sphere has a radius of 0.5 meters and CCD enabled), it often stops when a collision would happen, hangs, and then continues through the mesh, as supposed to.


Now i don't need to fix this right-away, it's low-priority for me. The question is, will this be fixed in Bullet in the near future? Are there plans to do so, at all, or is it my responsibility to somehow fix it? If it is planned to be fixed soon, i can wait a few months. Otherwise i'd be happy if someone could tell me what i need to do.

Thanks,
Jan.

[Erwin Coumans]

I'm working on a fix that avoid collisions against interior edges and vertices. An initial version should be released for Bullet 2.76 later this month.

You can track/read more about this issue here: http://code.google.com/p/bullet/issues/detail?id=27

There might be an additional issue with CCD enabled. Perhaps you can help testing this new feature?
Thanks,
Erwin

[JanK]

I would be glad to help with that.

When you say "internal edge", does that mean that i somehow need to provide connectivity information? I don't do anything like that atm (if that is possible at all). Or would Bullet figure that out by itself?

About CCD: AFAIK CCD is enabled by setting the swept-sphere radius and the CCD threshold, even in a discrete world, no? Because i just found out that there is a continuous world, too, and tried that, though it made no difference.

However, i found another problem with the continuous world: I have a lot of static cylinders in my world and with the discrete world my camera-sphere smoothly slides around them. However in the continuous world when the sphere touches the cylinder it simply stops immediately. I can't slide around it, at all, one is forced to back off before any further movement is possible again. So i assume in the continuous world there is a problem with sphere / cylinder collisions.

Jan.

[Erwin Coumans]

When you say "internal edge", does that mean that i somehow need to provide connectivity information? I don't do anything like that atm (if that is possible at all). Or would Bullet figure that out by itself?

I'm working on a helper function that will calculate connectivity information and edge angles.

About CCD: AFAIK CCD is enabled by setting the swept-sphere radius and the CCD threshold, even in a discrete world, no? Because i just found out that there is a continuous world, too, and tried that, though it made no difference.

Don't use the btContinuousDynamicsWorld, it has never been completed.

Thanks,
Erwin

[radsun]

Hello

If i comment this line in btKinematicCharacterController it sildes on trimesh

Code: Select all

			if (hitDistance > m_addedMargin)
			{
//				printf("callback.m_closestHitFraction=%f\n",callback.m_closestHitFraction);
///				m_currentPosition.setInterpolate3 (m_currentPosition, m_targetPosition, callback.m_closestHitFraction);
			}

Meaby it helps

[Erwin Coumans]

Hello

If i comment this line in btKinematicCharacterController it sildes on trimesh

Code: Select all

			if (hitDistance > m_addedMargin)
			{
//				printf("callback.m_closestHitFraction=%f\n",callback.m_closestHitFraction);
///				m_currentPosition.setInterpolate3 (m_currentPosition, m_targetPosition, callback.m_closestHitFraction);
			}

Meaby it helps

The btKinematicCharacterController has many issues and is unfortunately not really maintained. Any improvements / patches etc, are welcome.

Thanks,
Erwin

[Erwin Coumans]

I would be glad to help with that.

Can you please try out this new btInternalEdgeUtility and give feedback in the following thread?

http://bulletphysics.org/Bullet/phpBB3/ ... f=9&t=4603

Thanks,
Erwin

[JanK]

I checked out the latest revision and tried it.

Sliding is now smooth as a baby's butt

One issue remains, though it seems not to be related to triangle meshes, because it happens with box-shapes and cylinder-shapes as well:

My camera is a dynamic sphere that i control via forces and damping, when i move that sphere very fast and bump into some static object, i get a short lag before bullet responds. This lag is NOT due to long computations, because i get several frames rendered in that time, it is simply that bullet does not process the collision-response properly for a fracture of a second.

There is a video here, that shows the effect:
www.artifactgames.de/Sonstiges/CollisionLag.wmv

At the fast moving clouds you can see that there are frames rendered during the time that bullet takes to respond. And as you can see from the wireframe-overlay the tesselation of the mesh should not be a problem.

Thanks for the sliding fix, that was a major problem for me.

Jan.

PS: The current cmake-file does not include "CollisionDispatch/btInternalEdgeUtility.cpp" one needs to add that or else you will get a linker-error (that's with revision 1881).

[Erwin Coumans]

One issue remains, though it seems not to be related to triangle meshes, because it happens with box-shapes and cylinder-shapes as well:

My camera is a dynamic sphere that i control via forces and damping, when i move that sphere very fast and bump into some static object, i get a short lag before bullet responds.

This is likely an issue of high velocity in combination with CCD motion clamping. Some people had good results in clamping the velocity as well, see http://bulletphysics.org/Bullet/phpBB3/ ... 916#p10916
We probably have to apply some velocity update when the motion is clamped. If you want to try it out, see void btDiscreteDynamicsWorld::integrateTransforms(btScalar timeStep)

Code: Select all

void	btDiscreteDynamicsWorld::integrateTransforms(btScalar timeStep)
{
	BT_PROFILE("integrateTransforms");
	btTransform predictedTrans;
	for ( int i=0;i<m_nonStaticRigidBodies.size();i++)
	{
		btRigidBody* body = m_nonStaticRigidBodies[i];
		body->setHitFraction(1.f);

		if (body->isActive() && (!body->isStaticOrKinematicObject()))
		{
			body->predictIntegratedTransform(timeStep, predictedTrans);
			btScalar squareMotion = (predictedTrans.getOrigin()-body->getWorldTransform().getOrigin()).length2();

			if (body->getCcdSquareMotionThreshold() && body->getCcdSquareMotionThreshold() < squareMotion)
			{
				BT_PROFILE("CCD motion clamping");
				if (body->getCollisionShape()->isConvex())
				{
					gNumClampedCcdMotions++;
					
					btClosestNotMeConvexResultCallback sweepResults(body,body->getWorldTransform().getOrigin(),predictedTrans.getOrigin(),getBroadphase()->getOverlappingPairCache(),getDispatcher());
					//btConvexShape* convexShape = static_cast<btConvexShape*>(body->getCollisionShape());
					btSphereShape tmpSphere(body->getCcdSweptSphereRadius());//btConvexShape* convexShape = static_cast<btConvexShape*>(body->getCollisionShape());

					sweepResults.m_collisionFilterGroup = body->getBroadphaseProxy()->m_collisionFilterGroup;
					sweepResults.m_collisionFilterMask  = body->getBroadphaseProxy()->m_collisionFilterMask;

					convexSweepTest(&tmpSphere,body->getWorldTransform(),predictedTrans,sweepResults);
					if (sweepResults.hasHit() && (sweepResults.m_closestHitFraction < 1.f))
					{
						body->setHitFraction(sweepResults.m_closestHitFraction);
						body->predictIntegratedTransform(timeStep*body->getHitFraction(), predictedTrans);
						body->setHitFraction(0.f);
//							printf("clamped integration to hit fraction = %f\n",fraction);
					}
				}
			}
			
			body->proceedToTransform( predictedTrans);
		}
	}
}

PS: The current cmake-file does not include "CollisionDispatch/btInternalEdgeUtility.cpp" one needs to add that or else you will get a linker-error (that's with revision 1881).

Should be fixed in latest release (note we are re-organizing some of the demos, so some are disabled but they should be re-enabled before 2.76 release)

Thanks,
Erwin

[crodgers]

Hi everyone,

I have just started working in Bullet about a week ago since we are changing to Bullet from another physics engine in our project. After a couple days working with the Character Controller, I discovered the same problem line as reported by radsun:

Code: Select all

         if (hitDistance > m_addedMargin)
         {
//            printf("callback.m_closestHitFraction=%f\n",callback.m_closestHitFraction);
//            m_currentPosition.setInterpolate3 (m_currentPosition, m_targetPosition, callback.m_closestHitFraction);
         }

			updateTargetPositionBasedOnCollision (callback.m_hitNormalWorld);

It seems that calling m_currentPosition.setInterpolate3 before updateTargetPositionBasedOnCollision cause the displacement vector from m_currentPosition to m_targetPosition to truncate drastically, OR that setInterpolate3 leaves the m_currentPosition too close to the wall. Either way something is weird and the line seems to prevent updateTargetPositionBasedOnCollision from preforming the sliding/target offset calculations with a decent vector.

Commenting the line out also seemed to stop the controller from trying to step up walls. Before finding this out, our player would slide up through walls until it was on top of the ceiling; it happened faster when colliding with corners.

However, commenting out the line does not seem to fix a bug that causes the player motion to snap up for one frame when moving across a triangle mesh terrain. Could this be something to do with collision with triangle edges or fault lines?

By the way, I had added jumping behavior to the controller class, if anyone is interested. The modification was mostly for fixing the method stepDown (where falling was controlled by the set step height and not by any gravity). The feature allows one to have different step heights while having the same effect for gravity. Jumping became a freebie after that

Cheers!

Chris

[Erwin Coumans]

If you have any improvements you think are worth sharing (under the Zlib license), please contribute it by posting a svn patch (against a recent trunk, such as Bullet 2.76 revision 2038 as of writing).

Post contributions in the google issue tracker at http://bullet.googlecode.com

Thanks a lot,
Erwin

[crodgers]

Hi Erwin,

I have updated to the new Bullet code. However, it seems I am running into some collision issue outside the scope of the character controller.

Since the version change, the controller motion is no longer smooth traversing terrain; whether it be up slope, down slope or on level ground. It seems the motion pops up when I go over edges where any two triangles meet on my terrain mesh.

I have tried disabling falling velocity code that I added, setting margins on the character geometry and enlarging the ghost object volume, but these have had results that are worse.

Could there be something weird going on with convex sweeping or something with sleeping/not-sleeping triangles?

Thanks for any help you might provide on this

Chris

[Erwin Coumans]

Since the version change, the controller motion is no longer smooth traversing terrain; whether it be up slope, down slope or on level ground. It seems the motion pops up when I go over edges where any two triangles meet on my terrain mesh.

From what version are you upgrading?

Can you try to call

Code: Select all

object->setContactProcessingThreshold(0.);

For the character controller object?

Otherwise, you might want to try out using the new btInternalEdgeUtility: http://bulletphysics.org/Bullet/phpBB3/ ... f=9&t=4603

Thanks,
Erwin

[crodgers]

Hi Erwin,

I have replied to Issue 198 (under Google user name "ossumajor") and have attached the changes to the Kinematic Character Controller files. Our results were tested using the ghost object collision. The controller can now jump and slide smoothly along walls!

The walking-pop-up bug we had encountered recently, after updating to the new Bullet 2.76 code, was caused by our higher level code and thus was out of the control of Bullet; it was related to how we were initializing our terrain triangle mesh. However, trying to use the internal edge utility helped us to find the problem, so thanks again Erwin

Chris