Great Physics Engine Comparison (PEEL)

Dirk Gregorius
Posts: 861
Joined: Sun Jul 03, 2005 4:06 pm
Location: Kirkland, WA

Great Physics Engine Comparison (PEEL)

Post by Dirk Gregorius »

Pierre is talking about a bunch of optimizations he has done for PhysX over the recent years here and also compares it also to Bullet. Interesting to read, but sadly it misses Havok. I hope they will release the source, so we can add other engines as well. He seems to have a huge collection of great test cases.

http://www.codercorner.com/blog/?p=914
RBD
Posts: 141
Joined: Tue Sep 16, 2008 11:31 am

Re: Great Physics Engine Comparison (PEEL)

Post by RBD »

Nice to see PhysX getting better all the time; nice progress report on PhysX versions, and perhaps insight into some differences with Bullet. But it is understandably dripping wet with bias since PhysX is his baby; but at least he adds: "admittedly I may not be a Bullet expert." (far from non-expert, but no mention of simple details like collision margins used for Bullet). Looks like what you would expect when someone prepares propaganda for his own commercial baby using their own proprietary closed source test tool and methods.

I do find it very interesting commercial PhysX being defensive and apparently threatened by the free, permissive, and open source Bullet. I guess it is understandable considering the amount of resources that have been poured into Novodex / PhysX since 2001, they better damn well outperform :P .

Sadly for Pierre and his colleagues, PhysX's restrictive licensing, and nVidia's territorial hardware shenanigans really hurt devs and end-users, and therefore PhysX adoption by many.
Dirk Gregorius
Posts: 861
Joined: Sun Jul 03, 2005 4:06 pm
Location: Kirkland, WA

Re: Great Physics Engine Comparison (PEEL)

Post by Dirk Gregorius »

Well, I think they should release the source. Luckily Pierre is considering this. So lets hope for the best. In the end that would be the best since we can tune the tests in a way that makes sense and then make our own conclusions.

Anyway, besides this I think Pierre has done a decent analysis and his observations are kind of the same as my own experiences. I think this is no cheap propaganda and there is a lot of value in his posts! But releasing the source for Bullet integration would help a lot in this regard!
Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Great Physics Engine Comparison (PEEL)

Post by Basroil »

Sadly they have no mention of powered joints in that. Considering Nvidia is touting PhysX's pseudo-Featherstone as a plus, it would be interesting to see physical accuracy and speed comparisons.

Should also be interesting to see what happens when Bullet 3.x finally gets released (keep hearing "soon", so I hope it's not an issue with the joints and instead just normal delays)
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Great Physics Engine Comparison (PEEL)

Post by Erwin Coumans »

Thanks for sharing Dirk, it is an interesting read indeed. Pierre makes some valid points and I appreciate he shares his point of view, but his most dramatic results can be easily fixed in Bullet:
  • In the 255*255 static boxes tests, Pierre reports a staggering 34ms for Bullet simulating nothing, but with the right settings it is actually near to zero. There is no bug to be fixed there, just using Bullet properly: world->setForceUpdateAllAabbs(false); and world->addRigidBody should fix it.
  • The long sweep tests are not optimized, and with some trivial culling, you can cull most of the tests, rather then reporting 300x slower performance of Bullet.
  • Once Bullet gets into deeper penetration, EPA kicks in and that is 10 times slower than GJK, so choosing the right collision margin is very important.
  • The Bullet ray cast and convex sweep is far from optimal, and should be fixed with dedicated tests for most common cases.
  • Bullet 2.x uses generic methods for most cases, so a dedicated algorithm for special cases will easily outperform GJK+EPA. Bullet 3.x will have some more dedicated methods. The Sony Physics Effects contribution will help towards this.
I am working on Bullet 3.x and its OpenCL GPU performance is working very well. It can simulate 100k stacking boxes in real-time on a 7970 GPU. There are various broad phase collision improvements, better SAT collision (also thanks to Dirk for his SAT presentation), better contact management, faster solver. A lot of the GPU improvements will benefit the CPU version too, so I'll make sure to sort out some PhysX 3 versus Bullet 3 doubts.
Pierre
Posts: 67
Joined: Mon Jul 25, 2005 8:56 am

Re: Great Physics Engine Comparison (PEEL)

Post by Pierre »

Hey guys,
Looks like what you would expect when someone prepares propaganda for his own commercial baby using their own proprietary closed source test tool and methods.
Now that's rich. It's not my baby. There are actually a lot of things I disagree with or don't like in PhysX. If you go this way, my baby is Opcode.

As for the proprietary test tool and methods, dude, feel free to run your own benchmarks and publish your own results. The closed source thing is just a good excuse to justify people's laziness. I don't need to reveal to the world the fiercely guarded secret of how to create a box stack in Bullet, do I? :)
I do find it very interesting commercial PhysX being defensive and apparently threatened by the free, permissive, and open source Bullet.
You are completely misreading it. We don't feel "threatened" by Bullet at all. However I do feel pissed off by people claiming that Bullet is more optimized than the CPU version of PhysX. That's the only reason why I included Bullet in these graphes, as I clearly explained. I need a link to point people to, for the next time I read some BS on some forum.
Sadly for Pierre and his colleagues, PhysX's restrictive licensing, and nVidia's territorial hardware shenanigans really hurt devs and end-users, and therefore PhysX adoption by many.
PhysX adoption looks fine to me. I may be completely wrong but it looks like a lot of actual games are using PhysX. On the other hand I don't see a lot of games using the open source competitors...

