With your signature you should be able to work scientifically at least to some degree and come up with a nice chart on your own, right?
I’m still waiting for you to enjoy us all!
I found this, but unfortunately it’s based on some very simple physics examples:
http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=6&t=5509
Here’s another post with more info:
http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=6&t=3517
Yeh,
Point out a random game is useless, Call of Duty 4 uses ODE physics. 
My fav still Havok.
You don’t need such a chart for the trivial reason that Unity isn’t using thats not present in every physics engine that exists on earth including even ODE I think and that although ODE was and still is primarily a collision engine, not a physics simulation engine.
When developing Unity 3.0, we did have the option to switch physics engines, as we were not required to keep web player backwards compatibility. We did evaluate both Havok and Bullet at the point, and came to the conclusion to stay with PhysX (at least for the time being).
Havok has great performance, but is less flexible in some ways (for example collisions of cloth objects with arbitrary meshes were not supported last time I checked), plus it would not fit with Unity’s licensing model. We doubt most of our users would be happy to pay per title license fees for using physics.
Bullet looks very promising, but when we evaluated it a bit over a year ago, we were not quite convinced of it’s performance and proven track record. Still, I believe it is something to keep an eye on.
Instead of another physics engine, I would love to see some hooks to write your own. I ported some of my old code that simulates fly casting to Unity/C# and it really took a performance hit (this code runs fine on 10 year old 500 Mhz machine). I know I can write C++ plugins (and probably will) but then I lose the web player option.
Been playing around with shaders/CG and that kind of wrapper could work for managed custom physics that runs fast.
@jonas echterhoff
I don’t know how much time you’ve invested into investigating those options, what you did investigate exactly or how experienced you are with the subject but Havok in many cases has much more to offer compared to PhysX that it’s a shame not taking the opportunity to switch if you could. It’s really sad…a wasted chance. I would even say that depending on what you’re doing Havok is the only serious physics engine out there.
This is like saying we’ve looked into Unity but we’ve decided to stay with Torque.
I’m hoping to get a) a seriously improved PhysX in Unity for now and b) Havok support in Unity for the future. And just as a note, i wouldn’t mind the switch also in a V3.X, no matter if things get broken once again.
Im not sure that it does, as I have run some simulations, and in unity I bottleneck around 2500 objects, but with PhysX libriaries sims I have been up around the 25000 mark…
However, these are not definitive or nessarily repeatable.
You appear to have missed Jonas’ point entirely. He didn’t say PhysX was the best option, or that Havok was worse, he merely pointed out 1 technical point that featured in their decision and then stated the real reason why they chose not to use Havok over PhysX. Let me bold that part for you:
I’m pretty sure the majority of Unity users wouldn’t like to pay additional engine licensing costs for every game they wanted to release, i’m certain I wouldn’t.
Scripting in Unity usually runs at a pretty good percentage of native speed (the terrain engine is mostly C# scripts for example), so there’s no reason why there should be much of a performance hit.
–Eric
You have to consider that they may have approached Havok, but Havok might not have been interested on partnership. I may be wrong but it seems to me that Havok policy is more per product based, not Engine partnership. Also Havok lacks iOS support which is one of the main pillars of Unity success.
Btw, don’t get me wrong, I’ve worked with Havok before and I trully recommend it, but that doesn’t necessarily means it is the right tool for Unity at this moment.
Cheers.
Its a tradeoff, things could break if switching over Havok, but you are getting a performance return which is always a winner.
Btw, even if things breaks, i still believe it wont hurt that bad.
If the license was a problem, i think Havok now is eating their fingernails. Unity is spreading like a virus, it could be a very good chance of spreading its middleware popularity, too bad Havok, too bad Unity.
Please, bring havok to Unity!
Indeed but on the other hand Bullet would $0 vs $50k / product for PhysX and that with bullet supporting about all platforms Unity offers not just windows, x360, ps3 and since about 1.5 months OSX
And bullet is the only solution that plans to support OpenCL.
Havok kills itself out on its own by focusing on DirectCompute instead of OpenCL which is not even a topic for Unity as U3 decided to remain on DX9, NVIDIA so far didn’t talk about the future of physx at all, ie if its intend to die in 2011 or not (if they don’t move on to OpenCL, then this year will be the last one where big projects will touch it at all as the CUDA only arrogance isn’t acceptable anymore with AMD having more raw TFlops than NVIDIA yet PhysX refusing to use them due to using a non-cross tech layer if a cross tech standard layer would exist with OpenCL)
The only reason people hammer around on Havok as far as I see is likely not even the physics, but the hope that other Havok Systems might be added once the physics is present.
Going by the speed at which already standard physx features and the console fundamental multithreading safeness and usage were added that would then be by Unity 7 in 2018
@Kilah NomadKing
The way i know some of them, i would be surprised if you can’t get a reasonable agreement with them.
The current lack of iOS support for sure is a minus but you already have the situation that Unity works different according to the platform like different renderpaths/scripting options/input possibilities/… so supporting PhysX on iOS/Android until Havok shapes up there as well whilst using it on other platforms already can make sense.
snip
Advanced Cross-Platform Optimization
Havok Physics is optimized for use on Microsoft® Xbox 360®, Sony® PLAYSTATION®3, Nintendo® WiiTM, Sony® PSPTM, Mac, Linux and PC. The Havok Physics SDK is fully multi-threaded and hand optimized to make full use of the available hardware on all supported platforms.
snap
@Dreamora
I guess you never used Havok in a project on your own before. Remembering your posts it’s interesting how fast you turned from a Unity/CUDA lover to a Unity/CUDA hater. I doubt your raw power argument pro ATI as much as i can understand that OpenCL is as (un)sexy as OpenGL is, for the good as well as for the bad.
Thats no option using 2 distinct physics engines cause the differences in supported combined physics bodies etc is too large.
It would definitely break the crossplatform targeting with little effort as you basically have 2 different games if its physics dependent (ie uses physics for more than just collision detection)
Of course it is/can be.
If switching to Havok meant having to pay an additional fee per title, that would definitely not work for me and I’d have to switch game engines (as would a majority of Unity users I suspect).
I wonder just how feasible a Bullet physics plug in would be? How much more difficult would it make our job of using physics in our games? Would game performance really drop, considering Unity’s PhysX implementation only uses one core and a Bullet Physics plug in might be able to use 4 or more cores?
I’d be interested in learning more about the decision making process Unity Tech used to decide not use use it? Could we get some specific info on what Bullet lacks (or lacked at the time) which prevented UT from using it? I recall reading some years back how big a project porting PhysX to a Mac was for the devs back in the Unity 1.x and 2.x days, wouldn’t using Bullet then mean fewer man hours to implement and update in the future?
On the subject of physics engines, has anyone looked at this before? AGX Dynamics and Unity - Algoryx
I love CUDA for what it is, worked with it for months.
But not for physics cause AMD never implemented drivers for it unhappily (NVIDIA used open / licensable tech to write the cuda compiler and was always open about it, none the less ATI decided to not support it and came up with an own competition that was proprietary and was at no time able to compete even the slightest bit with CUDA.
OpenGL might be a discussable topic due to Apple being the most incapable company on earth when it comes to not fucking up drivers or getting their OpenGL up to date. Being as much worth as apple and being even more incapable at writing non bugged drivers than AMD just isn’t reasonable and I hope they are finally going to do something about it or alternatively go to hell with desktop OS and focus on iOS only.
But for OpenCL it is a whole different thing because that one will be adopted seriously as its or large business and scientific interest. ATIs previous CUDA competitor was nicely put shit, DirectCompute is Windows only.
Even Apple has some rather solid interest making OpenCL working solidly (something they don’t seem to have for OpenGL, as they didn’t even reach OGL 3 yet and have a rather strange way of deciding what extension they intend to support and which not)
Also, as mentioned, OpenCL 1.1 is supported on mobiles, something neither CUDA, ATIs proprietary layer nor DirectCompute offer.
Unity is great but you know that U3 is not what people expected from a new major version and that the threading problems and lack of multithreading is something inacceptable for a new engine major released 2009+, not considering the other problems (new major, still no softbody, wtf?)
You can not even do WWW requests in a components awake if the component is in the first scene on windows cause you have a 50%++ chance to get struck by a “get thread context” crash since 2.6 when async WWW was put in.
Umbra has some serious bugs (stuff blinking out although its fully in view, though generally the bounding volume handling in U3 has problems) and isn’t using Occlusion Queries on hardware that would support it, beast has several minor to major problems too, making both new “pro features” more of a “forseight of where we are going” for serious use than new features of 3.0
You had your own share of problems from what I recall, so you know what I’m talking about.
Hey, you don’t have to tell me. :O)
I’m very honest and direct with my opinion/experiences and got critisised quite often for beeing so, although it often turns out to be true.
I know, I’m no different from that and get burnt for it rather regularly too but also have great days cause I’m honest and straight in both directions. For example I love unitys editor scriptability and the fact that it can be extended rather well (less with U3 than U2 due to some artificial limitations but still much more solid than many to most other engines if done without touching sources) and U3 was another step forward on that end especially for iOS 
I hate talking around the stuff and put stuff “nicely” if it isn’t, it does not help me nor anybody else, it just wastes time and makes the topic 10 times more complex to handle in the future.