[Showcase] Peak Physics - Large scale CPU physics

Unity Engine
,
1

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,]( Vehicle Physics Simulation (Update 20-Feb-17 Terrain Editor Preview 1) page-2) 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.
26 Likes
2

whispers something about standalone builds being 10x faster

5 Likes
3

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

Forgot to say: absolutely amazing work so far.

2 Likes
5

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 :slight_smile:

1 Like
6

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.

3 Likes
7

Yes of course, forgot to say about that :slight_smile: thanks for clarifying :slight_smile:

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

8

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

I love that big floating ball in first video.
I see you got quite few features done.
Well done.

10

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.

18 Likes
11

Looks neat. Good looking update.

1 Like
12

NICE! Will this work with e.g. car tires, physics, would you make this available someday?

13

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.

1 Like
14

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
5 Likes
15

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

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.

1 Like
17

Well, even so, system behaves smoothly already. That performance for its own is very impressive in my humble opinon. Well done so far.

1 Like
18

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!):

4 Likes
19

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:

And there’s some volume preserving soft body code/scenes there too (might be a bit messy though):

1 Like
20

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.