PhysX 4.1 in Unity - experimental builds

Ok, this seems promising! Very nice, indeed ) Thanks man, made my day!

 

Is this trick with rigidbody box collider encompassing 4 spheres or did you do it some other way?

 

It's articulated body with 7 or 8 fixed joints. Red spheres have much heavier mass.

 

Terrible unity noob here so apols before I start.

My first attempts have been playing with tracked vehicles in unity and my first impressions is that the current wheel colliders on multi axle just seems to multiply some bad approximated physics where friction and many other aspects in testing has left me completely bemused.

Some of the solutions seem terribly complex, that end performance really worries me.
I have been searching and as a noob I am thinking PhysX vehicles would be a much better solution, especially with having PxVehicleDriveTank and tracks can be a much smaller array of jointed 'cloth' purely for render.

Is there an C# API to the PhysX Libs so you can apply as from the SDK (
PxVehicleDriveTank)
"This extra constraint on wheel speed mimics the effect of the caterpillar tracks but avoids the expense of simulating the jointed track structure." as yeah wow currently its hugely expensive.

 

I use a Joint based suspension for the tanks and no wheel collider. Last physics upgrade was epic as it allowed for way bigger timesteps. since unity 5 it needed much lower timesteps affecting greatly the performance. I was checking this new update with the new solver and the higher accuracy comes at the cost of more computation. So this time the solver may not mean any improvements unless for same accuracy it allows hibher timestep due to its higher by defalt accuracy, something I doubt, also bigger timesteps my ressults in flawy behaviours in other areas endind up with odd penetrations.

 

I just wondered if it was me being a noob and there is basically a C# wrapper for the Nvidia PhysX of any version since 3.4.
Apols for talking tanks, but currently many of the physics methods are extremely expensive, so just to continue and also just ask Tokyo a little more.

Thanks for your reply.
Did you do the thing where you created all individual ridgid body tracks and jointed them very much how you build a real overall track by linking track segments?
As that can be 20-30 segments per track and 40-60 per tank, which I have seen others use, but the expense?
I was sort of wondering to do similar with what is in essence a series of inverted conveyors jointed at each wheel ground point.

But still feel if Nvidia have already done this, even though not tried, but if you read the below it does hint that it could be a perfect fit.
I know PxVehicle was in PhysX 3.4 but I don't see anywhere any Unity reference to acessing or creating these classes.
Unity says it has PhysX so where is it? Or is it just a subset on a few offered objects?
This is an honest noob question as slightly confused why its not much more than providing straight wrapper for C#?

Even on my wheeled vehicles I would like to access PxVehicle but as a Unity noob I am confused with the current offering of the wheel collider as it just seems this really badly chosen subset of PhysX that is has missing API so maybe you could fill in the rest?

PhysX already has some optimised classes for PxVehicleDrive4W, PxVehicleDriveNW, PxVehicleDriveTank and PxVehicleNoDrive
Maybe its just noob perception but PhysX initially looks great, whilst the implementation for at least vehicles in Unity maybe not so?
https://docs.nvidia.com/gameworks/c...hysx/guide/Manual/Vehicles.html#vehicle-types

 

SO you're after a real track simulation, in my case the tracks are just a gimmic, the wheels are actually driving the tank. Yet, I based my game on this asset.
https://assetstore.unity.com/detail/templates/systems/physics-tank-maker-50485
It used to have the track simulation you mention, yet, in my view it was too expensive.

Yet, I'm still looking for a cheaper solution as on Xbox the CPU is cloged by physics. I really wish the Physx was runing on multiple cores :\

 

No like you also had a look at physics tank maker and yeah purchased and great but far too expensive.
I think something much simpler is needed and it is in PhysX PxVehicleDriveTank but hwo do you access the API via C#?

The wheel colliders make an extremely poor simulation for tracked vehicles, but physx does have at least from 3.3.4
https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/3.3.4/Manual/Vehicles.html

Also its lighter and better than the wheel collider in unity but wondering how you access?
Again PhysX can be multithread but prob unity implementation not so.
https://github.com/NVIDIAGameWorks/...ltiThreading/SnippetVehicleMultiThreading.cpp

 

Yes earlier in this or similar thread someone of unity said that the physx itself runs multithreaded but the unity implementation does not. I was puzzled to heard that. I wish they did allow for multithreading, specially now that they're implementing havok and their own multithreaded physics would make much more sense to have multithreaded physx as the transition would be possible for current projects.

 

Any chance we could get PxVehicle rather than 'PxWheel'?

 

Oh men that is great to know. and surprising tbh. Ye. physics simulat() is something that gets super busy in my case. at least on Xbox I don´t see much core spreading and physics simulate is busy as hell.

 

And articulations are much more stable.

