PhysX 4.1 in Unity - experimental builds

(PhysX dev here) We removed the trigger-trigger overlaps to make the code simpler and easier to maintain, not for performance reasons. As far as I know this change didn't make the code any faster (yet). However it does open the door to more refactoring which will hopefully make the "simulation controller" layer a lot easier to work with in the future. It is not for performance, the complexity of this layer is a constant source of subtle bugs and frustration. If you ask me, it's not just trigger-trigger interactions that must go: the whole concept of "trigger shape" should also vanish (I'm not saying we will do that anytime soon though).

We did ask our users (including Unity) whether this specific change would be fine, years ago now. We first deprecate a feature for the lifetime of one PhysX version before actually removing it. In 3.4 the corresponding flag was explicitly called eDEPRECATED_TRIGGER_TRIGGER_REPORTS. With all due respect, it is a bit late to complain about it now....

In any case I also posted a snippet in this thread showing how to emulate triggers with regular shapes, which not only gives back trigger-trigger interactions, but it also makes triggers work with CCD (which is otherwise a rather severe limitations of built-in triggers).

So I think the clear solution to this problem is not to switch everything to overlap checks, but simply have Unity internally switch to the approach used in the new snippet (in their PhysX wrapper layer). It should be transparent for Unity users, as far as I can tell.

 

There are lots of problem in android build. I can't release new update because of that. I have waited for skinned mesh batch in srp to be released and fixed. Now physics not working properly. This issue needs to be fixed.

Code (JavaScript):

1. [Physics.PhysX] BV4 midphase only supported on Intel platforms.

 

Thank you for the details, they really are appreciated - and I don't think that anyone is against having the internals of how it works change so much as having nothing in place to replace it. Unity's docs have always been peppered with comments about avoiding the obvious alternatives to trigger-on-trigger collision, which is certainly not PhysX's fault.

 

I found the problem. This is related to prebake collision meshes.

 

Hey @yant,

I'm testing unity 2019.3.0b3 with temporal Gauss Siedel, and in my project, some physics is broken with temporal but not with projected, so I think I have found a bug, or a regression :

-Make a kinematic rigidbody, interpolated, move and rotate with script (rigidbody.moveposition and .moverotation, so it keeps the interpolation)
-Connect a rigidbody chain (non kinematic and interpolated).

With temporal solver it will break, no problem with the projected solver.


I made a repro project you can download here

Just open the "Debug_Kinematic_Joint" scene in scene folder. At runtime, try to move and rotate the mover, containing a script that will do what I explained above. Try to switch the solver to see the difference.


Hope it will help you in the bêta debug process

Have nice day,
Jonathan

 

Second this, are PhysX 4 articulated joints available in Unity already? The information is hard to find about this.

 

Have you reached a decision on when (if?) you will have trigger to trigger stuff working again in what beta version? I think I've read every reply since I posted but didn't notice a hard decision.

 

Thanks!

 

Thanks! Will focus on other things then, such as Jobs system, Burst and SIMD stuff. Came back to Unity after 1 year being idle, and there is lots of new stuff .

 

Thanks you! have had this error on my android build for awhile and ive been scratching my head for a while ^^ i do have prebaked collision meshes in scene! thank you thank you, how did you figure that out in your case?

 

Any idea when this may be ready? Thanks

 

We're using Unity for Hardware in the Loop (HIL) testing automation for Offshore & factories. Think cranes, hydraulics, heavy machinery etc.

We're really looking forward to reduced articulations and keeping a daily eye on this thread. A tentative release date is very welcome

 

Clear communication, constant updates. Just wanted to say thank you very much @yant and Goodluck!

 

Link is broken. Excellent work though, any news on when TGS scientific documentation will be available?

 

Functional link here.

 

Tried the 2019.2.0b2 build, articulations act very very and very stable.

I run simulation at 500 FPS, though!

Two problems so far though:
- Joints not moving to closest point (only one rotation path).
- Once articulation sleeps, it's hard to wake it up. I hacked this with joint.AddForce(Vector3.zero).

 

Nevermind, Joints are moving to closest point, it's just that I had to set Target beyond [-PI, +PI] range!

 

Ok, I got into the weird stuff with articulations, the joints stop working based on some weird colliders as children being present or not.

 

Playing with articulation further, it seems to break if the Anchor Rotation is changing down the chain, it seems.

 

Hey, big thanks for info!

To reply:
- I never used the maximal coordinates articulations, so I suppose you are right.

- I tested AddForce/AddTorque, but it doesn't work (no effect), I just used AddForce to block ArticulationBodies sleep (as mentioned before).

- Now that you mentioned ArticulationBody related to RigidBody - does that mean it would be possible to simulate Graph Jointed (non-tree) structures, with base structure being tree (articulated body) and adding some classical joints?

 

Ok awesome, can't wait to test it out!

 

Hi, hoping for build this week, it's gonna save my ass (demoing Unity to some ppl)

 

Can you please elaborate on "trigger shape should also vanish"? I am curious what is the problem with triggers as concept.

 

So is on the mid or long-term plan to change how the Triggers works? Seems like some performance benefits could come from those changes made by PhysX - or least make things less error-prone when integrating new features.

To better understand my doubts:

1. Should Unity users be prepared for a future where Trigger-Trigger interactions vanish and start thinking on the "right way" instead?
2. OR will Unity work under the hood to maintain the Trigger-Trigger interactions on the foreseen long-term?

I am asking that because I see the main reason of the Trigger-Trigger complains being that we didn't saw that breaking change coming - specially near a LTS release - but with proper communication and planing I can see that being acceptable (like for the 2021 release cycle or even 2020 release cycle).

 

Several users including myself chimed in stating the importance of maintaining backward compatibility of trigger to trigger interaction, and the Unity dev said that he would be looking at it the following week and it should be fairly simple to put back in. That was several weeks ago.

I've been watching this thread carefully and have seen no update on this from Unity though.

 

Actually @yant has been working hard on it, take a look here: https://forum.unity.com/threads/ontriggerenter-not-fired.719165/page-2#post-5091077

 

Awesome! Do we have any idea if it will make the 2019.3 release?

 

In the linked post he mentions backport to 2019.3, so I think so.

 

I mean what should replace trigger in PhysX. I don't quite understand how the physics system should determine should be there collisions on contact or not without the trigger concept.

 

Hey, how are articulations looking ?

 

Ok big thanks for feedback! I will work on other stuff meanwhile; trying out articulations will be the juicy part.

 

btw I've just noticed on 2020.1a9 if you have a monobehaviour with
public void OnTriggerEnter(Collider other) and working correctly (meaning, the trigger should be called). It's all nice.
The problem is that you can do a script.enabled=false; (disabling that script) and OnTriggerEnter will still be called, ignoring whether it's enabled or not.

 

It was always like that, see the "Note" part in the API: https://docs.unity3d.com/ScriptReference/Collider.OnTriggerEnter.html

 

Thanks for update.

Also, would articulations be good for 6 DOF+ jointed structures?

 

Yes, I realized that, it's probably quite hard to do (if even possible). I am fine with that.

But, last time I tried Articulations (the last experimental Unity build that had it), I had weird problems with Articulations, where if I added more and more joints - they broke down (stopped to move).