Experimental build with the PhysX 3.4.1 upgrade

@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!

 

I'm happy to test and give feedback to anything related to that topic

 

@yant Has the contact modifications been given more thought?

 

Considering we just got PhysX 3.4.2, I guess it'll take a long time till we get PhysX 4.0 now ? (such an unfortunate timing, we were on bleeding edge PhysX release only for such a short time)
https://news.developer.nvidia.com/announcing-physx-sdk-4-0-an-open-source-physics-engine/

 

I'd love to see a quick bump as well

 

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/

 

Yeah and really, we're having ourselves a juicy ECS/Burst/Job version one day... depending on real world cache efficiency near Unity staff.

 

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

 

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.

 

Unity 2018.2 uses PhysX 3.3, they upgraded to 3.4.2 on 2018.3.

 

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.

 

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.

 

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 )
- convex sweeps and overlap checks (also pretty please..)

 

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.

 

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.

 

@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

 

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?

 

They dropped PhysX 4.0 RC here today: https://github.com/NVIDIAGameWorks/PhysX

Looking at the migration guide: https://htmlpreview.github.io/?http...entation/PhysXGuide/Manual/MigrationTo40.html it doesn't seem like hugely changed api. A lot of conf flags have been removed but most probably are fine.

Main issue I can see with this is if Unity's cloth solution is using Apex Cloth as it's finally removed in 4.0. Nvidia only supports NvCloth from now on.

 

+couple of minor bug fixes but you guys are already on that

 

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.

 

@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?

 

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?

 

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.

 

Hmm, thanks Edy. I think the same thing. They shows 3.4 are is buggy or loser. Nah I don't believe this.

 

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

 

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...

 

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

 

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.

 

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.

 

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.

 

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.

 

Add soft bodies