PhysX 4.1 in Unity - experimental builds

Yeah, i don't want to sound too negative here. The new physics engine looks amazing! There is a bunch of stuff that i absolutely love about it! However. It currently brings my computer down to a crawl on startup even with only a few rigidbodies, has random lag spikes, unstable stacks, currently tied to framerate, etc... This is all fine for an experimental physics engine! woo more early access to in development features yay! However... For those of us who would like to move to DOTS when DOTS is actually stable and supported (editor support, stable API, etc...) It currently seems like that will happen far before Unity Physics is ready for production.

At that point we have two options for actually shipping games as i see it. First: wrap the gameobject pipeline, which is time consuming, complex, and throws out a good chunk of the benifits of ECS, at least for said physics objects. Second: Pay an undetermined amount of money to Havok for an actually stable physics engine. Havok's business has trended towards AAA games super hard and often costs $10,000 minimum to license. This scares me. 0_0

This is why I and others have been pestering for information about a physX ECS integration. I want to know that if i move my project from GameObjects to ECS, that I'll be able to ship a game that uses physics, which most games do in some capacity.

tldr: This announcement makes me very scared to invest time in ECS since i can't be sure it will have a stable physics engine i can afford. =<

// EXTRA

Ok, this is sounding super negative. Some love for the new physics engine: Joints are super stable! Objects don't spaz out... like ever! I dropped a several hundred thousand kilogram thin slab on a bunch of 1kg cubes and it just squished them, no random spazing or anything. with 4 iterations! It's open source and the source looks not too complex! Plus it's layered so if you just need queries and no sim you could do that i think, which is awesome! I love the robust colliders and queries! I love the fact colliders have a radius! I love that it includes determinism, immediate mode and stuff even though i will most likely never use it! It looks super promising! I can't wait for the day it's production ready. =3

 

Thanks for the clarification Anthony! Those are good news for sure. Certainly, the information has been quite confusing so far but now I have a clearer picture.

Joachim Ante explained it further in this thread.

As I'm understanding DOTS / ECS so far, it seems a kind of "C-style", lower-level C# where we go back to use structs and indexes instead of classes. This brings outstanding performance, but the examples I've seen so far look more complex and more difficult to maintain than standard C#, GO-based code (in the same sense as a C vs. C++ comparison).

So I'm happy as we can continue using the same GO-based workflow in Unity, while we wait for DOTS and its modules to be more settled. Then we could consider porting relevant parts of our projects to it.

I'll be testing the new PhysX 4 integration soon with some specific tricky situations.

 

There's also the fact the DOTS implementation is bad. RE: see the problems with stacking.... Saying Stacking isn't supported is a dodge at a real problem. Until Stacking works in DOTS, it's unusable.

 

Sure but we can't even stack 3 cubes at the moment. That's a strange place to be... I thought it would just be a WIP thing, but havok staff did say it's not going to improve. They clearly said the fact you can't stack anything is a feature.

That is a concern. I would expect a small amount of stacking stability - 3 dynamic objects covers basics. Certainly not expecting havok-level stacking here, but 0 stacking by design is a tiny bit strange!

 

Any chance to include the PhysX origin shifting feature in an experimental build? This is a must for open world, Unity still seems to ignore that... Please check this thread with more details: https://forum.unity.com/threads/fea...er-integrated-with-physics-like-on-ue.648736/

It would be awesome if we could call this function right on the PhysX to fix all positions for large worlds with good performance, instead of manually moving everything like with the floating origin script, which is not good for performance on real world simulations. Basically an optimized way of adding or subtracting a vector of all loaded objects positions.

 

I've been testing PhysX 4 joints extensively and well, I've barely found any improvement.

I've tested real-world configurations where different parts have very different masses. Results are almost the same as in PhysX 3. The Temporal Gauss-Siedel (TGS) solver seems to improve the results a bit, but it's still far away from being usable in real-world scales.

