Discussion Unity.Physics or Havok?

Unity.Physics or Havok?

I'm trying out DOTS. It seems now we have two options for physics? Which are Unity.Physics and Havok. All that is clear to me is that Unity.Physics is stateless while Havok is stateful. Havok claims to be more performant than Unity Physics, but is it really? I mean, it says it's based on Unity Physics... which it also says to be written by Unity and Havok. It also claims to be used by many AAA games. So, which one should I use?

 

You should use Unity Physics until you outgrow it. You're way putting the cart before the horse, and both can be toggled interchangeably throughout the project. So you begin using Unity Physics.

Try the samples so you know, on github at least. Docs also cover the why, so this topic is pretty much answered in the docs themselves.

 

If you need a stable simulation (like a block physics game) then you should definitely look into havok as it definitely has a more stable simulation.

The stateless nature of Unity physics is really useful for multiplayer rollback though.

If you need a pro license for unity (200k [revenue|funding]/year) you must also pay for a havok license. $200/year/seat https://assetstore.unity.com/subscriptions/havok

Outside of that, don't overthink it.

 

Okay. Well, since I'd be relearning it from zero (I guess?) I thought I might as well start with the generally preferred one. I thought they'd have some differences in usage. I mean, one is stateless and the other is stateful.

This is what you meant by "more stable", right? I won't be needing physics this much, I think.
Right. I used to want physics rollback and on-demand simulation for multiplayer.
The extra licensing is nice to know. Thanks.

 

I found it's pretty much the same as Physx or any other physics library. If you have done one, you've done them all. Some differences in raycast behaviour and the amount of source access you have are pretty good.

 

From my initial tests Havok is faster, more stable (in terms of stacking not crashes) than Unity Physics. I do not see a reason NOT to use Havok unless the multiplayer thing mentioned above is important. When you get to the point where you‘d have to pay for it, you‘ll be like oooooh only 200 bucks? That‘s pocket money now.

Note: just switching physics engine may be technically possible but it WILL screw over every physics behaviour you tweaked so far. In essence you CAN NOT switch physics engines without starting the physics part almost from scratch!

 

I don't know about the underlying PhysX, but I found Unity.Physics and UnityEngine.Physics usage to be quite different, at least for collision/trigger event handling. Well, it's mostly due to DOTS. I mean, there's no way they can be the same, because DOTS and monobehaviour scripting are very different.

That's also why I assumed Unity.Physics and Havok to be quite different. I saw some Unity.Physics code requiring build physics world and simulation physics world objects. That's because it is stateless, right? Being stateful, I assume Havok doesn't require such thing, and that should make quite some difference.

 

Yeah, I fear that. Telling unity to switch physics engine might be just a toggle, but that might as well be a toggle to break the game. It might be a big mess, and who knows if it's even possible to fix. Unity claims that the transition is seamless but I doubt that.

But that's not all. If I happen to need the other engine, I'd need to know enough about it too, to a similar level of how much I know the previous engine. It would be hellish trying to fix the mess created by switching while being a noob. So I'd like to avoid changing engine as much as possible by choosing carefully at the beginning.

Yes, even for that reason (or excuse), this might be too early, but I want this discussion to exist since all I could find were just the claim and some performance and stability comparison.

 

The stability testing between the two is also included in the ECS samples on github. You will see rationale and comments about smoothing over contacts on the ground, or general stacking strategies.

Stateful vs stateless is one part (joints, stacking, stuff that has a lot of forces acting on things) and polish tweaks are another (raycasts over triangle edges, general contacts etc).

Behaviour differences also have samples / comments so it's really worth going over those docs and samples.

A driving game or FPS would probably be fine with Unity physics with no need to change. Consider most games out there don't make full use of Havok either.

 

Alright. I'll check the docs and samples. The samples is this one, right? As for the docs, I'm not sure which one would give comparisons or tell the differences. I found the docs of the packages (Unity.Physics and Havok), but the Havok one doesn't seem to explain much. Maybe they're really that similar to not require much additional explanation?

 

Hmmm memory is sketchy, there's a couple of samples that help explain the differences. One of them goes over bumpy vehicle behaviour on a mesh and demonstrate how to fix it in entities by using a system. This IMHO is a good sample because it's modifying how the raycasts for the wheels respond. Then, instead of bouncing in the air, the vehicle is under control. The reason it's an important sample is because Havok (AFAIK) does not need this extra code, but Unity Physics does. So having those A-B tests is useful to you.

So Havok indeed has better polish in things like that. I am probably sticking with Unity Physics and going to fix that up instead as I want to have multiplayer with DOTS as well.

Sorry can't be more helpful, but do post a lot in this part of the forum, the people here love problems that are well defined but tricky.

 

The havok visual debugger is miles better than the current unity debugging script/mode(which is terrible in any scene with more than a couple colliders), its pretty much a reason in itself to use havok over unity physics. You can also scrub back in time using it which I assume Unity Physics will never have an equivalent for.

This is anecdotal and maybe I didn't do enough testing but with making a retro shooter, I couldn't get contact welding script from the Unity Physics samples working to a good enough result vs using havok.

Additionally stable stacking/not have rigidbodies slowly "creep" is something that cant be understated for a scenario as simple as: having random objects on some sort of surface(bottles on a table) that don't slowly travel on their own - there are ways to mitigate this with Unity Physics but imo its easier to just go havok(something more complex like a pile of ragdolls will always be traveling with unity physics, they will never stop moving).
I'm not dealing with networking though.

Being able to switch architecture from havok to unity physics and back with just a flick of a switch is really quite amazing though, from my perspective there's almost no perceived difference in api or general behaviour between one or the other. At the end of the day it really does seem to boil down to stable stacking vs networking rollback but its so easy to switch so no excuses not to have a play around with both.

 

So basically, Unity physics could use a bit of love as far as 0.5x is concerned.

 

The visual debugger seems cool. I thought it didn't matter much since the docs doesn't say much about it. Never thought I'd want this kind of thing.

Havok docs says contact welding adds some performance overhead though, so it's not enabled by default. I bet it's just so you'd manually select which ones to contact-weld. In actual usage, is the overhead significant? How about for mobile?

Rigidbodies always moving (even just a little) sounds concerning... But if it's a known issue that with a known fix it might be fine, I guess? That's, like, how Unity has always been lol. But hippocoder also mentioned a raycast issue with a fix; are they the same? Well, I hope there aren't too much issues even if it's fixable... Workarounds may cause more problem in the future.

But if they're really that similar in usage and easy to switch between, it won't matter much which to start with (unless doing much physics stacking or rollback).

Sorry but what's 0.5x?
Edit: Oh, it's the version isn't it