In any case I will try Erwin's suggestion for the last test, and update the post. For the other things though, if they're "not optimized" or "far from optimal", then I'm afraid my results are valid and I must keep them. That's exactly the reality check I needed for people still claiming that PhysX is not optimized. I think you understand this.

Other than that, I use a default collision margin of 0.04 for all shapes. I think I got that number from a Bullet sample, not sure. I don't think changing this value changes the performance much anyway. Seriously, I did try to make Bullet as fast as I could. There's a UI in which I can tweak all these options, and I actually selected the ones giving me the best performance/behavior (friction dir caching, warm starting, no split impulse, no randomize order for constraints, DBVT). ERP is 0.2, ERP2 is 0.1, margin is 0.04.

As for Bullet 3, I'm sure it will perform better but that's kind of irrelevant, isn't it? So will PhysX 3.4 and Havok X.Y, at which point we need to run the benchmarks again and see what we get.
Zogrim
Posts: 2
Joined: Wed May 15, 2013 8:08 am

Re: Great Physics Engine Comparison (PEEL)

Post by Zogrim »

really hurt devs and end-users, and therefore PhysX adoption by many
For a Note: 415+ released commercial games are currently using PhysX SDK on consoles and PC, not counting titles for mobile platforms.

As for Bullet, what is the number here - around 30 ?

Forgive my interruption :)
Pierre
Posts: 67
Joined: Mon Jul 25, 2005 8:56 am

Re: Great Physics Engine Comparison (PEEL)

Post by Pierre »

So I just tried setForceUpdateAllAabbs(false) but it doesn't actually change anything.

Here's the function creating objects, maybe you can spot something wrong:

Code: Select all

