Experimental build with the PhysX 3.4.1 upgrade

This is awesome! FYI for others, here are the official v3.4 PhysX release notes.

@yant my primary concern is whether you have integrated all the Vehicle/Wheel changes listed in there? The current implementation of wheel physics are very approximated and inaccurate for low-speed sim games. Some of the features in v3.4 such as PxVehicleSuspensionSweeps seem to greatly improve collision response on more complex surfaces. Is this something we can expect to see in this release?

 

+1 For the Vehicle/Wheel changes.

 

Holy crap, thank you, thank you, thank you so much!!!!! I was resigned to waiting for "2018.3 or later", which is what was previously stated for the timeline of PhysX 3.4.

My game needs 3.4. It's a game where you can build things, and currently there's a hard limit on the complexity of what you can build due to the hard PhysX limit of 262143 active colliders. Combining colliders is not an option for me as each one needs to be individually identified via raycast. I am ecstatic right now that I'll be able to remove the limit in my game's next release! Will you continue to provide early builds with PhysX 3.4 for the latest Unity version until it's fully integrated?

Also, this is just my opinion, but I think you shouldn't be shy of introducing new features and deprecating old ones. If people want support for old features, well, that's what the LTS stream is for.

 

Understood. Obviously take whatever integration course fits best for the release schedule.

If you have the spare cycles it might be nice to see a different experimental beta with those features added that we can play with, with the view that it'll be a 2019.x thing.

 

Awesome! I was waiting for this since the preview of physx 3.4 dropped. I will start testing with massive amounts of RBs and report results.

It would be great if we can get GPU Physx as an option, even though it is platform specific.

 

@yant so 3.4 works in the editor, but you cannot create builds with it?

 

Aw man. Thanks for the information.

 

Recent sdk, no breaking change, loving this.
Are there accelerated world queries like "closest object" in 3.4?

 

Yeah, the PhysX-GRB would be spectacularly useful even though it is specific to boxes.

 

Cool stuff. Any chance we could see PxArticulation exposed in the future?

 

Has anything been done to make the joints more stable? In PhysX 2.0 they were a lot more robust, in PhysX 3.3 they tend to freak out.

https://fogbugz.unity3d.com/default.asp?693205_mgti1lqk2kfh9hqu

https://forum.unity.com/threads/joints-in-unity-5-are-very-unstable-and-its-not-just-me.319084

 

VERY happy with this news!

Very nice is that with V-HACD, or just single objects for now?

 

Is this going to be a package one can install and test at any point?

 

Unlikely, @eobet. It's quite a fundamental part of the engine, I highly doubt it could be made hot-swappable in the way packages are.

 

Here's hoping it means exposing the cooking functions so we can cook the mesh colliders ourselves outside of a main thread asynchronously to prevent framedrops in the game.

Sure, the speedup (up to 10x may be nice; will do some perf benchmarks* in the upcoming weeks I guess), but being able to offload it to another thread completly would be superb.

*) Shame this experimental build cannot create standalone players tho, I'd prefer profiling the game outside of Editor.

 

I was hoping this would fix the suspension issue on the Wheel Collider, but apparently it is still there. The issue is that if the suspension ever get compressed to the very bottom it bounces back up in an unnatural fashion instead of just remaining fully compressed. Is this something that will be fixed or can it be mitigated somehow? (besides avoid applying too much force on the suspension).

 

What about a checkbox on a Mesh Collider, that would turn the asynchronous cooking on/off (on Unity's side of the engine), instead through a C# API? I reckon this could bring some nice performance improvements as well and be really really easy to use for the end user? Or does this go directly against the future plans you already have?

 

That's really powerful but in the near term being able to turn mesh colliders into several convex mesh colliders would be a positive improvement across our entire project. Is that coming too or did plans change and we should figure out a 3rd party option? (thanks for any reply).

 

Personally, I wouldn't expect the checkbox to be checked in scenarios where you need to immediately work with the changed collider. However, it would be IMHO suitable for usecases like loading new parts of a terrain in distance (where you don't need to do any raycasts/collisions yet) and not wanting to use main thread time to cook colliders before you start to spawn objects in the game world.