In the first video the excavator arm contains 5 articulations connecting 6 rigidbodies (including the excavator itself). I've tested it in three situations:

1. PhysX 3 with rigidbodies tweaked. Strong and stable articulations.
2. PhysX 4 using the default solver (Projected Gauss-Siedel) and rigidbody tweaks removed. Same result as with default joints in PhysX 3: weak, flaccid articulations that cannot even lift the bucket.
3. PhysX 4 as above but using the new Temporal Gauss-Siedel solver. A small improvement is observed as articulations seem to keep their rotation axis enforced. Other than that, joints are still as weak as before and are unable to lift the bucket.

The second video shows a heavy articulated vehicle where a small part (the dolly) supports a fully loaded trailer. The dolly is an independent vehicle connected to the front trailer and supporting the rear trailer. Everything using real-world masses.

I've recorder two cases only: with and without rigidbody tweaks in the joints. The result is exactly the same in both PhysX 3 and 4, in both PGS and TGS solvers.

There's no difference at all using the new PhysX with the new TGS. The WheelCollider seems to skip all that solver stuff and just messes up the vehicles by totally ignoring any joints or extra-supported weight. No surprise here, I must admit (PhysX's terribly designed and badly implemented sprung-mass model, ladies and gentlemen!)

Maybe there are other situations where TGS really makes a difference, but as for what I've seen, it's nowhere close to what we were shown in the promotional video.

EDIT: I've got a reply from an nVidia developer on Twitter explaining that the promo video uses a different set of articulations not yet exposed to Unity users. Certainly that explains why there's no significant difference. @yant also told he's working on exposing these articulations.

 

Sorry if this is a dumb question, but you keep saying "Rigidbodies tweaked" is there a place i can read about what you're doing here because it seems to have an amazing effect on the physX joint structures 0_0

 

I mean using fake mass and/or inertia in the rigidbodies, instead of leaving them with the real-world values. Similar to the options Mass Scale and Connected Mass Scale in the Configurable Joint, but without the evident side effects.

 

