PhysX 4.1 in Unity - experimental builds

Sounds great Anthony!

Will the builds be always editor only or can we eventually get a build that can do standalone builds?

Standalone builds would ease the testing a lot as there are limitations in the editor: interpolation doesn't appear smooth in the editor due to lack of proper vsync, can't profile the real perf figures, can't use 2019.1 incremental GC which works only in builds (when custom build gets out for 2019.1).

 

What about a Windows build?

Greetings,
Jakub

 

Does that mean we get articulations, too? Is the API for that exposed?

 

Awesome stuff! I love seeing these early builds. Unfortunately I won't be able to participate until there are win editor builds and some of the new features - 3d wheels and articulations.

Keep up the good work mate. Exciting times!

 

Great to know that PhysX 4.0 is on the way to Unity! I'll jump into testing it as soon as there's a Windows build available

 

MAC??!!

 

You can read more about it here: https://en.wikipedia.org/wiki/MacOS

 

(Feedback)

The differences appear tiny:

1. Cloth is not game breaking and never was for the past couple of years, it's purely visual response so that should be a welcome change really.

2. Terrain is fine - and indeed we need the update for terrain holes to work properly without hacks. So that's fine too. Thickness was never a good thing anyway, we can just use continuous for proper collision. So this is all fine.

3. In general Unity shouldn't divert from Physx. So if it doesn't support trigger->trigger then simply don't support it. It's absolutely trivial to work around, so publish workarounds in the release notes and wait to see if anyone actually still needs help after the workaround.

For example one can simply do an overlap check between two bodies, or a trigger can be triggered with a non trigger on an exclusive layer if performance is a concern. Regardless, 3 is the only potential sticking point I can see, something that can probably be designed out with workarounds clearly written in the manual for trigger events.

The manual should be containing relevant code for workarounds and redundancy, not just the odd frankly often useless example.

 

Any plans to support GPU rigidbodies?

 

Oh yeah, you mentioned it in another thread. I guess it's easy to forget if you don't work on it directly. I guess there's no performance increase to it either?

 

Does any of this happen to help with the issues that come from moving too far away from (0,0,0) and possibly help allow for large world sizes or is that not fault of the actual physics system itself and physics issues end up being a side effect of a different issue?

 

I'm pretty happy about the deprecation of terrain "heightmap colliders". I often experienced weirdness with these. I think it has something to do with starting a CapsuleCast very "close" to the terrain, in which case the hit is sometimes not detected and behaves similarly to starting the cast already intersecting with the terrain. Maybe due to numerical imprecisions? But the float distance from terrain wasn't THAT small. Usually about 0.01f or something

I agree completely. The best way to let users know they are using an ugly hack is to not make that ugly hack available in the first place. Otherwise many people may end up using that feature without knowing it's very sub-optimal. I'm very in favor of breaking-changes in general.

I would be glad to do a little performance comparison report with my character controller as soon as a Windows build is available. Based on those features I'm guessing the gains mostly affect rigidbody/joint simulations and not physics queries, but you never know. Maybe the new broadphase accelerates queries

 

Exactly! ugly hack becomes first class exposed citizen now Unity's hinted that it's time to expand a little. Lets expand somewhere really useful.

And as you got further from origin, I suspect it just crapped out more.

 

While I understand that point of view, backwards compatibility has always been important for Unity - unless there's some pressing reasons to not have that (for example if maintaining the backwards compatibility makes the system worse for everyone).

 

Well, I mean, this sounds like it might be one of those times. He did say that it is no longer even supported by PhysX, which means time and resources would have to be spent to implement something that is already a bad/wrong way to go about something, which essentially means that it is worse for everyone, no?

 

It's not worse for everyone if people know to avoid it for new projects and old projects that relied on it wouldn't break in all directions. This kind of case would really boil down on how complex and hacky the workaround would need to be. If it's not big deal, why not make it?

 

I mean, I guess that just comes down to individual preference. I, personally, would rather Unity say "Hey look guys, this thing is no good, it is being removed/deprecated in a coming version, so just know that if you want to upgrade your project to that version, here is what you need to change" and then focus their efforts elsewhere on better and more important things. It is not like it is being ripped out from under anyone and they wake up to an auto-update that broke their project.

 

I can't say that trigger->trigger is good or bad when it's not really explained what is meant by that. Do you mean two colliders set as triggers could cause collision events if they touch? If so, yeah the fact that even worked sounds like a bug.

if something else is meant, please explain.

 

I think they mean trigger/trigger overlaps will not generate OnTriggerX events

This is no big deal because if you need that you could easily attach a script that does Physics.OverlapBox to detect this

 

Hmmmm. Triggers vs triggers support going away is a pretty big blow to me. I'm currently building a game that has lots of individual elements (fire, water, wind, etc...) that are tracked by many triggers for performance. They need to be able to detect eachother, it's already hellish enough just to keep track of what is overlapping what due to the missing OnTriggerExit messages when objects are disabled or destroyed. I guess this means I should start working on a custom broadphase and overlap solver. =<

 

This needs the "floating origin" feature to be exposed in Unity. PhysX already has this feature since PhysX 3.x at least. Honestly, I expected the floating origin to be considered after the update to PhysX 3.4. Now we would have to wait until the PhysX 4 integration is stable? I hope nVidia doesn't release PhysX 4.4 immediately afterwards then!

 

A cloth per job is a major upgrade I think It's not per vert (probably need an ECS rewrite I guess?) but I'll take it!

