Why the heck is almost every game engine trying to switch over to Bullet physics ?
What is so special about Bullet ?
Itās good, itās fast and itās open sourceā¦ What more do you want?
I wish Unity would switch tooā¦
If they did would that not kill the physx systems already in place? Meaning, the previous physx would not work under the new compiles.
BTH
Plus from what Iām told Bullet doesnāt have some of the weird idiosyncrasies of PhysX, like how colliders tend to bounce rather than just touch, or joints go nutz under tension. These things in PhysX make simulating certain behavior nearly impossible.
I suspect that the biggest reason Unity wonāt switch is because it would likely break all earlier webplayers, although I also wish that either PhysX were made more robust/accurate or they added Bullet as an alternative physics engine (something like how some other engines allow you to choose which engine you want to use for a particular build / project).
I wonder if it would be possible to add Bullet as a Unity plugin (.DLL)? If so, would it perform as quickly / efficiently as if it were built in (or nearly so)?
You could definitely implement Bullet as a plugin, but it wouldnāt be as efficient as a built in system. Iām not sure how much of a hit youād take performance wise, but a lot of marshaling/unmarshaling could probably be avoided by using blittable types. My gut feeling is that it would be a fair amount slower, but acceptable in cases where PhsyX is just not working for you at all.
Iād also love to see Unity switch over to Bullet, even if it was just an option for standalone builds.
Because itās free and good enough for a number of use cases.
Secondly itās nothing new that quite some people also like to switch because it might sound hip but have no real clue what they are talking about. Havok in many cases still is #1 and itās the engine i would like to see in Unity. PhysX offers, if the API is fully exposed, quite some possibilities Bullet doesnāt offer.
You can be sure it has: just use the bullet physics from blender game engine and you will see how ugly it can beā¦
Iāll happly second the vote for Havokā¦ of course those Havok folks seem to think theyāre #1ā¦ so iām not sure how open theyād been to licensing for an engine that isnāt a rounding error-close to their prices 
Cheers,
Galen
Quite the opposite actually. We did evaluate Bullet for Unity 3.0.
The stability of simulation in stress situations was better in PhysX than in Bullet. Performance wise PhysX was also faster than Bullet.
The biggest reason for us to stick with PhysX however is that we donāt like breaking backwards compatibility very much. Other engine vendors usually donāt really care much about making it easy for customers to upgrade projects to newer versions, but we feel this is quite important because when we add new target platforms we want to make it easy for everyone to target that platform.
1 Like
Unity 3 and Unity 2 already use two separate webplayers; Unity 3 content canāt be played by the Unity 2 webplayer at all.
āEric
Havok is just more serious were others are blenders or offer no solution at all plus there are very intelligent, mathematically gifted people behind Havok. I think if you enter negotiations the right way, almost everything is possible.
Could you share what you did to evaluate Bullet? Does anyone know of any videos that compare Bullet in action versus PhysX? Iāve yet to see a side by side comparison anywhere.
On a semi-related subject, Iād love to see a tutorial or documentation on how to work around some of PhysXās āodditiesā. Some things, like joints that go bizerk when under tension, are awefully hard to work around as there isnāt any way, currently, to measure tension on a joint. Play around with Jakeās rope script if you donāt know what Iām talking about.
In the end, Bullet is the only crossplatform technology that crosses with reasonable support to more than Windows - PS3 - X360 - (Wii) as Havok and PhysX and that without bloat bombing (problem for mobile where the 9-14mb and webplayer)
Havok would be nice, but havok suffers near the same problems as PhysX: No OSX support (physx by now does but the same bad performance as pure cpu on windows)
Also PhysX is the worst case solution if the Win CUDA support is not used at all cause it has the worst pure CPU performance of commercially viable technologies, only Newton used to be as bad and its license never made it a reasonable tech for any use.
And breaking the old stuff can no longer go through as a reason for not switching cause PhysX in U3 already caused enough trouble and none of the new physic features in U3 aside of collision layers work well enough if at all to be even considered for production use.
Trivialities and standards like Softbody physic, water blocks and force fields are still missing after years of PhysX focus so the interest and focus on it seems to be more of a minor focus than a major focus.
So technically there is no better time to switch, what they have is either just simple rigidbody physics class support or broken (clothing).
Its clear that this path wonāt go any further as people expect 2010 class physics and NVIDIA has not even handed out an ETA for PhysX OpenCL from what I recall, so a switch to something that either accelerates through standard shaders like Havok or has serious multicore power like Bullet (which are working on enhancing that with serious gpu acceleration, at which point they will crush physx if they refuse to switch to OpenCL) will soon become a must, no longer a āwould be really niceā as it was in the past. Even mobile devices support OpenCL, not just Windows and OSX, all without addon libraries, so for the sake of a future proof physics support, Bullet is the best possible solution.
Havok wonāt go to opencl as they donāt support any platform where it is the primary solution or required. On Windows they have DirectCompute and on consoles neither is required.
Where PhysX will go aside of āto hellā will have to be seen. They had a rather easy to port platform with CUDA focus before (compared to what havok has) and didnāt move the slightest bit yet, I donāt expect them to go anywhere before its too late.
Iām also confused by Joachimās statement about breaking backwards compatibility for V3 when looking at the mess Untity V3 can cause, both in terms of generally breaking things as well as focusing on physics (from broken stuff, different working things, half baked implementations, not beeing supported at all). V3 would have been a good chance switching to a more powerful solution or improving the already supported middleware. Iām curious about what kind of physics weāll end up once 2D is supported.
Iām all in for getting things broken when i get something really good for an exchange.
Iām laughing of those which are saying that Bullet is weird, has problems, and other stuffs. GTAIV has physics problems? No? Just asking, because it uses Bullet.
The only goodie with PhysX is that you can use GPU Acceleration (nVidia Only, and donāt know if Unity uses it)
Sometimes it already helps if you inform yourself about different solutions, their capabilities and their shortcomings upfront, at least before you post. You can google them all and read a little bit into the subject. Admittedly if you want to get a more solid understanding, you need to test them out on your own, compare them which is rather annoying because it takes time and you need some sort of understanding of the subject. Obviously itās more entertaining and takes much less work just to post some rant. Well, each to their own.
As much as I like bullet, and think itās a better move to āswitchā to it, the migration concerns are serious. Unity abstracts the interaction with the physics API well enough for a fairly easy transition, Iād think, but the behavior of different physics engines is, sadly, different in practice and you canāt just switch one without dramatic consequences to some projects. I think itād be best to have both running for one version of Unity to make the transition. For instance, Unity4 could support both, you choose which you want to use per project, and it could be made very clear that PhysX will not be supported in Unity5. That way, thereās more than enough time for projects to ensure theyāve migrated to the correctly behaving engine.
The way modern physics engines work, itās really not bad at all to abstract it this way, since theyāre running asynchronously anyways, so there really isnāt as much tight integration as it may seem. From a pure code standpoint, itās not much different than supporting multiple rendering APIs, itās just that changes in the output of a rendering API arenāt going to completely break a game like a physics engine can/will.
How do you know they didnāt have to do workarounds to fix problems with Bullet? Have you seen the source code? I havenāt used Bullet so I have no opinion one way or the other, but pointing at a random game is pretty useless.
āEric
I am still waiting on someone to point out a stat chart comparison between the two engines.