Btw - unrealted though - but since you mention robotics, ROS integration with Unity would make Unity a king in robotics.

 

I am slightly bemused to why you would break up the optimised Physx routines in batched raycasts of individual wheels.
Its in the introduction of why Vehicles was introduced.

Vehicles
Introduction
PhysX support for vehicles has been significantly reworked in 3.x. In place of the NxWheelShape class of 2.8.x, a more optimal integration of the core PhysX SDK and vehicle simulation code has been developed. More specifically, the vehicles component now sits outside the core SDK in a manner similar to PhysXExtensions. This change allows vehicles to be updated in a single pass as well as promoting a more intuitive approach to modeling vehicle data. Vehicles support has been extended from the suspension/wheel/tire modeling of 2.8.x to a more complete model that couples modular vehicle components including engine, clutch, gears, autobox, differential, wheels, tires, suspensions, and chassis.​

It would seem a contradiction because you do expose PxVehicleNoDrive from that module as it would make sense if nothing was exposed from that module, but you do for reasons with sense.
You are telling me all this about C# gravy and having to be modular with source in C# straight after declaring its not true with PxVehicleNoDrive which is exposed?

 

Hi! I'm not sure if this is the right place to post this, but I am using your experimental 2019.2 build and the temporal solver gives me much worse results for my specific use case. My issue seems related to this
https://github.com/NVIDIAGameWorks/PhysX/issues/21

I can't use wheel colliders, I have to actually simulate wheels since this is a freeform building game.

The blocks are connected together by fixed joints, which may be causing problems. I can't use a single articulated body for the whole bot, it restricts building flexibility. (afaik there must be no loop in how an articulated body is laid out, so for example making a scizor lift would not be possible unless I used several articulated bodies attached with regular joints)

I am using a maxdepenetration velocity of 5 and I tried increasing the contact offset. These tweaks didnt seem to help. Do you have any ideas on what is happening? The wheels have a cylindrical collision mesh, while the planet's collider is spherical.

 

Temporal Solver is also much more unstable for me; Cube colliders / rigidbodies were flying off conveyor belt where as old solver was 100% stable.

But you can try increasing solver interation count, might stabilize things .

 

It does help, but the result is still lackluster, in my opinion. The projected solver works quite welI so far, at least. haven't tried enough scenarios yet to judge how well unity physx works overall for the game I work on. (Latest version is on a 3rd party bullet integration, But this older version worked with physx 2.8 so I wanted to compare the two)

Maybe the temporal solver is meant more as an alternative option, with its pros and cons depending on situation, than as a successor always offering a superior simulation quality to the projected solver.

 

How is Bullet working for you? How you implemented it?

 

I didn't do it, the former dev team (abandoned commercial project) made a private in-house plugin in 2012. I'm not a c++ guy, (I only recompiled the plugin for 64 bits) so I can't help you that much with the specific implementation details. The team made a dll they called bulletservice (from 2 cpp files) that includes the main bullet static libs (BulletCollision, BulletDynamics, etc...) and on the c# side the team wrote bullet.cs that gives access to the functions the team wrote in bulletservice.

I haven't played the physx version that much (only started messing with it recently) so I'm not familiar enough with it to confidently compare it to the main version. I'll release the physx version to get other players to voice their opinion on the matter.

If you want to try the physics of the bullet version (0.1.6) here's the link: discord.gg/HWzDMZc
The game has a steep learning curve, so I'd suggest to ask me or someone else (tell them your goal) for instructions.

I'm generally happy with the simulation quality, but performance leaves to be desired. A big reason for this is that each robot is made out of 10s of bricks, and every single one is an independant rigidbody attached to its neighbors by fixed constraints. Optimizing this would probably be easier for me in the physx version. (not a c++ guy)


With that said, you'd probably be more interested to try this free asset, since it is publically available:
https://assetstore.unity.com/packages/tools/physics/bullet-physics-for-unity-62991

 

Thanks for info . Yes, I know about this free asset - might be worth trying out.

I am still waiting for this/that Physx 4.1 built with articulations, I think it will do wonders - but if not - Bullet might be the answer.

 

@yant Hey, how is PR looking right now ?

 

Hey, thank you! Good to know it's one week to prepare for this juicy sauce of an update . Hope you guys resolve those painful bugs.

 

@Kobix Btw, if dots/ecs sounds like something you'd like to try, Unity is making their own open source physics engine completely in editable c#, as discussed here https://forum.unity.com/threads/unity-physics-discussion.646486/

it's meant to be deterministic for networking reasons, But does some sacrifices for determinism. It has some limitations, but joints at least compare favorably to unity's implementation of physx https://forum.unity.com/threads/unity-physics-discussion.646486/page-5#post-4404130

Of course,switching to ecs might not be convenient for you.

 

