Search Unity

[Showcase] Peak Physics - Large scale CPU physics

Discussion in 'DOTS Physics' started by AndersOrum, Nov 9, 2018.

  1. AndersOrum

    AndersOrum

    Joined:
    Aug 31, 2014
    Posts:
    49
    Hello everyone!

    I hope it's okay i do a little showcase in this section of the forum, but since this is mostly a performance showcase of the Job System, Burst, ECS and DOD i think it's most relevant here.

    So lately i've been working on a new physics engine to power my softbody based vehicles and heightmap deformation based terrain physics, 2 perfect subjects for optimization through DOD, ECS, Burst & Parallel Multi threading.
    Initially i built a proof of concept engine where i've integrated seamless interaction between softbody, rigidbody & particles, on top of that i'm also trying to integrate per body/constraint selection between force, impulse & position based dynamics while maintaining seamless interaction.
    The proof of concept was built with a standard OOP single-threaded design using the classic way with GameObjects, MeshRender & MeshFilter etc to represent bodies, i did this well knowing i later would have to rewrite it all in order to take full advantage of all the new performance options we have available now, but since i hadn't worked with either the Job System, ECS or Burst before i thought it would be best to wait with those and focus on the actual physics implementation and at the same time use the prototype for performance comparison, and wow what a difference!

    Now on to the exciting stuff, before i go into more details i'd like to show a small demonstration of the scale of the performance capabilities.

    The demos below are running at 50Hz with 2 contact iterations.
    • 20k bodies/particles with full two-way interaction piling in a small 50x50x50 meter box made of plane colliders, here we are solving about 100k potential contacts and 60k actual contacts each iteration:



    • 200k bodies/particles with full two-way interaction however spread out and falling onto a 1x1km plane spaced with 1 m between each body.

    [Edit] Added hardware specs.
    CPU: Intel i7 4790k
    GPU: Nvidia GTX 970
    RAM: 16 GB 1333MHz

    Compared to my prototype which was actually relatively decently optimized, i'm seeing 20-200+ times speedups everywhere.

    Now i will not do any direct comparison to other physics engines at this early stage as there's obviously still quite a few features missing to make a fair comparison, however i already feel pretty confident saying that no other currently commercially available physics engine can keep up with the scale of performance potential this have.

    Below you can see the full feature set implemented in the initial prototype before i started on the "real" engine, and everything written in blue are the features currently converted.
    Feature List: (Updated 11-Mar-19)

    Dynamics:
    -Force Based Dynamics
    -Impulse Based Dynamics
    -Position Based Dynamics


    Physics Objects:
    - Softbody
    - Rigidbody
    - Particle
    - LinearNode
    - AngularNode

    Integrators:
    - Explicit Euler (2 different variants)
    - Semi-Implicit Euler ( 2 different variants + angular integration)
    - Verlet (3 different variants)
    - VelocityVerlet ( 2 different variants)

    Constraints & Motors
    - Spring Constraint(With & without elastic deformation)
    - Distance Constraint (Force, Impulse & Projection variants)
    - Point Constraint (Projection Only)
    - Linear Motor (Force, Impulse & Projection variants)
    - Angular Motor(Torque & Impulse variants)

    Global Forces:
    - Linear Gravity
    - Spherical/Orbital Gravity
    - Linear + Angular Damping(Force & Velocity based variants)
    - Fluid Drag
    - Buoyancy
    - Wind force

    Collision Detection:
    -BroadPhase

    - AABB (Axis Aligned Bounding Box)
    - OBB (Oriented Bounding Box)
    - OBS (Oriented Bounding Sphere)
    - Brute Force Method
    - Spatial Partitioning (Grid)


    -NarrowPhase
    - SAT (Separating Axis Theorem)
    - Sphere Collider
    - Plane Collider
    - Contact Manifold Generation(Relative Velocity, Contact Normal, CollisionPoint(s), Penetration Depth)


    Collision Response:
    - Penalty Method (Force/Acceleration based)
    - Linear + Angular Impulse Method (Velocity/Momentum based)
    - Projection Method (Position based)

    -Friction
    - Linear Force based Friction
    - Linear + Angular Friction Impulse (Velocity/Momentum based)
    -Restitution(Bounciness)
    -Baumgarte Stabilization

    -Collision Solver
    - Gauss-Seidel method (this will probably not be converted as it doesn't really work in parallel)

    Physics Material
    - Friction
    - Restitution(Bounciness)

    Other features
    - Mesh skinning/deformation
    - Raycasting
    - Raycast based Wheel Collider
    - Per Node/Body Integration method

    - Cloth cutting and tearing (proper mesh separation is not yet implemented)
    - Internal Softbody collision
    - Procedurally generated softbodies + mesh (currently only Clothplane and Cube)
    - Multiple simultaneous physics worlds.
     
    Last edited: Mar 11, 2019
  2. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    28,033
    *whispers something about standalone builds being 10x faster*
     
  3. AndersOrum

    AndersOrum

    Joined:
    Aug 31, 2014
    Posts:
    49
    Hehe i was afraid i would get flagged for demoing this in the editor however i'm not seeing anywhere near such dramatic difference between the editor and standalone builds more like up to 25% at best, but yeah any serious performance benchmark should be done in a standalone build no arguing there, i will do proper performance test one of the following days and put up some numbers and more details about the cost of each system and what else may be interesting.
     
  4. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    28,033
    Forgot to say: absolutely amazing work so far.
     
    AndersOrum likes this.
  5. eizenhorn

    eizenhorn

    Joined:
    Oct 17, 2016
    Posts:
    2,295
    In Job, Burst context difference is big, because in editor they have many protection checks and other stuff which not exists in builds and performance x10 faster, in some cases:) And yes good work :)
     
    AndersOrum likes this.
  6. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,167
    you can turn those off in Jobs menu. You can have both Safety checks off & job debugger disabled.

    Not saying that it's a good thing to profile in editor. But 10x is not what you should expect when you compare to editor with checks turned off.
     
    Last edited: Nov 13, 2018
  7. eizenhorn

    eizenhorn

    Joined:
    Oct 17, 2016
    Posts:
    2,295
    Yes of course, forgot to say about that :) thanks for clarifying :)

    In some cases we gain more than x10:D from 14ms to 0.9ms, but of course with enabled safety checks:D
     
  8. starikcetin

    starikcetin

    Joined:
    Dec 7, 2017
    Posts:
    297
    Great stuff. Good to see multiple competing physics libraries. I hope Unity also release one in the near future so we have even more options to choose from.
     
  9. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    9,039
    I love that big floating ball in first video.
    I see you got quite few features done.
    Well done.
     
  10. AndersOrum

    AndersOrum

    Joined:
    Aug 31, 2014
    Posts:
    49
    Hi guys,

    Finally time for an update, i've been working on many features related to the softbody core of the engine and it's coming along nicely, new features includes:
    - Softbody Physics
    - Mesh Skinning/Deformation
    - Ray Casting
    - Raycast Based Tire Physics
    - Force Based Linear Friction
    - Force/Penalty Based Collision Response
    - Per Node Integration method
    - Semi-Implicit Euler Integration
    - Verlet Integration
    - Spherical Gravity
    - Softbody Designer Editor Tools


    In the video below i'm testing the new softbody physics with a simple chassis frame, suspension and axles made of 34 nodes & 154 constraints combined with tire physics based on raycasting.

    The simulation is running at 1000 Hz using Semi-Implicit Euler Integration, Force based collision and friction.

     
  11. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    9,039
    Looks neat. Good looking update.
     
    AndersOrum likes this.
  12. khos

    khos

    Joined:
    May 10, 2016
    Posts:
    1,159
    NICE! Will this work with e.g. car tires, physics, would you make this available someday?
     
  13. AndersOrum

    AndersOrum

    Joined:
    Aug 31, 2014
    Posts:
    49
    Do you mean tire physics based on softbody physics like the chassis? If so yes definitely, but currently i'm missing a couple of features to make that possible
    1. Constraints/springs between 2 bodies(currently only internal constraints is possible, but it's only a matter of creating editor tools to setup external constraints)
    2. Torque/angular motor constraint

    Other than that i expect stability issues to arise with fast rotating softbodies like wheels which will need to be solved somehow as well.

    I do want to make it available someday, but first i want to release a game with my vehicle and terrain physics and probably a long the way make it available for use in simulations and then finally available to gamedev.
     
    khos likes this.
  14. AndersOrum

    AndersOrum

    Joined:
    Aug 31, 2014
    Posts:
    49
    Time for another update,

    This time a small performance stress test of the softbody system

    In this demo i have 200 softbody tires, all of them mesh skinning enabled(recalculation of vertex normals is disabled in this demo since i haven't optimized it for multithreading yet).
    Each wheel is made of 34 nodes and 145 constraints, 432 vertices 34 bones and 1408 boneWeights.

    Scene Stats:
    Average Fps: ~200
    Physics Frequency: 1000Hz (0.001)
    Softbodies: 200
    Nodes: 7000
    Constraints: 29000
    SphereColliders: 6800
    Skinned Meshes: 200
    Bones: 6800
    BoneWeights: 281600
    Skinned Vertices: 86400


    Hardware Specs:
    CPU: I7 4790k @ 4GHz
    GPU: Nvidia GTX 970 4Gb vram
    RAM: 16 GB DDR3 @ 1333MHz

    New Features:
    - External Constraints
    - Procedural Softbody Tire Generator
    - A bunch of optimizations
     
  15. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    9,039
    Looks interesting.

    I assume, you haven't implemented physics sleep method, since all thread running at full, even tires are still standing.
    At T:31 you show tires colliding. But looks buggy as of yet. Is intercollisions something, to work on at some point?
     
  16. AndersOrum

    AndersOrum

    Joined:
    Aug 31, 2014
    Posts:
    49
    Yep no sleeping mechanism implemented yet.

    Currently softbodies only have node collisions there's no collision triangles/faces yet, so while they are actually properly checking collisions between bodies there's just a very small chance of the nodes with a sphere collider radius of 5cm to actually hit each other. So this is an area that still needs a lot of work and optimization, currently each node is potentially checking for collision between all the other 7k nodes, the softbody isn't wrapped in an AABB(or another bounds shape) only each individual node is each node even checks collision of all the other nodes within same body as it is right now, they are however sorted trough the Broadphase with the grid implementation but that's it.
     
    Last edited: Mar 14, 2019
    MostHated likes this.
  17. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    9,039
    Well, even so, system behaves smoothly already. That performance for its own is very impressive in my humble opinon. Well done so far.
     
    Last edited: Mar 14, 2019
    MostHated likes this.
  18. jselstad

    jselstad

    Joined:
    Apr 12, 2016
    Posts:
    6
    It turns out you can do Gauss-Seidel in parallel if you use Graph Coloring (which divides up your vertices/constraints into a set of mutually independent parts, which can all be solved in parallel safely):


    The method seems relatively straight forward (and even the graph coloring part is parallelizable as well!):
    http://publications.lib.chalmers.se/records/fulltext/245496/local_245496.pdf
     
  19. zalo10

    zalo10

    Joined:
    Dec 5, 2012
    Posts:
    21
    If you’re looking for a simple jobified normal calculation, I have one here that is equivalent to Unity’s. (I do have a parallel solution there as well, but it takes 95% as long to execute AND it ties up all 8 cores. Better to just tie up one for about the same length of time, possibly better to paralleize only across meshes rather than vertices).

    IQ has some more info on it:
    https://iquilezles.org/www/articles/normals/normals.htm

    And there’s some volume preserving soft body code/scenes there too (might be a bit messy though):
    https://imgur.com/XCpohaf
    https://imgur.com/BBNKFHl
     
    Last edited: Mar 15, 2019
    goncalo-vasconcelos likes this.
  20. AndersOrum

    AndersOrum

    Joined:
    Aug 31, 2014
    Posts:
    49
    Thanks for the links guys,

    Yes i've come across a couple of different parallel implementations of the Gauss-Seidel solver, but in my limited experience on the matter i found the Gauss-Seidel solver to be mostly suited for a Position Based Dynamics Spring-Mass system where it works great for stability and accuracy, but not as great with a Force Based Spring-Mass system which i'll mainly be using, but this is an area where i still need research and experiment before i can say for sure, and since i plan to keep supporting both force, impulse and position based dynamics i'll probably have to implement different solvers for each of them to get the best results.

    Oh and by the way i just want to point out the Gauss-Seidel video/paper you linked, their implementation and discussion is entirely GPU based, this doesn't change it's relevance but it's an important difference when it comes to the performance of the algorithm.
     
  21. AndersOrum

    AndersOrum

    Joined:
    Aug 31, 2014
    Posts:
    49
    Update v.0.0.22

    In this update i've focused on features and improvements related to my softbody based tire physics, as i expected high angular velocities in softbodies like had some problems, initially about 20 rads/s was the limit, above that they would start expanding rapidly as the velocities increases, at about 30 rads/s the tires had doubled in size but they would remained stable up to about 60 rads/s even though it had expanded to more than 10x it's size in diameter, luckily i was able to solve that with Directional Spring Constraints, which simply applies different strength and damping values depending on whether the length on the constraint is smaller or larger than it's target length, so with this type of constraint used the tires are now able to handle angular velocities up to about 150 rad/s while keeping it's shape and only expanding about 1cm in diameter and remains stable. I could probably stabilize it for even higher rates by using more constraints specifically for stabilization but it's currently only using the minimum number of constraints needed to make up it's shape.

    I'm quite happy with these results so far, but the tires are currently just a simple node/constraint design the actual wheel design i'll be using will have rim and tire as separated bodies, that will double the node count and more than double the constraint count per wheel so how it performs at high angular rates is still unknown.

    In this video i demonstrate the new tire physics and torque constraint on a simple softbody vehicle(i'm by no means trying to replicate the actual performance or handling characteristics of the vehicle) reaching speeds up to 300 km/h which translates roughly to 130 rads/s for the wheels used with a radius of 0.65m(these are rather large wheels which normally would be used on trucks).
    The video and all of the above test was running at 1000Hz using Semi-Implicit Euler Integration.


    New Features:
    - Force Based Constraints: ElasticSpring, PlasticSpring, BreakableSpring, DirectionalSpring
    - Torque Motor Constraint (Softbody)
    - VelocityVerlet Integration
    - Raycast-Triangle Collision Detection
     
    FROS7, jdoxbotica, rz_0lento and 5 others like this.
  22. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    2,154
    Kinda mandatory question at this point: I know you've been doing this tech only for your own game in past, have you changed your mind on the possible licensing already? :)
     
  23. jdoxbotica

    jdoxbotica

    Joined:
    Aug 6, 2018
    Posts:
    7
    @AndersOrum do you have any articles or links that would cater to a beginner who wants to learn how to get started with doing soft body vehicle physics?
     
  24. AndersOrum

    AndersOrum

    Joined:
    Aug 31, 2014
    Posts:
    49
    I apologize for the long delay guys.

    Currently my vehicle-, terrain- and physics engine is for personal usage only, but further down the line i'd like to open up for the possibility of licensing all of it, but i don't expect to open for licensing until after i've released my own game using all the tech i'm working on.

    Information on this subject is very hard to come by it's pretty much non-existent as far as i can tell, besides Rigs of Rods' and BeamNG's modding guides i haven't been able to find any tutorials, articles, papers or anything discussing spring-mass system based vehicle physics, softbody physics are rarely used for much more than cloth.

    RoR and BeamNG's guide isn't so much about the basics of vehicle creation with spring/mass system, but rather about configuring vehicle within the games, but they do provide some info which i think would be helpful for a beginner,
    for example you can take a look at RoR's suspension design page, this provides some examples and ways to build different types of suspension dynamics, but keep in mind you may not be able to create similar design depending on which physics engine you are using, Truss Physics for example is lacking many features compared to RoR and BeamNG which limits your possibilities.

    Besides that i suspect there's quite a lot of useful info scattered throughout RoR' and BeamNG's forums, this is probably your best bet for finding info. Personally i've mostly learned with the "trial and error" method which works great for something like this but of cause is very time consuming.
     
    Hybridizer and rz_0lento like this.
  25. newlife

    newlife

    Joined:
    Jan 20, 2010
    Posts:
    908
    Hello @AndersOrum,
    are you still working on the project? Hope yes cause its very interesting.
     
  26. AndersOrum

    AndersOrum

    Joined:
    Aug 31, 2014
    Posts:
    49
    Hi Newlife, thanks for your interest in my project.

    The project is still going strong, i did take a break for a couple months, but i'm back on it and making great progress again.

    Since my last update here i've worked on a bunch of new features, improvements and optimizations, which includes:

    Peak - Core

    Collision:
    • Box Collider
    • Terrain Collider - Supports multiple physics materials, each alphamap layer can have unique physics materials attached, so for example sand is more soft and have less friction than rocks, currently it selects the most dominant layers physics material but later i'll add blending between layers.
    • Layer based collision sorting (it's not using the built-in layer system in Unity, so there's no hardcoded limit to the number of layers)
    • Physics Material - Each collider can now have an unique physics material attached, each physics material controls the strength/damping(force based collision only) as well as the friction of a collision.
    • Static Friction(Force based)
    • Collision response stability improvements - As can be seen in my last video there were some slight jitter between tire-ground collisions, introducing Baumgarte stabilization in the force based collision response helped eliminate this issue.
    Constraints:
    • Torque Motor Constraint - Improved and optimized the implementation.
    • TorsionSpring Constraint - TorsionSprings is a new constraint type it works a little different then most other constraints, nodes doesn't have a rotation or angular velocity so a torsionSpring between 2 nodes wouldn't make sense, instead a torsion spring can be added between 2 Torque Motors, for example i use torsion springs with high stiffness to simulate differential/transfercase locking and inter-axle locking on vehicles.
    • Constraint Solver(Optimization) - The last single threaded part of the solver is now able to be solved in parallel, this was achieved by presorting constraints when they are added to the system, which means Constraints are now solved 100% in parallel, this results in about 40% speed up in the constraint solver.
    • Axis Constraints - Axis Constraints is also a new constraint type/category, it's a 3-body constraint and it works by first defining something i call "Axis Links" this is simply a link between 2 nodes it doesn't exert any forces it just calculates the direction, center, velocity etc. between the nodes, a 3. node can then be attached to the Axis Link with different kinds of constraints for example a simple spring constraint which will constrain it to the closest point along the Link while moving freely along axis of the line, the reason for making Axis Links a separate "constraint" was to allow connecting any number of nodes to the Axis Link while only calculating the Axis Links data once. Axis constraints will be usefull for several things but my main usage will probably be to reduce the number of nodes/constraints needed to create advanced suspension designs, but it could also be used as rails guiding a train for this i have plans to implement curved Axis Links based on bezier curve for example.
    Peak - Vehicles

    I've also started transferring my vehicle system to Peak, and at the same time also working an many improvements to the vehicle system, i'm especially experimenting with the powertrain simulation trying to get a more physically correct model which allows both internal and external breakage.

    • Engine - The internal of the engine is basically simulated as 2D Rigidbody but only angular dynamics is calculated(rotation,angular velocity, inertia, torque) i call these AngularNode2D, while linear dynamics is completely omitted(position, linear velocity, mass, force) from the internal simulation and instead is modeled as a spring/mass(softbody) system like the rest of the vehicle, so the internal and external of powertrain components/bodies is simulated as 2 independent systems.
    • Gearbox/Transfercase/Differential etc. - Powertrain/drivetrain components can either be simulated as individual AngularNode2D's like how the engine is simulated or combined into a single AngularNode2D, the individually simulated setup suffers from instabilities at high inertia ratios between components when large torques is exerted on the system, the combined setup handles such scenarios much better.
    • Clutch - The clutch simulation is basically a modified torsion spring constraint between the engine node and the gearbox node.
    • Driveshaft - Driveshafts which connects powertrain components in the individually simulated setup is simply modeled as a torsion spring constraint.
    • Wheel - New improved node/spring design which models both rim and tire in a single softbody. This design is made of about 70 nodes and 400 constraints per wheel, wheels can be created fully procedurally.
    I'm also working on a couple high detailed softbody vehicle designs similar to my previous designs i used with Truss Physics these will be made of about 700-1000 nodes and 3000-5000 constraints per vehicle.
    In order to achieve high rigidity and stability at high angular velocities(while using realistic node weights) for the new high detailed wheels and vehicles designs i had to increase the physics update rate from the previously used 1000Hz up to 2000Hz, for reference BeamNG/RoR is also running at 2000Hz while when i used Truss i ran it at 800Hz, so far my tests have been made with the Semi-Implicit Euler integration, but i still need to test other integration methods like the Verlet integration which may be able to achieve better stability and rigidity at lower frequencies.


    Peak - Environment

    And finally i've started experimenting with my dynamic heightmap(terrain) deformation, i don't have a lot of info to share on this yet as it is still at a very early stage.

    I've also experimented on aerodynamics which simulates drag and lifting forces, this will calculate lift and drag based on atmospheric density and bodies geometry's angle of attack against the velocity direction, however this was prototyped outside of Peak Physics since i haven't implemented collision triangles/faces in Peak yet.


    So this is pretty much what i've been working on lately, there's lots of other small changes, bug fixes, optimizations etc. but not really worth mentioning.
     
    Edy, RobeKey, GliderGuy and 6 others like this.
  27. newlife

    newlife

    Joined:
    Jan 20, 2010
    Posts:
    908
    Just one word: WOW!!
     
  28. Thygrrr

    Thygrrr

    Joined:
    Sep 23, 2013
    Posts:
    297
    10x faster than that? omg.
     
  29. newlife

    newlife

    Joined:
    Jan 20, 2010
    Posts:
    908
  30. AndersOrum

    AndersOrum

    Joined:
    Aug 31, 2014
    Posts:
    49
    Will do, i expect to share a new big update next week! :)
     
    RobeKey and newlife like this.
  31. erikschouten17

    erikschouten17

    Joined:
    May 17, 2020
    Posts:
    1
    Excited to hear about the new big update!
     
  32. Nyanpas

    Nyanpas

    Joined:
    Dec 29, 2016
    Posts:
    406
    I thought this was all based on some sort of 3D Verlet integration. I am surprised to see it being Euler. What made you go with Euler?
     
  33. khos

    khos

    Joined:
    May 10, 2016
    Posts:
    1,159
    Have not heard of anything yet, are you still planning an update?
     
unityunity