DOTS is the right platform for a physics rewrite that would essentially give us origin shifting for almost-free, in a single frame, among other powers, so I wonder if Unity's just trying to buy enough time for ECS to mature in this respect. I mean, it's probably why voting is a bad idea

 

This is very exciting, however lack of trigger to trigger collisions is a total deal breaker to us. A significant part of our game relies on being able to get trigger-to-trigger events - for instance, we never want any physical outcome for unit-on-unit intersections (which we would get if we used real colliders and rigidbodies), even if those very same unit triggers are used for some real collider events in other places. Any game relying on trigger "sensors" gets a ton of use from trigger-on-trigger events.

 

trigger<>trigger is possibly the easiest thing to code (and would have infinite performance basically in ECS) so I can't help but feel it's basically like using a bomb to swat a fly... Maybe it should be a package "Sensors", working with 2D, 3D, anything really...

 

Tried a quick perf benchmark that looks like this:



This is 1000 "characters" moving. The characters consist of:

• A CapsuleCollider
• No rigidbody (there is not a single rigidbody in this entire scene)
• Several CapsuleCasts, Raycasts, OverlapCapsules, ComputePenetrations every FixedUpdate

The results are all in-editor since there's no build support. The millisecond measurements are the cost of the total FixedUpdate where all the Physics queries are happening:

• PhysX 3.4, SAP: 14.2ms
• PhysX 4.0, SAP: 18.8ms
• PhysX 4.0, ABP: 17.4ms on average, but fluctuates a bit more than SAP. Some frames are costlier than SAP, most are less

I'm not too surprised about the fact that it is more expensive in PhysX4 right now since it is an early build, so I think this was to be expected. On the other hand, ABP broadphase does seem to bring a slight benefit in this case. Also I do realize that the changes brought by P4.0 are mostly about rigidbody simulation performance and joint solving quality, but I think those are interesting numbers nonetheless (could be indicative of an issue)

But I'd be curious to know if PhysX 4 brings other changes that may have caused this performance drop. For example; I know a while back, making rigidbody-less colliders move was more expensive than making colliders with rigidbodies move. This disappeared at some point but I wonder if PhysX4 brought this back?

 

Hoping to see better stability for joints in Unity with the 4.0 release. Is that accurate?

 

I just tested the beta version and I have to say that in my case (constrained vehicle, that is rigidbody wheels connected to vehicle body with a configurable joint) the new solver gives clearly better results, altough now is much more sensitive to "external intrusion" (in my case I was applying the suspension force externally with a script without using Y Drive). Switching to Y Drive as suspension force has solved the issue.
Now I would like to know how to convert standard suspension force unit (N/m) and standard damper rate unit (N/m/s) to Y Drive position spring and position damper. In my case for example, a value of suspension force of 80000 N/m and damper rate of 4000 N/m/s "convert" to a position spring of around 100000 and a position damper of around 2000. But this is only a guess.

Another issue that i found with the new solver is that now the contact points are less "stable":

Red lines are the contact points, white one is the centroid.
This doesn't happen with the old solver.

 

I use trigger on trigger a lot in the project I'm currently working on. I suspect that it's used liberally in 2D infinite flyer type games.

 

Check default contact offset if applicable.

 

Just got around to trying the new build and OMG that TGS solver is a godsend! Its error recovery for joints is so much better! I built a really naive chain (out of character joints) and it not only held it's weight, dragged over objects correctly but it also recovered from errors way more elegantly than the old solver. eg: if i pull the chain through a wall it will snap to the other side and resolve in less than a second. The old solver starts breaking just under the weight of the chain. 0_0 I cannot wait for this to be in a mainline version! I may actually be able to rely on joints now holy crap! That was with only 6 iterations. even with 128 iterations the old solver couldn't even hold the weight of the chain. Hype!

 

I tested with different values, but the issue is still present. Anyway, with the default value (0.01) the old solver doesn't show the issue, the new solver does.

 

Sure thing, sending it via PM since it's part of my asset store product

 

I wonder on how the recent GDC keynote on Havok and Unity Physics physics fits in all this:
https://blogs.unity3d.com/2019/03/19/announcing-unity-and-havok-physics-for-dots/

• Is Unity Physics based on PhysX, or it's an in-house development?
• If the later applies, will be PhysX abandoned? Would make sense to keep testing PhysX 4?
• Also, how the WheelCollider is implemented in Unity Physics? Any chance of doing things right this time?

There's a wheel and car parts company also named Havok, so its utterly difficult to find information on Havok wheel and vehicle simulation xD

 

This would probably be a better place for asking these questions: https://forum.unity.com/threads/unity-physics-discussion.646486/

In short, Unity Physics is a new DOTS package, coming with full C# sources. It's been developed with Havok's physics team, see the this part of the GDC keynote:

Additionally there will be full c++ Havok integration but we don't really have specifics on that yet, like how much it will cost. Unity Physics package doesn't come with extra cost.

 

I have to admit this doesn't inspire confidence. Currently Unity Physics looks years away from being stable and usable. And Havok is behind a paywall. From what i've read so far this seems to mean there won't be a free, stable and performant physics option for ECS... =<

 

The worry is on PhysX getting left behind for people who move to DOTS and having only possibly expensive Havok option there if you need stable physics. For example right now Unity Physics can't deal dynamic vs dynamic stacking at all and it's considered as a feature (I hope this will be dealt with eventually).