Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

PhysX 4.1 in Unity - experimental builds

Discussion in 'Physics Previews' started by yant, Feb 25, 2019.

  1. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    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
     
    hippocoder and rizu like this.
  2. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    I see now. A discussion like this would be a little off-topic here, perhaps, but I just wanted to add that you guys might probably draw far-reaching conclusions from a position of information lack. I mean it's not clear how long will it take to make Unity Physics rock solid. Imagine for a second that what you have today is probably a handful of weeks effort. It's not a result of a year or a decade of coding. It already looks competitive to what the builtin physics has to offer from my POV. Dev velocity is great, watching the team I bet it won't take long to up the quality to very high standards, and beyond.
     
    Mikael-H likes this.
  3. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,494
    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.
     
    Last edited: Mar 21, 2019
  4. ceebeee

    ceebeee

    Joined:
    Mar 7, 2017
    Posts:
    377
    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.
     
    hippocoder likes this.
  5. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,331
    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!
     
    Antypodish, Edy and Cynicat like this.
  6. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    I don't really mean to exclude anyone, especially the ones who bring in such deep and well thought out topics but could we please keep this thread dedicated to the feedback about the PhysX 4 update? Like mentioned above, there are other threads where they talk dots physics, and I really have nothing to add on top what's said there. Let me just keep pushing this stateful beast for GameObject worlds ;)
     
    Roni92pl, Cynicat, elcionap and 3 others like this.
  7. Marcos-Elias

    Marcos-Elias

    Joined:
    Nov 1, 2014
    Posts:
    87
    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.
     
    keeponshading likes this.
  8. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,494
    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.
     
    Last edited: Mar 25, 2019
  9. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    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
     
  10. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,494
    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.
     
    Cynicat likes this.
  11. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,061
    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
     
    Last edited: Mar 25, 2019
  12. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,494
    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.
     
    sharkapps likes this.
  13. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    To build up on Edy's point -- the reduced and maximal coordinates joints are coming, I have them being cooked on a branch, I'm not yet happy with the code to have it published today, but hopefully will make it available soon.

    Here is what I can get working. This is a reduced coordinates articulation: https://gyazo.com/1603218826fdd543525f01387e90869b

    The red spheres are 200kg heavy, while the blue ones are 1 kg light. See - no stretch / springiness.

    Another articulation: https://gyazo.com/8cd355cae95053abae0c099089f6fbd3
     
  14. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,494
    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.
     
  15. JVene

    JVene

    Joined:
    May 26, 2018
    Posts:
    2
    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 :D! I needed this months ago.
     
    Marcos-Elias and Edy like this.
  16. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,494
    <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> :D
     
    hippocoder and JVene like this.
  17. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    This is the PhysX 4.0 thread, not the Unity Physics thread. You may be mixing information here.
     
  18. DavidSWu

    DavidSWu

    Joined:
    Jun 20, 2016
    Posts:
    113
    Oops. Thanks for pointing that out!
     
  19. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    84
    Will there be gpu rigid bodies?:)
     
  20. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    Not with this upgrade, unfortunately.
     
  21. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    Hey

    Here is a new experimental build: https://beta.unity3d.com/download/66783f76fcd4/public_download.html. The main changes are:

    - Update to PhysX 4.1; it was released at GDC about a month ago. PhysX updates have never been available that soon before ;)
    - Maximal and reduced coordinates articulations (an early preview for enthusiasts)
    - Mesh baking is now up to 4x faster than before, thanks to a new midphase
    - Bake MeshColliders off the main thread

    More info over here: https://docs.google.com/document/d/1lq4j4C6utxk0nVrS8vgOxPnI6paK3YU4qLu1nCqdEhY/edit?usp=sharing

    This is the last 2018.3-based build, I'm moving development to 2019.1 for a short while and then will make it available in the 2019.3 alphas when they are available, to evaluate how close is this getting to a shippable state.

    Anthony
     
    konsic, JakubSmaga, PhilSA and 6 others like this.
  22. newlife

    newlife

    Joined:
    Jan 20, 2010
    Posts:
    754
    @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?
     
  23. tjmaul

    tjmaul

    Joined:
    Aug 29, 2018
    Posts:
    32
    @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!
     
  24. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    I think this is a bug that you can't have drives working when the the motion is free, in this build the drive will only work in Limited mode. Going to be corrected in the next week's build.

    https://gyazo.com/b773f3c8ae769bf981778a02f7f49594

    Settings for the rotations on the right:

    https://gyazo.com/649a4332083b6a0aee138bba49c29f68
     
  25. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    This is the current limitation that will be relaxed in the future build. However, you won't be able to teleport reduced mode articulations run-time.
     
  26. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    84
    Will it support floating point origin?
     
    Marcos-Elias likes this.
  27. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    Hi,

    Here is a new build of the experimental physx upgrade based on Unity 2019.1. https://beta.unity3d.com/download/a4ae2e318ea7/public_download.html

    New:
    - Unity 2019.1
    - Linux Editor
    - Articulations:
    - Drives are allowed to work in any mode, not just Limited https://gyazo.com/b773f3c8ae769bf981778a02f7f49594
    - Max force is now set to max float, as with ConfigurableJoint
    - Exposed addForce, addTorque
    - Added a simple anchors gizmo https://gyazo.com/3d3b881769a42529d246fd1e98d7d880

    As usual, any thoughts and comments are most welcome. Thanks so much for your help.

    anthony
     
    Last edited: May 13, 2019
    Roni92pl, ClayChi, rizu and 2 others like this.
  28. petersx

    petersx

    Joined:
    Mar 5, 2015
    Posts:
    213
    Any change for cloth component ?
     
  29. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    Cloth is not supported in this build for the reasons explained earlier in the thread. However, the next build is going to be based on Unity 2019.2, and will feature cloth among other changes.
     
  30. keeponshading

    keeponshading

    Joined:
    Sep 6, 2018
    Posts:
    312
    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?
     
    Last edited: May 7, 2019
  31. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,069
    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?
     
  32. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    Yes, one of the follow-up builds will have the same interface as the matching Rigidbody functions.
     
  33. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    keeponshading and hippocoder like this.
  34. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    That should be possible to solve with a HingeJoint and some clever scripting, normally (for the most part). Unfortunately, articulations are unbreakable by design so it won't be possible get all of your requirement fulfilled out of the box.

    This build doesn't allow to combine articulations and joints, but I'm working on that aspect you'll be able to say, lock the door with a FixedJoint for instance. For now, the door lock will have to do with activating a drive to close the door and then toggling the limit to be Locked once it's closed.
     
    keeponshading and hippocoder like this.
  35. keeponshading

    keeponshading

    Joined:
    Sep 6, 2018
    Posts:
    312
    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.
     
  36. newlife

    newlife

    Joined:
    Jan 20, 2010
    Posts:
    754
    Im testing the new beta, it seems that with solver type "temporal gauss siedel" spring example doesn't work anymore
     
    yant likes this.
  37. newlife

    newlife

    Joined:
    Jan 20, 2010
    Posts:
    754
    Another issue is that "Dof Y Drive" and "Dof Z Drive" values are swapped (Z values are used for Y direction and viceversa)
     
    yant likes this.
  38. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    thanks @newlife for bringing this up, I'll be confirming the issue shortly and delivering the fixes as needed in the very next builds
     
  39. newlife

    newlife

    Joined:
    Jan 20, 2010
    Posts:
    754
    you welcome :)
    Btw, is it possible to change articulation body values in run time?
     
  40. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    yeah, sure. that should be possible right now.. let me know if there are bugs.
     
  41. newlife

    newlife

    Joined:
    Jan 20, 2010
    Posts:
    754
    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.
     
    yant likes this.
  42. newlife

    newlife

    Joined:
    Jan 20, 2010
    Posts:
    754
    Any news?
     
  43. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    Yes, another build is coming this week.
     
  44. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    Hi,

    Here is a new build of the experimental physx upgrade based on Unity 2019.2. https://beta.unity3d.com/download/57ff4c5943b0/public_download.html
    Sample project updated for 19.2: https://drive.google.com/open?id=1ZcIzmPg0KUQ-SHseTm1Q-_Oci_-GF3y4

    Notes:
    - Unity 2019.2 beta; Windows Editor, Mac Editor, Linux Editor included
    - Cloth component based on NvCloth and PhysX 4.1
    - Terrain thickness property is removed from now on

    Fixes
    - Fix CharacterController dynamic obstacles climb logics
    - Fix mesh cooking modes
    - Fix limits and drives axis options in ArticulationBody joint
    - Fix changing ArticulationBody joint settings run-time (both from editor and scripts)
    - Some articulation body drive and limits properties were renamed

    Known issues:
    - ArticulationBody mass is not possible to be changed runtime
    - Temporal Gauss-Siedel solver won't be able to solve some articulations correctly

    At this moment in time I think this concludes the features we wanted to have exposed in this iteration. I'll move this to a 2019.3-derived branch and will work on stabilising it and fixing what's not working properly.

    As usual, any thoughts and comments are most welcome. Thanks so much for your help.

    anthony
     
    anton_matosov and rizu like this.
  45. newlife

    newlife

    Joined:
    Jan 20, 2010
    Posts:
    754
    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.
     
  46. Marcos-Elias

    Marcos-Elias

    Joined:
    Nov 1, 2014
    Posts:
    87
    Nothing about shiftOrigin? :(
     
  47. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    2,312
    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.
     
  48. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    We'll release it as soon as it's reasonably ready - that's the most precise I could tell. I hope we can make it to 2019.3, but if it's not good for the purpose by the deadlines - I won't deliver it. Quality matters. From your POV, do you think it's usable for the wide audience in this state? Thanks.
     
  49. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    Unfortunately, not this time around. Sorry about that.
     
    Marcos-Elias likes this.
  50. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    284
    I'm not exactly set to compete with Unity Physics (the C# solution talked about earlier in this thread). That solution is designed towards ease of use, not depending on game objects, and being friends with DOTS overall. It would take a revolution to take our physx integration up to that level, and then, at the end of the day, we end up having two different solutions trying to solve exactly the same thing.

    Instead, I'll concentrate on polishing and stabilising the PhysX integration (ie upgrading, changing APIs where needed, resolving long term user pain, etc). Off the main thread mesh baking is a good example of that. Articulation joint is another example. That said, there won't be any significant dedication to make the PhysX integration gameobject-free.

    Hope that was a helpful perspective.

    Anthony