Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice
  2. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  3. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Jobs-friendly APIs for Rigidbody (like ContactModification/TransformAccess/BatchRaycast)

Discussion in 'Physics Previews' started by LudiKha, Oct 6, 2021.

  1. LudiKha

    LudiKha

    Joined:
    Feb 15, 2014
    Posts:
    140
    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).

    upload_2021-10-6_13-54-58.png
    1. read 7 rigidbody properties (position, rotation, mass, velocity, angularVelocity, inertiaTensor, inertiaTensorRotation)
    2. read 2 rigidbody properties (position, rotation)
    3. 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?

    Cheers,
    - K
     
    alemnunez, K3CK, Edy and 1 other person like this.
  2. one_one

    one_one

    Joined:
    May 20, 2013
    Posts:
    621
    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!
     
    LudiKha likes this.
  3. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    595
    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.
     
  4. LudiKha

    LudiKha

    Joined:
    Feb 15, 2014
    Posts:
    140
    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.
     
    one_one likes this.
  5. K3CK

    K3CK

    Joined:
    Sep 12, 2018
    Posts:
    6
    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.
     
    alemnunez, LudiKha and one_one like this.
  6. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    1,926
    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://forum.unity.com/threads/dot...i-had-in-monobehaviour-physics-physx.1057004/
     
    Last edited: Jan 12, 2022
    NotaNaN, LudiKha, K3CK and 2 others like this.
  7. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    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?

    Thanks for your time (and baking expertise).
     
    Pr0x1d, NotaNaN, elcionap and 4 others like this.
  8. joshrs926

    joshrs926

    Joined:
    Jan 31, 2021
    Posts:
    111
    Did anything ever happen with this? I’d love to have job access to read/write Rigidbody velocity.
     
    K3CK, one_one and LudiKha like this.