Ray-cast issue - odd results

[rusty]

I'm having some issues with casting rays against a box representing the ground that it not attached to a body, but just a plain collision object. I would expect the positions I get from the ray cast to have a y-component of close to zero, but instead I'm getting y-components that jump around all over the place.

The odd thing is; if I cast a ray straight down, I get what seems to be a valid fraction and a very good intersection point! Even taking into account for rounding errors when calculating the point, I sometimes get heights as large as 0.19 units down to 0.09 units.

Does anybody have an idea as to why this might be? I've verfied that the ray is actually hitting the box. My code for determining the point is as follows;

Code: Select all

bool
SPhysicsManager::TestRay(
				TTestRayResult& lResult,
				const Ogre::Vector3& lRayStart,
				const Ogre::Vector3& lRayEnd,
				UINT32 lCollisionFlags /*= 0xffffffff*/)
{
	InternalRayResultCallback lInternalCallback;
	
	lInternalCallback.mRayTestFlags = lCollisionFlags;

	mpDynamicsWorld->rayTest(btVector3(lRayStart.x, lRayStart.y, lRayStart.z), btVector3(lRayEnd.x, lRayEnd.y, lRayEnd.z), lInternalCallback);

	if (lInternalCallback.mHitSomething)
	{
		lResult = lInternalCallback.mResult;
		lResult.mPoint = lRayStart + ((lRayEnd - lRayStart) * (lResult.mFraction));
		return true;
	}

	return false;
}

This is for a vehicle physics demo, an I'm not using Bullet's own Ray-cats vehicle class, but instead, rolling my own as I want to eventually simulate different suspension types (double-wisbone, MacPherson strut, trailing arm torsion bar etc.).

And here is my ray call back method, just incase anybody can spot something wrong with it.

Code: Select all

btScalar SPhysicsManager::InternalRayResultCallback::addSingleResult(btCollisionWorld::LocalRayResult& rayResult,bool normalInWorldSpace)
{

	// Store the fraction/interval of the collision on the ray, as well as the physics object pointer
	CPhysicsObject* lpObject = (CPhysicsObject*) rayResult.m_collisionObject->getUserPointer();

	// If we have a non-null object, check to see if the ray is allowed to hit it.
	if (NULL != lpObject)
	{
		if (0 == (lpObject->GetCollisionGroup() & mRayTestFlags))
			return 1.0f;
	}

	// We've gotten to here, so the ray is hitting a valid object. Flag that a valid hit has been found
	// and set the fraction in the callback class.
	mResult.mpObject = lpObject;
	mResult.mFraction = rayResult.m_hitFraction;
	mHitSomething = true;

	// Do we have to store the closest hit fraction?  It always seems to be 1, which is a bit of a pickle.
	m_closestHitFraction = rayResult.m_hitFraction;

	// Worldsace/local normal sruff
	if (normalInWorldSpace)
	{
		mResult.mNormal = Ogre::Vector3(rayResult.m_hitNormalLocal.getX(), rayResult.m_hitNormalLocal.getY(), rayResult.m_hitNormalLocal.getZ());
	} 
	else
	{
		///need to transform normal into worldspace
		btVector3 lhitNormalWorld = m_collisionObject->getWorldTransform().getBasis()*rayResult.m_hitNormalLocal;
		mResult.mNormal = Ogre::Vector3(lhitNormalWorld.getX(), lhitNormalWorld.getY(),lhitNormalWorld.getZ());
	}

	return 1.0f;
}

[rusty]

I've made some progress on this issue by making the ground box smaller...where it was 1000 units along the xz place before, it is now only 900 units.

Is there a prescision issue with large objects (spheres, boxes)?

As an aside, my simple ray test from <0, 10, 0> to <0, -1, 0> no longer works! Oh what fun I'm having with these ray-casts!

[Erwin Coumans]

There might be issues with huge collision shapes, in general it is recommended to use triangle meshes (btBvhTriangleMeshShape) for static world environment instead.

But we should try to fix this issue: can you provide a more information, how to reproduce this in a Bullet demo?

What are the box half extends, and world transform, and what is the start/end of the ray?
Thanks,
Erwin

[rusty]

I thought it might be a "big object" issue of some sort, but I didn't want to have to write a collision mesh exporter. I suppose I can generate one at run time for a flat plane.

The current collision box has a half extents of <400, 1.25, 400> with a transform of <0, -1.25, 0>.

The ray-segment starts at <0, 10, 0> and ends at <0, -1, 0>. This does not register any sort of hit, and my callback is never called. My smaller rays for the suspension of the car still seem to behave erratically, but nowhere near as bad as they did.

It is worth thinking about having a btPlaneShape for collisions, so that users can quickly setup their demos with a word? Atleast then, to a certain extent, precision issues shouldn't arise from having a larger test area.

[Erwin Coumans]

Thanks for the reproduction data, we'll check it out and report back.

There is a btStaticPlaneShape, you could use instead.
Thanks,
Erwin

[rusty]

Thanks, Erwin. I was looking for btPlaneShape in the documentation, so no wonder I couldn't find it. If you have problem reproducing the issue, let me know and we can perhaps sort something out with you getting a hold of my code to see it.

[Erwin Coumans]

Let's file an issue in the tracker, so we don't forget about this:

http://code.google.com/p/bullet/issues/detail?id=107

Thanks again,
Erwin

[rusty]

Excellent. I've finaly tried using btStaticPlaneShape for the ground, and after some issues, I managed to get it to work.

Is it normal for me to have to implicitly set the transform for a collision object before it will function properly? I could only get the plane shape to work after doing that.