PintObjectHandle Bullet::CreateObject(const PINT_OBJECT_CREATE& desc)
{
	udword NbShapes = desc.GetNbShapes();
	if(!NbShapes)
		return null;

	ASSERT(mDynamicsWorld);

	const PINT_SHAPE_CREATE* CurrentShape = desc.mShapes;

	float FrictionCoeff = 0.5f;
	float RestitutionCoeff = 0.0f;
	btCollisionShape* colShape = null;
	if(NbShapes>1)
	{
		btCompoundShape* CompoundShape = new btCompoundShape();
		colShape = CompoundShape;
		mCollisionShapes.push_back(colShape);

		while(CurrentShape)
		{
			if(CurrentShape->mMaterial)
			{
				FrictionCoeff		= CurrentShape->mMaterial->mDynamicFriction;
				RestitutionCoeff	= CurrentShape->mMaterial->mRestitution;
			}

			const btTransform LocalPose(ToBtQuaternion(CurrentShape->mLocalRot), ToBtVector3(CurrentShape->mLocalPos));

			// ### TODO: where is this deleted?
			btCollisionShape* subShape = CreateBulletShape(*CurrentShape);
			if(subShape)
			{
				CompoundShape->addChildShape(LocalPose, subShape);
			}

			CurrentShape = CurrentShape->mNext;
		}
	}
	else
	{
		colShape = CreateBulletShape(*CurrentShape);

		if(CurrentShape->mMaterial)
		{
			FrictionCoeff		= CurrentShape->mMaterial->mDynamicFriction;
			RestitutionCoeff	= CurrentShape->mMaterial->mRestitution;
		}
	}

	const bool isDynamic = (desc.mMass != 0.0f);

	btVector3 localInertia(0,0,0);
	if(isDynamic)
		colShape->calculateLocalInertia(desc.mMass, localInertia);

	const btTransform startTransform(ToBtQuaternion(desc.mRotation), ToBtVector3(desc.mPosition));

	//using motionstate is recommended, it provides interpolation capabilities, and only synchronizes 'active' objects
	btDefaultMotionState* myMotionState = new btDefaultMotionState(startTransform);

	btRigidBody::btRigidBodyConstructionInfo rbInfo(desc.mMass, myMotionState, colShape, localInertia);
	{
		rbInfo.m_friction		= FrictionCoeff;
		rbInfo.m_restitution	= RestitutionCoeff;

	//	rbInfo.m_startWorldTransform;
		rbInfo.m_linearDamping				= gLinearDamping;
		rbInfo.m_angularDamping				= gAngularDamping;
		if(!gEnableSleeping)
		{
//			rbInfo.m_linearSleepingThreshold	= 99999999.0f;
//			rbInfo.m_angularSleepingThreshold	= 99999999.0f;
//			rbInfo.m_linearSleepingThreshold	= 0.0f;
//			rbInfo.m_angularSleepingThreshold	= 0.0f;
		}
	//	rbInfo.m_additionalDamping;
	//	rbInfo.m_additionalDampingFactor;
	//	rbInfo.m_additionalLinearDampingThresholdSqr;
	//	rbInfo.m_additionalAngularDampingThresholdSqr;
	//	rbInfo.m_additionalAngularDampingFactor;
	}
	btRigidBody* body = new btRigidBody(rbInfo);
	ASSERT(body);
	if(!gEnableSleeping)
		body->setActivationState(DISABLE_DEACTIVATION);

	sword collisionFilterGroup, collisionFilterMask;

	if(isDynamic)
	{
		body->setLinearVelocity(ToBtVector3(desc.mLinearVelocity));
		body->setAngularVelocity(ToBtVector3(desc.mAngularVelocity));

		collisionFilterGroup = short(btBroadphaseProxy::DefaultFilter);
		collisionFilterMask = short(btBroadphaseProxy::AllFilter);

		if(desc.mCollisionGroup)
		{
			const udword btGroup = RemapCollisionGroup(desc.mCollisionGroup);
			ASSERT(btGroup<32);
			collisionFilterGroup = short(1<<btGroup);
			collisionFilterMask = short(mGroupMasks[btGroup]);
		}
	}
	else
	{
		body->setCollisionFlags(btCollisionObject::CF_STATIC_OBJECT);

		collisionFilterGroup = short(btBroadphaseProxy::StaticFilter);
		collisionFilterMask = short(btBroadphaseProxy::AllFilter ^ btBroadphaseProxy::StaticFilter);
	}

	if(desc.mAddToWorld)
//		mDynamicsWorld->addRigidBody(body);
		mDynamicsWorld->addRigidBody(body, collisionFilterGroup, collisionFilterMask);

	if(gUseCCD)
	{
//		body->setCcdMotionThreshold(1e-7);
//		body->setCcdSweptSphereRadius(0.9*CUBE_HALF_EXTENTS);

		body->setCcdMotionThreshold(0.0001f);
		body->setCcdSweptSphereRadius(0.4f);
	}
	return body;
}
DonTzzy
Posts: 4
Joined: Tue Sep 13, 2011 11:14 pm
Contact:

