Search Unity

PhysX 4.1 in Unity - experimental builds

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

  1. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    Hi everyone,

    (this post will be edited to reflect the latest changes)

    We're aiming at updating our PhysX version to 4.x this year. PhysX 4.1 was released last GDC and I'm wondering if there's anyone who wants to try it out in Unity, though it might be fairly raw at the moment.

    Find the latest build here: #95

    Additional notes:

    PhysX 4 retires a few features we used, so this early build won't correctly deal with those. Let me go through the most visible changes below.

    1) Unity 2018.3 brought a new mode called Unified Heightmaps, which was essentially a way to treat local portions of a TerrainCollider as a mesh and process collisions as the ones vs mesh. PhysX 4 completely removed the old legacy heightmaps approach, so will we. That is, no more TerrainData.thickness.

    2) Trigger versus trigger events are no longer supported by PhysX. We need to understand how crucial is it for us to support that, and if yes - make a workaround.

    -----------

    A quick overview of what we've got in this cycle so far:

    1) Temporal Gauss-Siedel solver, find it in the physics settings - the solver type property.

    This new solver type was primarily introduced to increase the accuracy of constraints simulation at the cost of spending more time in computations. It does seem to relax the requirement that the mass ratios have to be approximately the same in order to make the solver converge fast.

    Read more here: http://gameworksdocs.nvidia.com/Phy.../RigidBodyDynamics.html#temporal-gauss-seidel

    2) Automatic Box Pruning, find it in the physics settings - the broadphase type property.

    Read more internals here: http://gameworksdocs.nvidia.com/Phy...igidBodyCollision.html#broad-phase-algorithms

    Additionally, here are Pierre Terdiman's notes on the algorithm itself: http://www.codercorner.com/blog/?page_id=1632

    Basically, the intention is to solve the issues with the Sweep-and-Prune code that is used to discard potentially overlapping pairs. Basically, there are two issues present: it can't always discard faraway pairs when some of their projections overlap, and it's really good only when most of the bodies are sleeping in the scene. A challenging configuration for SAP is when you have a relatively flat large landscape where a lot of objects move. Think TerraTech, Rust, a typical RTS game as well.

    PhysX 3.3 made an approach to this problem by introducing the Multi-Box pruning algorithm which was essentially a grid of Sweep-and-Prune instances, restricted to its grid cell each. The hope was that if two moving bodies belong to different cells, they couldn't influence each other, and thus could be discarded quick. However, this came with the cost of having to maintain the world bounds as well as the grid itself.

    With PhysX 4 we have an evolution of Multi-box pruning stuff, that does the magic of maintaining the world bounds behind the scenes, in a hidden from the user way. How do you like it?

    3) Maximal and reduced coordinates ArticulationBody - high precision joints simulation with no stretch at all. Perfect for robotics, machine learning applications, blending physics and animation

    4) Mesh baking is now up to 4x faster than before, thanks to a new midphase

    5) Bake MeshColliders off the main thread, or on demand, independent from MeshCollider instantiation

    Please do let me know what you think.

    Anthony
     
    Last edited: May 31, 2019
  2. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    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).
     
  3. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    I'll see about the options here when we reach 19.1/19.2. For now it's going to be editor-only, 2018.3
     
    AlanMattano and rizu like this.
  4. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
  5. JakubSmaga

    JakubSmaga

    Joined:
    Aug 5, 2015
    Posts:
    416
    What about a Windows build?

    Greetings,
    Jakub
     
    TokyoWarfareProject likes this.
  6. tjmaul

    tjmaul

    Joined:
    Aug 29, 2018
    Posts:
    50
    Does that mean we get articulations, too? Is the API for that exposed?
     
  7. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    Like a mentioned above, I doesn't yet contain any new features. They are coming in the future updates - I intend to update the thread every other week or so, taking your feedback into account.
     
    ClayChi likes this.
  8. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    Coming soon.
     
    JakubSmaga likes this.
  9. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    285
    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!
     
  10. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,587
    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 :)
     
    Nothke, MostHated and strich like this.
  11. TokyoWarfareProject

    TokyoWarfareProject

    Joined:
    Jun 20, 2018
    Posts:
    508
  12. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    spakment and Mikael-H like this.
  13. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,939
    (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.
     
  14. AdamMGardner

    AdamMGardner

    Joined:
    Sep 26, 2017
    Posts:
    2
    Any plans to support GPU rigidbodies?
     
  15. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    Just in case I misinformed -- the idea was that this particular build doesn't feature Cloth, but Cloth itself is not going away, it's going to be supported in experimental builds just later. It's not there right now because PxCloth is gone, but NvCloth is almost the same thing just called differently and cleaned up.
     
  16. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,939
    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?
     
    yant likes this.
  17. MostHated

    MostHated

    Joined:
    Nov 29, 2015
    Posts:
    882
    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?
     
  18. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,211
    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
     
    Last edited: Feb 28, 2019
    RogDolos, MostHated and hippocoder like this.
  19. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,939
    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.
     
  20. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    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).
     
  21. MostHated

    MostHated

    Joined:
    Nov 29, 2015
    Posts:
    882
    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?
     
    hippocoder likes this.
  22. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    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?
     
  23. MostHated

    MostHated

    Joined:
    Nov 29, 2015
    Posts:
    882
    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.
     
  24. ceebeee

    ceebeee

    Joined:
    Mar 7, 2017
    Posts:
    393
    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.
     
  25. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,211
    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
     
  26. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    256
    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. =<
     
    Sluggy and yant like this.
  27. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    My colleague's on it, we have it out in 2019.2 alphas right now. I reviewed the code and it looks a bit more suited for jobification - like there's no longer the need to add all cloth instances to a special scene and so on. We could potentially run a cloth per job. As far as I get, there are no perf comparisons available yet, but I hope that at least editor performance will get better -- we have some new non-alloc API for accessing Cloth vertices, constraints and so on. Previously it was using the allocating ones and leaked like crazy (PR is on the way to trunk).
     
    hippocoder and Cynicat like this.
  28. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    Trigger vs trigger. This is when imagine you have two rigidbodies, both are triggers for different reasons -- and with this change you won't get OnTriggerXXX events when they overlap each other. Nvidia has pointed out to me some workarounds (though not exactly free perf-wise), and I'm going to listen to the community and decide whether to implement those or not. Honestly, I don't believe the overall conclusion would be to deprecate that feature. Every time I work on a personal project, there is always a great simplification coming from the fact trigger vs trigger work. But let's see. I can probably make it a switch in the project settings too.
     
  29. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,587
    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! :p
     
    Backes, Maeslezo, JakubSmaga and 3 others like this.
  30. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,939
    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 :D
     
    Cynicat likes this.
  31. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    FWIW - there is a new build available that works on Windows as well as on Mac, and exposes two new features. Read more above. Thanks.
     
  32. artyom-zuev

    artyom-zuev

    Joined:
    Feb 15, 2018
    Posts:
    5
    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.
     
    Sluggy and thibouf like this.
  33. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    Thanks for sharing your perspective Artyom.
     
  34. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,939
    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...
     
  35. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,211
    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?
     
    Last edited: Mar 14, 2019
  36. knup_

    knup_

    Joined:
    Feb 23, 2017
    Posts:
    18
    Hoping to see better stability for joints in Unity with the 4.0 release. Is that accurate?
     
  37. newlife

    newlife

    Joined:
    Jan 20, 2010
    Posts:
    811
    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":
    contactPoints.gif
    Red lines are the contact points, white one is the centroid.
    This doesn't happen with the old solver.
     
  38. petersrin

    petersrin

    Joined:
    Mar 20, 2018
    Posts:
    3
    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.
     
  39. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,939
    Check default contact offset if applicable.
     
  40. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    256
    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!
     
    Mikael-H and knup_ like this.
  41. newlife

    newlife

    Joined:
    Jan 20, 2010
    Posts:
    811
    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.
     
  42. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    Hey PhilSA, may I have your Unity project for that please? Thanks.
     
  43. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    I think I have a good guess at what's caused that. This build is on vanilla PhysX without our modifications, and one of those was a change that forced the dynamic pruners for both static colliders and the dynamic bodies. It's there since Unity 5.0 -- I don't remember why couldn't we place that code in our integration and had to keep it as a custom patch. I'm moving the patch into the integration early next week to minimise the diff with the vanilla PhysX (and thus ease the upgrade pain).
     
  44. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,211
    Sure thing, sending it via PM since it's part of my asset store product
     
  45. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,587
    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
     
    Cynicat likes this.
  46. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    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.
     
    Edy likes this.
  47. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    Edy - the builtin integration of PhysX isn't going to disappear any time soon, we will maintain, support and improve it for a while. That said, we still target at shipping PhysX 4.x upgrades once they're ready.
     
    Edy likes this.
  48. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    256
    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... =<
     
  49. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    I'm not sure I follow the logic of your argument here. I was trying to say that for those who didn't yet want to move on to the dots stuff there was nothing changed by the GDC announcement, because as I tried to explain there are still the same people behind the GO-based PhysX integration trying to maintain it and improve. This code is not getting stripped out, moved to an external package, abandoned or whatever crazy thingie I was able to read through social channels recently. PhysX 4 is coming, articulations are coming too in one of the next custom builds in this thread. TGS is already here. Once Nvidia publishes a new PhysX 4.x/5.x/x.y version, it's coming in an update too.

    Now for those who did care about DOTS, the GDC announcement brought an amazing disclosure that there is a new, native to DOTS physics engine being developed right as we speak. This one is coming as a package with full source code in C#, which was never possible before. There is a strong team behind it, they're obsessed with performance and super focus on the result. There are pull requests merged daily, the development velocity is unbelievable.

    Additionally, there's a native Havok integration coming that would take the same data, perform better at scale thanks to caching. It's not yet available to the best of my knowledge, but is coming some time in summer on yet undisclosed terms.

    That said, why would some be unhappy.
     
    Yozaro, Edy, elcionap and 1 other person like this.
  50. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    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).
     
    Cynicat likes this.