Search Unity

Experimental build with the PhysX 3.4.1 upgrade

Discussion in 'Physics Previews' started by yant, May 7, 2018.

  1. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    Regarding the slowdown - this has been tracked down to an unfortunate conflux of unrelated efforts. It's already fixed in 2018.3b6 thanks to a great report by @KillHour
     
    matteumayo likes this.
  2. tjmaul

    tjmaul

    Joined:
    Aug 29, 2018
    Posts:
    50
    @yant sorry for being so anxious about this, but I looked at the roadmap https://unity3d.com/unity/roadmap and articulations are not in it for 2019.1. Should I be just a bit more patient or has I been dropped? Articulations would open a whole world of possibilities!
     
  3. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    Articulations won't make it in 19.1 I'm afraid. We have an experimental branch that's far from complete even for sharing on forums. That said -- it's not dropped, just not ready for being shipped at the moment. Thanks for your interest in physics. anthony
     
  4. tjmaul

    tjmaul

    Joined:
    Aug 29, 2018
    Posts:
    50
    I'm happy to test and give feedback to anything related to that topic
     
  5. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    @yant Has the contact modifications been given more thought? :D
     
  6. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
  7. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,938
    I'd love to see a quick bump as well ;)
     
  8. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    We need to see it officially out and give it a try internally. For now, it's not 100% clear how different it is from PhysX 3.4. We have a ton of custom patches to apply on top of vanilla snapshot. Anthony
     
    Edy, rizu and hippocoder like this.
  9. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    I'm mainly interested on the more stable solvers but obviously would need to see the changelog/API docs for the real changes (and obviously test it in practice). I think Nvidia had a talk about these improved solvers on some recent GDC or something. Basically it makes constraint solving more stable especially when the mass ratio between the objects is big. Traditionally this has always made the lower mass counterpart freak out so people have tried to balance it by using more similar masses in places where it wouldn't otherwise make any sense.

    Anyway, according to the announcement, 4.0 should be out on Dec 20 so just under christmas, we'll be wiser after that. :)

    Edit: found the talk:
    https://www.gdcvault.com/browse/gdc-18/play/1024812

    this unofficial blog post shows some of the slides covered in this talk:
    http://physxinfo.com/news/12876/gdc-2018-new-physx-sdk-will-focus-on-simulation-accuracy/
     
    Last edited: Dec 3, 2018
  10. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,938
    Yeah and really, we're having ourselves a juicy ECS/Burst/Job version one day... depending on real world cache efficiency near Unity staff.
     
    Nothke likes this.
  11. TokyoWarfareProject

    TokyoWarfareProject

    Joined:
    Jun 20, 2018
    Posts:
    508
    daammmm doesnt it make a bit watered the "new" physix in 2018.3?

    +1 for the ECS/Burst/Job version

    I remember someone said physx itself is perfeclty multithread capable yet the unity implementation is not, wonder why
     
  12. JohnSmith1915

    JohnSmith1915

    Joined:
    Apr 21, 2016
    Posts:
    143
    Hi, Physx 3.4 will be implemented in Unity 2018.2 or only in 2018.3?, how can i check that Physx version is using my Unity installation? thanks.
     
  13. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    Unity 2018.2 uses PhysX 3.3, they upgraded to 3.4.2 on 2018.3.
     
  14. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    285
    Damn. Those stable simulation extensions look fantastic.

    No doubt it is a non-trivial thing for you guys to upgrade, and a huge task to get it through QA et. all. That said, I would love to see an experimental on this.

    Another question for you @yant - There are quite a few features in PhysX that are left unimplemented in Unity for reasonable reasons. However are those features compiled out entirely? Can we write our own interop to call into the built dlls? It would be amazing if we could write our own plugins to fill out the PhysX featureset.
     
    Roni92pl likes this.
  15. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    How most game engines do this is that there's a middle layer in the engine itself that implements the PhysX stuff and makes sure the API that gets exposed to users has engines functionality and type conversions taken care of. With Unity, you can then imagine they just expose the middle layers other side to the managed side and it'll eventually get exposed to users.

    In other words, there's no PhysX at the native<->managed border at all in Unity code or if there is, it would be the first. There are countless reasons why this isn't really feasible thing to implement and in the end, all this would probably be way more work than to actually just implement the missing PhysX functionality in stock Unity.
     
  16. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    Currently main missing functionality that exists in PhysX 3.4 and what people have requested:
    - more vehicle stuff (but having had full access to this and it's sources for years, I'd urge people to not rely on physx vehicles at all, there's no magic here that can solve your vehicle issues)
    - articulations (apparently this is coming at some point, maybe for 2019.2?)
    - immediate mode physics (apparently coming in some form later on)
    - physx contact modifications (can we have this? pretty please :D)
    - convex sweeps and overlap checks (also pretty please..)
     
  17. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    All good ideas here. Getting the base upgraded is one part of the job. Another would be to expose the new articulations in a useful way. The older articulations were sort of an alien in the whole ecosystem to be honest. Personally, I wouldn't worry much about the fact that physx 4.0 might come even before unity 2018.3 is out. What you get in 2018.3 is the most tested release, and the latest in the 3.4 lineup. One could argue 4.0 would be fairly raw in the beginning.
     
    hippocoder likes this.
  18. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    285
    Yeah no doubt. Would be cool to see articulations in experimental state in one of the alphas/betas soon. :)
    Even if it is just a dump of the properties like the configurable joint component.

    I don't know if it is possible not knowing exactly how you compile in PhysX, but it could be really valuable to everyone if it were possible to access features and properties the PhysX engine provides by writing our own interop based on the published cpp API (Or you blindly generate it in an experimental namespace). It would mean we can write plugins for things and you won't have to support them until you decide it is a useful thing to make a native part of your implementation. Might be more work than it is worth, specially since your team seems to have been able to really ramp up implementation speed in the past year.
     
    goncalo-vasconcelos likes this.
  19. Zergling103

    Zergling103

    Joined:
    Aug 16, 2011
    Posts:
    284
    Yeah, the joints in PhysX 3 are very rough and borderline unusable by comparison to the version of PhysX used in Unity 4. You'd frequently have to rely on unrealistic hacks like projection to keep ragdolls from exploding, and at times this "cure" was worse than the disease. Hopefully PhysX 4.0 will perform better.
     
  20. XRA

    XRA

    Joined:
    Aug 26, 2010
    Posts:
    189
    @yant is there any solution for eliminating the per-frame GC allocations that the CharacterController creates when using Move()
    Code (CSharp):
    1. private extern CollisionFlags Move_Injected(ref Vector3 motion);
    If I understand correctly, the character controller is a wrapper of PhysX's Character kinematic & this per frame allocation when moving has been around since I started using Unity 3.x
    Just wondering if it is something that can be improved within Unity's implementation.

    Other features of the PhysX character controller would be nice to expose for creators to take advantages of, such as the arbitrary up vector:
    https://docs.nvidia.com/gameworks/c...de/Manual/CharacterControllers.html#up-vector

    https://feedback.unity3d.com/sugges...-in-physx-feature-pxcontroller-setupdirection
     
  21. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    There will be a C#-based CharacterController solution rolled out soon. It follows pretty much the same logic as the old-school PhysX one, but the bonus here is C# -- that is being able to modify all the parts as you like.
     
    Edy and rizu like this.
  22. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    I'm really happy Unity went this route, I actually had one page long rant about the previous Unity char controllers but I never posted it to new chars feedback post as I wanted to polish it so it'll not come out too negative (and my main point would have been to ask for full source code c# controller for the new thing).

    My current project doesn't require characters but in past char controllers have been number one thing that made even Unity samples look bad or glitchy. In the Unity 4 (etc) old char controller, you could only work around the issues due to core problems being at the c++ side and then the following rigidbody based setup.. well, I'm not even going to go there.

    Anyway I understand from this comment that the new upcoming samples will have c# char controller that works on physics queries and calculates it's own movement in code (like majority of people do in this industry when they need robust controller). I wonder, is this new controller partially same that was used in recent FPS Sample for characters or was that completely different?
     
  23. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    From what I saw - it's a different package, but it's a sort of a turn-key solution too, pretty much like the first person controller you mentioned. @willgoldstone
     
  24. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
  25. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    We've never really supported APEX. Been using the PhysX core PxCloth stuff. Now it's gone too, but NvCloth isn't that much different from it if you look closely. Mostly names changed, that's it.
     
  26. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,938
    +couple of minor bug fixes but you guys are already on that :D
     
  27. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353
    NvCloth migration will happen during PhysX 3.4 phase, some time around 2019.2 I hope, independently of PhysX 4.0 upgrade. (But it's going to be another thread)
     
    rizu and hippocoder like this.
  28. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,938
    New Physx is nice and all but 3.4 was the main important thing... kind of eager to get to having functionality now such as with colliders and whatnot, I think you have already done an awesome job as it is.
     
  29. Ashsun

    Ashsun

    Joined:
    Aug 28, 2014
    Posts:
    2
    @yant
    Thank you guys, it's great job!
    After some tests, we found it's more than twice faster than previous version in our scene!
    On mobile devices however, the boost it's not that obvious(about 10 percent).
    Is this normal? Or am I missing some settings?
     
  30. INEFFABLEGAMESTUDIOS

    INEFFABLEGAMESTUDIOS

    Joined:
    Aug 25, 2015
    Posts:
    16
    PhysX 3.4 vs PhysX 4.0
    I know we just switched to PhysX 3.4. When do you think we can use PhysX 4.0?
     
  31. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,587
    Give time to PhysX 3.4 to settle :) And don't blindly trust the 3.4 vs 4.0 comparison. They've setup the 3.4 joints in the worst and laziest way.

    PhysX 3.4 is not THAT bad. I've setup articulated machines that work pretty good even using real-world masses and sizes. The result is much closer to the PhysX 4 representation in the video than to the 3.4:

    https://vehiclephysics.com/about/showcase/#heavy-machinery



    I don't like the kind of comparison shown in the PhysX 4 video. It's like "Remember the physics system we've feeding you with and you've been using, loving, a doing great things with? Well, we gave you S***, looser. Ha ha. This is the real thing."

    While I have no doubt on PhysX 4 providing state-of-the-art articulations, I'm also pretty sure the result will be as bad (or worse) as shown for 3.4 if the components are not configured properly.
     
    Last edited: Jan 12, 2019
  32. INEFFABLEGAMESTUDIOS

    INEFFABLEGAMESTUDIOS

    Joined:
    Aug 25, 2015
    Posts:
    16
    Hmm, thanks Edy. I think the same thing. They shows 3.4 are is buggy or loser. Nah I don't believe this.
     
  33. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    I thought that part of the video was meant to be a joke, especially after the 3.4 arm lost it's cool and trashed the whole table :D
     
  34. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,938
    Thing is I don't see how ECS is going to improve joints. Because ECS is highly out-of-order and a chain is, well a chain. You can't calculate them at different times if it's going to be deterministic.

    What the heck, my brain is spinning...
     
  35. ClayChi

    ClayChi

    Joined:
    Mar 30, 2018
    Posts:
    7
    Comparison video shows physx weakest points and its how it performs after 4.0, which is multiple joints connected to each other, like a robot arm and how it's being controlled by machine learning.

    It doesn't mean to make it look bad or anything.But it could be that both arms are using same trained model under 4.0 and it's obviously will fail on 3.4. Or robot itself trained under newmethod that is not possible without 4.0 and 3.4 will also fail because it would only work on 4.0. Here is the some features of 4.0

    • Temporal Gauss-Seidel Solver (TGS), which makes machinery, characters/ragdolls, and anything else that is jointed or articulated much more robust. TGS dynamically re-computes constraints with each iteration, based on bodies’ relative motion.
    • The new reduced coordinate articulations feature makes the simulation of joints possible with no relative position error and realistic actuation..
    • New automatic multi-broad phase.
    • Increased scalability with new filtering rules for kinematics and statics.
    • Actor centric scene queries significantly improve performance for actors with many shapes.
    • Build system now based on CMake.
    This changes IMO, super duper cool. Because it will make stable machine learning robot/humanoid physics.
    Wish this was an easy drag n drop but probably unity needs to be aware of how big this update is, before updating unity to 4.0 :(
     
    Last edited: Jan 18, 2019
  36. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,938
    They seem to be topological changes, that is, they don't really alter much in 3.4, but are added on top. So it's not a big deal and if Unity is porting Physx to ECS then it is wiser to just adopt a wait and see IMHO.
     
  37. ClayChi

    ClayChi

    Joined:
    Mar 30, 2018
    Posts:
    7
    Fair points but, speaking of Physx to ECS part, in various articles mentions that with 4.0, it could work on GPU even on AMD GPU. Fluid physics, destruction any many other stuff too.
    I guess it's also big part of the release but wonder how it could work in Unity and ECS.
     
  38. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,938
    It would need to justify the development hours by working on mobile GPUs (some are faster than current gen consoles and there are more of them), Intel (most of the laptops sold in the world)... so not just adding AMD support.

    By contrast if Unity spends that engineering effort on an ECS version then the GPU version is actually not hard to add since the methodologies and libraries are very similar (ECS and HLSL).

    Not against it, just stating the obvious really, it's not something (GPU support) that will be swift to arrive.
     
  39. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,229
    Articles you've seen have most likely discussed about Nvidia GameWorks techs rather than about PhysX (these are not the same thing). Here's the relevant official documentation for GPU rigidbodies on PhysX 4.0: http://gameworksdocs.nvidia.com/PhysX/4.0/documentation/PhysXGuide/Manual/GPURigidBodies.html
    As what comes to Nvidia GameWorks, FleX (softbody, GPU particle physics, can do also fluid) and Flow (fluid/smoke simulation) both can be run on DX11/DX12 Direct Compute which makes them compatible on AMD GPUs as well. FleX also has CUDA only mode. FleX runs only on Win/Linux and Flow is Windows only. Since these (FleX and Flow) have really limited platform support, you are not likely to see these much in games.
     
    Last edited: Jan 18, 2019
  40. NotGoodEnoughh

    NotGoodEnoughh

    Joined:
    Feb 1, 2018
    Posts:
    35
    Add soft bodies
     
  41. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    353