Re: Great Physics Engine Comparison (PEEL)

Post by DonTzzy »

Try Havok vs. Physx instead....

....instead of a comparison vs a "hobby project"...

But, from the last 3rd party benchmarks that I've read...Havok owned Physx. So, the "bullying" on Bullet, is understandable....
Pierre
Posts: 67
Joined: Mon Jul 25, 2005 8:56 am

Re: Great Physics Engine Comparison (PEEL)

Post by Pierre »

In fact here's the whole PINT plug-in: http://www.codercorner.com/tmp/PINT_Bullet281.rar
Pierre
Posts: 67
Joined: Mon Jul 25, 2005 8:56 am

Re: Great Physics Engine Comparison (PEEL)

Post by Pierre »

Try Havok vs. Physx instead....
Do people actually read blog posts? I did try Havok. Five versions of it.
RBD
Posts: 141
Joined: Tue Sep 16, 2008 11:31 am

Re: Great Physics Engine Comparison (PEEL)

Post by RBD »

Yay for the excitement.

I'm sorry you were insulted by my post Pierre. To be clear I did not state that you were purposefully misleading with your results. I was simply pointing out, that as a study or review, your blog post raised all of the red flags for bias (in a systematic review sense). I'm certain as a person with a scientific background you can appreciate this simple fact.
Zogrim wrote:As for Bullet, what is the number here - around 30 ?
:roll: Neither you or Pierre can possibly know since Bullet's license (as well as several other open source physics engines with zlib license) do not even require developers to ever disclose that they are using (or parts of) Bullet (contrary to PhysX's license that actually require developers to not only plaster NVIDIA all over their packaging, but credit PhysX in the marketing, opening marquee / credits screen, about box, etc.). What's funny is how many 3D suites now boast that they are using Bullet yet they don't have to.
Zogrim
Posts: 2
Joined: Wed May 15, 2013 8:08 am

Re: Great Physics Engine Comparison (PEEL)

Post by Zogrim »

RBD
Neither you or Pierre can possibly know
Oh. I got it. "Believe" :)

contrary to PhysX's license that actually require developers
Depends on actual licensing case, and even so, developers are not following it very often anyway.

Yay for the excitement
Conflict is the core of the drama :D
Last edited by Zogrim on Wed May 15, 2013 3:52 pm, edited 1 time in total.
Pierre
Posts: 67
Joined: Mon Jul 25, 2005 8:56 am

Re: Great Physics Engine Comparison (PEEL)

Post by Pierre »

To be clear I did not state that you were purposefully misleading with your results. I was simply pointing out, that as a study or review, your blog post raised all of the red flags for bias (in a systematic review sense). I'm certain as a person with a scientific background you can appreciate this simple fact.
What I appreciate is that people should not blindly take anything they read on the internet for "the truth". This applies to my post, regardless of who I work for. And this applies to people claiming that PhysX is not optimized, or that Bullet is faster. This was precisely the point of my post.

On the other hand you did call my prose "propaganda", so, yeah, I'm afraid you did imply I was purposefully bending the truth here. I'm certain you can appreciate that :)

I can only repeat what I already said: don't take what I wrote for granted. You don't have to. Please do your own tests if you have doubts. Or even just to double-check, it's always possible that I misused Bullet. But if I did, it was certainly not on purpose.
RBD
Posts: 141
Joined: Tue Sep 16, 2008 11:31 am

Re: Great Physics Engine Comparison (PEEL)

Post by RBD »

Pierre wrote:On the other hand you did call my prose "propaganda", so, yeah, I'm afraid you did imply I was purposefully bending the truth here. I'm certain you can appreciate that :)
My exact words were: "Looks like what you would expect…". What I strongly implied was that you have a vested interest in the results, created them, and are using them for promotional purposes, since you work for NVIDIA and on PhysX, thus are absolutely biased. You defensively took my calling it "your baby" as an insult for some reason, while I was simply using the expression to mean that you worked on it. Sorry if this is a red button for you.

Or am I completely wrong... are you not employed by NVIDIA and working on the PhysX product? If not, then I take back all that I said, and apologize profusely.
Post Reply