Hi! I’ve got a request for @yant that would seem like a logical next step, considering other non-DOTS APIs are being exposed or reworked to be better suited in use with Jobs (or even ECS) workflows.
Background
In my use case, we’ve built a self-balancing physics-based character that uses animations as joint targets. We read both the kinematic & rigidbody state into NativeArrays, and do all the dynamics computations very efficiently in fully parallelized (ECS) jobs from there. The kinematic state reading is done in an AnimationJob, which has very little overhead.
Performance cost
The most computationally expensive step in the whole system is reading the rigidbody properties, which takes up around 2ms for 100 actors with 15 ConfigurableJoint actuators each.
Benchmark
I’ve done additional tests with a million iterations on the main thread that confirm how expensive accessing rigidbody properties is compared to accessing struct values (around two orders of magnitude, and the cost is directly proportional to the number properties you’re accessing).
read 7 RigidbodyData struct properties (same as 1)
Note: This performance difference excludes gains we would be able to get from parallelizing the task using NativeArrays, or EntityQuery like TransformAccess allows for.
Being able to at least have read-access for rigidbodies in a simple NativeArray would serve my use case very well, with more functionality always being welcome of course. as Unity is moving more towards DOTS-friendly workflows.
Any chance @yant we can get a basic jobs-friendly API for Rigidbodies?
Considering that DOTS physics is still quite a pain to work with in a mostly GameObject based project, this would be an extremely useful performance optimizations for projects that rely heavily on physics or simply have a large amount of physics actors. So this would be a really useful addition!
I imagine the most logical way to achieve that would be to expose the immediate mode API actually – you’d get all the structs, arrays etc for your own managements and usage. Also all the calls to collision detection, solver, integration are explicit. Quite dots-y. I had an iteration on that some years ago, but time wasn’t quite right back then. Maybe times to consider this once again.
On another note, I wanted to mention that we’re going to work on exposing more structs-driven pipelines. One of the next to come is a way to extract shapes from Colliders and run all sorts of queries (also contact generation) on them in a job-full environment. It’s not ready yet, being baked as we speak.
Thanks for the answer - exposing the immediate mode APIs really sounds like a fantastically jobs-friendly alternative to accessing PhysX in Unity! Evidently I’d be highly interested in testing and using it if you’d manage to pick it up again.
The latter one also will be very useful - we currently depend on DOTS physics to generate on-demand contact info between two colliders, which obviously isn’t ideal because we’d prefer to use PhysX for that.
This would be a really handy feature. In my case I have 500+ vehicles, which run impressively fast thanks to the job system and burst compiler. Most of the time is lost reading the rigidbody properties beforehand, and the .AddForce, .AddForceAtPosition and .AddTorque afterwards.
Do you have any kind of estimate of when we could expect this (or maybe even just a preview version)? All of this would be fantastic, and I’m very much thinking I should wait for this to be available before I start a project I was about to start now
I’ve listed all the things that I find too limiting in the current PhysX integration here. I’d be curious to see if you think most of these can be solved? I feel like immediate mode would solve #2 and #3 https://discussions.unity.com/t/828581
How is the cooking going? There is nothing like the smell of freshly baked goods!
The reason I ask is because I would like to clean up the code a lot. Bouncing in and out of contact modification API is a bit of a pain, and kind of messy, so if I was able to work in one place, say all jobified, then it would be cleaner code and faster, right?