Have you tried going to ProjectSettings > Physics > "Default Solver Iterations" and increasing that number? Try testing with 255 iterations and see if the problem still appears (it's the max number allowed, but it''d be interesting to see if that solves it).

Physics engines will always have problems with high mass ratios. This super interesting video gives you an idea as to why that is the case:

You can think of the number of "clacks" in that video as being somewhat related to the number of iterations needed to correctly solve collisions between two bodies. And the more inter-colliding bodies are involved in a solver, the more the required iterations count grows (this explains instability of large stacks).

Physics work well in reality because real life has "infinite solver iterations" (and an infinitely small deltaTime too, which is why real life doesn't need ContinuousCollisionDetection), but CPUs can't afford this

 

The videos use the default iterations (6) because I just wanted to evaluate the new TGS solver. Using the same number of iterations TGS produces little to no improvement.

I've got a reply from a nNvidia developer on Twitter explaining that the promo video uses a different type of articulations not yet exposed in Unity. @yant told he's working on exposing them.

I've tested 255 iterations and it improves the excavator arm. It may be moved to some extent, but the articulations are still weak and oscillate significantly before coming to a stop. TGS makes no significant difference here.

In the case of the truck dolly there's no difference at all using 6 or 255 iterations. As for what I've experienced the WheelCollider seems to apply raw impulses to the rigidbody without considering anything else, i.e. other bodies connected via joints. Again, no surprise here.

 

Wow! That could actually be a game changer! Very impressive. Thanks for sharing!

No hurries. Knowing it's progressing so nicely is enough to me. I don't mind to wait a little longer for the integration to be as good as possible.

 

What a time for physic in Unity!

On another thread, here, NVIDIA is apparently "feeling the waters" on the subject of providing a package (that seems to work) which exposes PhysX SDK 4.1.

I've seriously considered that, or packaging 4.1 as a native library myself for use in Unity, because I must have the new articulated joints (robotics).

I loaded the PhysX SDK 4.1 to verify that the joints do exactly what I require, and I even seriously considered other game engines to gain access to it, but alas the shortest distance from here to a product is still through Unity. Even if I wanted to I can't justify moving to any other game engine. Performance on mobile is a particular reason, but editor performance on the desktop is another. There are always "issues" with any engine, but on balance the only thing I have a real, current problem with on Unity is PhysX without articulated joints.

The new Unity Physics engine will take a while to mature, so that's out. Havok is a mystery license, so that's out. One of those may be the best solution at some point, but I can't wait (business doesn't really care about emerging technologies).

At this point it's clear that for the product target on my desk I must use PhysX 4.1, with articulated joints in particular, by whatever means.

I am, therefore, highly focused on this thread now, and on the preview releases you're providing.

With all due respect to Edy (and there's a lot), brew coffee or grab another Red Bull - stop me from having to use NVIDIA's alpha level package or building my own ! I needed this months ago.

 

<promo mode>A possible shortcut is grabbing a license of Vehicle Physics Pro and use the component VPVehicleJoint for your articulations. It's a wrapper for the standard joint that also produces stable articulations in PhysX 3 (as shown in the videos above), and will seamlessly adopt the PhysX 4 articulations as soon as they're available.</promo mode>

 

This is the PhysX 4.0 thread, not the Unity Physics thread. You may be mixing information here.

 

Oops. Thanks for pointing that out!

 

Will there be gpu rigid bodies?

 

@yant Im testing the new build with articulations but im having some difficulties to understand how to "drive" the articulation. What im trying to do is to make the child articulation body rotate at a certain target angular velocity.
The articulation joint type is set to revolute and twist is set to free. So how to make the child rotate, or better how to apply a torque to it?

 

@yant, that's great news!
As far as I understood, articulations can only be created during editing. Is that a general limitation or is that just because of the early preview stage? Nevertheless, I'm excited to try this out. Thank you for your work on that!

 

Will it support floating point origin?

 

Any change for cloth component ?

 

Really like the little gyazo.com snippets and little examples.
But i reach my limit really fast by trying to understand how to solve real world causal stuff.

Do you have an tip for an practical example for an "car" door.
It s an hinge, who should be activated when door handle was pressed. Then hinged door is free for 60 degrees open/close through push and pull raycast. . door gets to 0 degree pos again it gets locked again.
When door is open and you accelerate car forward its pushed to lock.
When door is open and you accelerate car backwards hinge breaks if it was to fast?


How you would start to solve such an behaviour?

 

Nice to get these finally (we discussed about them earlier on the Discord). I did notice however that these only input Vector3. Would it be possible add ForceMode to these (like with RB forces) so one could use impulses as well?

 

Thanks. I will try to do some iterations.
Nearly every task i need to do has similar pattern and additional needs this functionality networked with multiple users.
However. Some higher level examples like and interior of an car or an living room with real world constraints and networked multi user interaction made by an specialist would be cool.)
Flow and State machine graphs could be cool for physics and would break some barriers for casual user.

 

Im testing the new beta, it seems that with solver type "temporal gauss siedel" spring example doesn't work anymore

 

Another issue is that "Dof Y Drive" and "Dof Z Drive" values are swapped (Z values are used for Y direction and viceversa)

 

you welcome
Btw, is it possible to change articulation body values in run time?

 

Im trying to change DofXDrive targetvelocity via code but, even if the value is updated correctly in the inspector, there is no effect on the articulation body.

 

Any news?

 

Hello yant, when is planned the official release of Phisx 4.x inside Unity?
If its not planned in the near future, is it possible to enable building for the beta version? At least for windows platform.

 

Nothing about shiftOrigin?

 

Bake colliders off main thread, that's awesome. Does that mean we can separate them from gameobject/transforms completely?

One request I have is for non batch versions of the jobified raycasting. Batching tends to complicate and actually lead to more work in a number of use cases. I have a love/hate relationship with job based raycasting.