Hi, I am aware of Unity physics, and that it has better joints than usual Physx joints, but I don't believe it is comparable to Articulations of PhysX (still wobbly - not staying in place), also tooling is quite bad for Unity physics too.

 

Btw 2020.1.0a15 has been published, and there are articulations inside.

 

It is improvement indeed!

Fixed previous problems.

Only problem so far are instabilities at +/-360° degrees, where articulations fall into explode/reset cycle. It's related to how stiffness, or more precise stiffness to damping ratio. I believe from my eye it's numerical error (lack of precision of float point), so it should be easy to fix

Also working only with revolute joints at the moment. Will test prismatic joints too.

Still, testing it as we speak . Wish anything to be tested?

 

Update:

Found 2 bugs and possible workaround (which is not so good but ok):

Wishing for adjacent links colliders to have no collision. This way I found 2 bugs:

Bug #1: Physics.IgnoreCollider has no effect (which means articulations have to be rebuild/refreshed, I guessed)

I tried that with disabling/enabling articulation. Buuuut:

Bug #2: Unity crashes when I enable/disable articulations.
I even tried to build a tree out of articulation bodies, and to disable leaf articulations first, parent last; then inverse for enabling (root first, children last). Still Unity crashed.

Solution: Set 2 altering layers (modulus of tree depth to alter layers) on articulation bodies before Play. It kind of works, but it's not ideal solution (now I see I need more than 2 layers, lol).

Will post more when I play with it more, hope the feedback is appreciated .

 

Hi Yant, are there any examples you can point us to to make it easier to get started with articulations?

I found the scripting API on ArticulationBody and the ArticulationBody component but examples would be more helpful.

 

Thanks @yant, I'm happy to see articulations out there now!

+1 to an extra thread. As for comments:

1. Revolute joint with Twist Locked crashes on pressing play.

2. I find the actuation of the revolute joint somewhat counter intuitive. I saw the formula used to calculate the torque on the joint ( velocityDifference * damping + positionDifference * stiffness) and it makes sense, but from a feedback control perspective I guess some more control would be nice. Is it implemented as opposite torques added on the two bodies on the joint? Then I also could implement feedback control algorithms myself.

3. There is no AddForceAtPosition(). I can implement easily myself, but I guess it should be part of the api to reflect what is possible with Rigidbody.

 

From Nvidia docs, it says that articulations are driven by PD controllers.

 

Just go through Nvidia Articulations API:
https://gameworksdocs.nvidia.com/PhysX/4.1/documentation/physxguide/Manual/Articulations.html

Bear in mind, not all is implemented.

 

Another bug:

Articulations like to sleep randomly, or parts or articulations. They are hard to wake up even with physical interaction.

Reproduction: make ArticulationBody fall to ground, then move the grounds transform up. ArticulationBody will not react.

Easy workaround: keep applying force to them every FixedUpdate.

 

Prismatic joint bug:

Multiple prismatic joints (T pose) in series acts very buggy. I am simulating a gripper, so you can imagine what kind of setup it is (3 prismatic joints).

Update 2:

I had disabled GameObjects with Articulations and Colliders (it was actually "backup gameobject", so the disabled colliders and articulations were in exactly same place).

I removed them. The problem is gone. I believe now it is not prismatic joint bug, but general bug with articulations.

 

Another weird bug:

Friction Type -> Set it to something else than "Patch Friction Type" and Articulations collapse.

Center of mass bug:

Articulation without Collider makes system really unstable.
Easy fix is: add disabled collider. (small sphere collider)

 

No problem. I love Unity as a software and wish to see it as a general simulation software too

 

Weird scene editor bug: When I select Rigidbody in scene editor, it kind of awakes Rigidbody continiously. In some steep areas this means Rigidbody can start to slip.

Rigidbodies were also touching Articulations.

 

I case anybody needs the point velocity of an articulation body (like Rigidbody.GetPointVelocity), you can use the following code. Attach the Component to an object that holds the transform for the point of interest and is parented to the ArticulationBody of interest.

Code (CSharp):

1. public class Test : MonoBehaviour
2. {
3.     public ArticulationBody ab;
4.  
5.     void Start()
6.     {
7.         ab = GetComponentInParent<ArticulationBody>();
8.     }
9.  
10.     void Update()
11.     {
12.         var v = ab.velocity;
13.         var w = ab.angularVelocity;
14.         var lever = transform.position - ab.transform.TransformPoint(ab.anchorPosition);
15.  
16.         Vector3 pointVelocity = v + Vector3.Cross(w, lever);
17.  
18.         Debug.DrawRay(transform.position, pointVelocity);          
19.     }
20.  
21. }
22.  

 

So this just happened:

https://news.developer.nvidia.com/announcing-nvidia-physx-sdk-5-0/

 

Nice, cool that soft-body physics is getting considered .