As for checking (at in userland C# code), I guess a simple boolean flag on the component (IsCooking) would be enough? Then the user can in his update loop check if the component he's waiting for to cook + integrate is still cooking or not.

Also, being able to switch the asynchronous cooking on/off during runtime would be really important, so colliders around the player are always recomputed synchronously and just the unimportant stuff that can wait can be done asynchronously.

However, if your goal is to move as many people to use the job system, then this would probably be counterproductive, I guess.

Well, this certainly sounds nice, but ... what is eventually? Any performance improvements can't come soon enough!

 

So far, I am liking this build. It fixed collision detection issues (objects don't collide!) that crept in 2017.2 onward that prevented . Overall, I feel objects are more stable and there is a noticeable performance improvements.

 

Tested 2018.2.0b4 and the PhysX experimental build (2018.2.0b3); while baking seemed to be faster, the sweeping OverlapBoxNonAlloc seems to take more time than before (especially during the startup of the game, when spawning a lot of stuff, when doing tens of thousands of these calls).

Is anyone else experiencing worse performance with the sweeps?

(However, these are just initial findings; I'll try to do proper testing later, both at the start of the game and after a while of playing, ideally with more samples.)

 

@yant Origin Shiftiing in Unity? -> https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/OriginShift.html

 

PhysX-GRB is not restricted to just boxes. The demo at GDC 2016 used a lot of boxes because it was all programmer art. PhysX-GRB supports every feature of the PhysX SDK besides articulations. You do need to cook convex and mesh assets with additional data to accelerate those on GPU, otherwise contact gen for those shapes will be processed on the CPU.

 

Thanks for this beta build! About to try it out.

Jobs api sounds great. However, I would love the option to simply bake the mesh collider manually off thread somehow. If this is easy to implement on your end, this would make our lives a thousand time easier.

 

@yant Can you tell if there's any plans for exposing Physx Contact Modification callback with PhysX 3.4.1? I've asked this before but haven't really seen any response. I know the physx api is kinda messy on this part, so I could suggest some structures that could streamline it for unity integration purposes if it helps anything.

 

Additionally, I'd like to see "Enhanced Determinism" scene setting exposed, it's just optional flag you set and afaik then physx will internally preserve the order or rigidbodies for internal solver even if you remove or add rigidbodies to the same scene. This feature is super trivial to implement, it really just requires you to set the flag on scene creation and that's it. You'd also definitely want to keep it optional as it involves some CPU overhead so not everyone would want to enable it.

I understand that the initial release will be more close the old setup to keep things simpler and not having to chase bugs created by the new systems. But I'd love to see more physx feats exposed later on if possible. Contact Modifications are something I've implemented on UE4 myself and I think it's pretty fundamental thing to have access to for any serious physics driven game. Like the Enhanced Determinism, it's not something that requires you to change existing features at all, it's addition to them but in this case, the implementation will require a lot more work than just the scene flag.

Default PhysX API for Contact Modifications is kinda messy as they have separate functions for each operation and collision pair. This could be simplified to make it more user friendly and to act more like current collision events do so it wouldn't feel so alien to users. I'll draft something up and send a message.

 

Thank you

Usually when people do these, they only need it for few objects so the cost isn't that huge. Think of a racing game where you only need to make sure the cars themselves handle collisions gracefully, this usually means 1-30 colliders that would be routed to get the events. It doesn't scale nicely for larger approaches but I don't think the contact modification itself does either, it's supposed to be use used to handle edge cases that you couldn't handle otherwise.

All that being said, just exposing just the array of contacts to modify in single global event + related functions is probably easiest and it still gets the job done. Many would be really happy if Unity can make this happen, the feature request for it is 126 votes atm which is pretty good, considering how little physics feats get voted in general. Also, people who really need this can handle it regardless how it's exposed as long it's there in some form (it's not exactly a feat beginners would use).

 

Do you know if this'll affect the performance/response of runtime terrain heightfield modifications?

 

What about caves/basements/underground bunkers or holes in the terrain, surely a thickness setting would prevent underground structures physics being impacted by terrain physics?

 

When duplicating GameObject's in the Hierarchy, the editor sometimes messes with the Scale value. For example, duplicating a GameObject or just changing its parent might change the Scale value from 1 to 1.000001 or 0.999999.

If the Scale is x=1, y=1.0000001, z=0.99999999 due to this Unity (editor) bug, is the Collider considered non-uniform and therefore has a negative impact on performance?

 

It's always exciting to see new physics stuff coming especially with those kinds of performance improvements!

I was wondering if 3.4 and Unity's integration will fix the Linear Limit and Angular Limit bugs on the ConfiguableJoints I've mentioned to you in the past?

Thank you!

 

It would make my life way easier if we got articulations implemented. Their basically required for VR physics to not be hell to work with. basically anything with multiple joints isn't going to be stable in VR. =<. its super cool to see the new version though!