[RELEASED] uPhysics & uPhysicsPro

Community Showcases
1

-uPhysics-

uPhysics is a custom, selfmade, integrated and dedicated game physics engine for Unity3D. It’s intend is to speed up the internal physics by replacing it completly. It archives its task by using extensive multithreading, moving any pressure from unity’s mainthread to remaining cores/threads. This will ensure a stable and high framerate on the mainthread while still having proper physics. It archives speedups by an order of magnitude and is capable of moving thousands of objects at once.

uPhysics will get alot of new features in the near future. See the “In the works” list for more details.

Features

  • Highly multithreaded

  • Load balancing of transform components over several frames, increasing performance by alot

  • Rich set of collider shapes

  • Sphere collider

  • Box collider

  • Capsule collider

  • Cylinder collider

  • ConvexHull collider (Mesh)

  • kDOP collider (Mesh)

  • Convex decomposition collider (Mesh)

  • Automatic compound collider

  • Any shape can move freely

  • Any collider can be used as trigger

  • Rich math

  • GC friendly (Allocators)

  • Rigidbodies

  • Rigidbody dynamics

  • Constraints

  • Global forces

  • Many little snippets to be discovered

  • Fast!

In the works

  • Joints/More constraints

  • Local and single/two body forces

  • TriMesh collider (Standard unity mesh collider)

  • Terrain collider

  • Bug fixes and tweaks

  • Raycasting

  • Multi simulation in one scene, not just one

  • Further stability, performance and memory improvements

  • Network syncronized/optimized physics

  • Decoupling of code, virtualization of objects so objects can be created/hosted from script without the need of an actual GameObject as host, dramatically increasing performance for server’s and alike

  • 2D and particle load balancing

  • Native and GPU acceleration

  • Rich wheel collider and Vehicle API

  • Controller’s (Character, Vehicle, … )

  • Simulation rewinding/replaying/recording

  • Better event integration using unity’s serializable events

  • Better convex decomposition for uPhysics AND Unity mesh colliders (Concave colliders)

  • Rope physics for uPhysics AND Unity

  • Destruction/Deformation for uPhysics AND Unity

  • Soft body physics (Cloth)

  • Inverse kinematic (Ragdolls and alike)

  • Raycasting/Physics in editor while not in playmode

  • uPhysics → Unity collider interaction (Lets uPhysics colliders interact with Unity ones)

  • Demos/Videos/More documentation

Changelog:

2.1.1

  • Added cylinder collider
  • Added constraints (WorldPoint, Grab, Distance)
  • Added global forces (custom gravity, Motor (torque), singularity )
  • Added manual simulation stepping
  • Fixed editor stepping related bugs

2.1.0

  • Added dynamics
  • Added rigidbodies
  • Added constraints backend
  • Added force backend
  • Reviewed/Optimized colliders, added cached ones
  • Disabled terrain collision, due to major update (coming back next version with TriMesh collision)
  • Reviewed/Optimized uPTransforms
  • Greatly optimized LoadBalancer and PhysicsLoop performance
  • Optimized garbage production with allocators
  • Optimized multithreading
  • Added sweep and prune broadphase (now default one)
  • Optimized convex object collision (implemented MPR)
  • Added recognition mode for triggers
  • Rigid-Rigid, Rigid-Collider, Collider-Collider collisions
  • Source is now more OOP
  • Much more little details

2.0.0

  • Reviewed full system
  • Added full set of colliders
  • Various mesh colliders

1.0.0

  • Initial release

Asset store packages:
uPhysics / uPhysicsPro
(Packages were previously seperated into library and source version. Both versions now include the full source code!)

Manual (Deprecated)

Support: Sharp.Development@web.de

NOTES

  • Anyone owning a uPhysics/uPhysicsPro copy can receive access to the private dropbox project and therefore to the newest version without the need to wait for the asset store submission. Just message our support with your invoice number.
2

Interesting. I’m a bit surprised that you can get such performance. A webplayer demo would be awesome to check that! Do you use PhysX like Unity does?

How difficult/long would it be to integrate your solution in a project and make everything use your engine instead of Unity’s one? For example, would it be easy to make a Character Controller using your physic system?

What about mesh colliders? Is there any method to create them on the fly?

3

Thanks for you reply!

As soon as I get the final touch done, I’ll write a manual aswell as including example projects demonstrating every aspect of the framework.
A webplayer demo sounds like a perfect addition, I havent thought of yet!

No, im not using PhysX. Integrating it in a custom framework would carry the need of users having unity pro since PhysX comes in shape of c++ dll’s. However, PhysX is not the ultimate physics library anyways. Its dedicated for extensive GPU multithreading to utilise its whole power, so it aint really suited for our single threaded unity. However, my system, like stated above, does make extensive use of CPU multithreading to get the pressure from unitys mainthread, in order to let it run more smooth.

How easy it is to integrate this framework? Good question!
Short answer: Very easy.

Long answer:
This framework implements own custom components, that means for characters and interacting objects (static environment colliders excluded). So, yes, theres no need for any unity internal component like character controllers. The system implements all of a character controllers functions by default in its own components.

Implementing the system means several steps:

  1. Create a simulation area (or multiple) where your objects interact in. Those can be as big or small as desired. Specify the physics and movement timesteps of that certain area and, if you want to use gravity, bake a heightfield. That setup is done within a few clicks. :wink:
  2. Every interacting object (for example your character controllers and trigger colliders/colliders, excluding static environment colliders) should be replaced with the internal component called “PhysicsObject”. On this component you can then specify how the object behaves, either in the editor or by script. However, I will aswell implement a few minor functions to convert character controllers and trigger colliders/colliders to the system components.

Technically, thats all. However, theres way more options to finetune the performance. For instance, the movement timestep of an area. That timesteps will move every registered PhysicsObject with load balancing each interval when that certain object has requested a movement.
Requesting a movement, for example, means calling the “MoveInDirection”/“MoveTowardsPoint” method of that object.
And for even further optimization, instead of requesting the movement in the update method, you can define MovementExecutors which will let you implement the systems custom update method which will be called with the movement timestep of the area. This happens on another thread all at once so you wont have the overhead of unity calling 5k monobehaviour - Update methods each frame.

For environment colliders, they can stay as they are. The system will recognize any static environment collider on startup and execute collision events on them. However, for static environment colliders, only primitives are supported, that means box, capsule and sphere colliders.

PhysicsObjects can use sphere or capsule colliders. Depending on need, you can let the EnhancedPhysics framework do the whole collision detection, or when needed otherwise, let the system use unity internal colliders. That means, when a collider comes in range, the unity collider will get enabled. However, by default, the system will do every range or collision detection related stuff itself when not specified otherwise.

Coming to your last point, MeshColliders. Unity itself struggles with multiple MeshColliders, they arent really performance friendly at all. In most cases they can easily be replaced with primitives. So yes, the system doesnt support them and I unfortunatly doubt it will ever. :confused:

4

First of all, WOW. You ran into it too.

We ran into the same problem with our current development project, where first of all Character controllers are CPU killing if you have more than one, so we switched to rigidbodies with capsule colliders…
This introduced a lot of problems to make everything look right and perform well…

Then we ran into issues with general physics performance (which person at unity decided to run everything on the main thread?).

I am quite excited to check out your work.

A few questions.

You said you don’t support mesh colliders, none at all? Imagine a house, made out of destructable parts, and we destroy certain parts of the house on explosion for instance, these parts have (simple) meshcolliders, and we would def need to keep these so you can for instance fire through gaps in the building.

these houses have no rigidbodies and are static colliders, we simply remove the house part on hit, and have client side effects to make this look nice.

What is your ideas for this?

5

I see the need in this case for a meshcollider. As long as they stay static it might not be a problem but let me go a bit indepth first.

Without changing the system at this point I could definitly think of multiple ways to realize this.

  1. As long as you want pure collision detection, the mesh collider can be roughly rebuild with box or sphere colliders around the gap. So you still would be able to fire throught the gaps. However, this requires way to much setup.

  2. Objects like projectiles shouldnt be PhysicsObjects at all, only character, monsters, players, objects which move or interact like items on the floor, w/e. Projectiles are most of the time to fast to be actively handled by my system. So infact, I would let unity handle the projectile and keep the meshcollider on the house. That means those can pass throught the gaps. However, there would be no way a PhysicsObject could collide with the MeshCollider. So, my idea would be to implement EnhancedPhysics ONLY primitive colliders which would behave like unity colliders but only collide with acctual PhysicsObjects. So you could keep your MeshCollider, fire projectiles throught it but let PhysicsObjects collide with an internal collider by overlaying, lets say an internal box collider, over the MeshCollider. I assume that only projectiles should pass throught the gaps but a character shouldnt. Doors could be rebuild with method 1 above. Those enhanced physics collider could ofc be removed to any time. (Which would fullfill your need of removing parts of the house).

Though, the idea of the internal enhanced physics colliders just for PhysicsObjects could aswell be done via internal unity colliders by specifing collision layers.

MeshCollider and Projectile = Layer - Projectile
Overlay box collider and PhysicsObject = Layer - World

However, if the second solution aint sufficient, I might end up coding a meshcollider to primitive collider converter. :wink:

6

Seems very useful. Does it work with the Unity terrain ?

7

Yes it does.

Though, you have to bake a so called “heightfield” for it. Its technically just an array of heights produced by raycasting from a certain y-position. So this heightfield technically represents the moveable height aka terrain heightmap.
The nice addition with this technique is that stuff like ramps or bridges will be automatically included, no need to walk over those via “collided below” events but rather by default.
The downside, though, is that, under circumstances, youll have to disable colliders like houses while baking. Though, theres alot of customizeable options how the heightfield should be baked to get around it. For example, layerbased or terrain collider only.

8

Nice. Have you decided on price yet ?

9

Not yet, but I guess inbetween 40-70$.

I am acctually hoping for some serious suggestions from the community. :wink:

10

This sounds pretty cool, but how optimized can you really make a physics engine in managed C#? Even unmanaged C# is no match for C++, and especially no match for assembly, which is what a lot of physics engines are made from.

What do you plan to do that makes this work and different from the rest?

11

Will this also work on mobiles now that they not only have one but two or quad cores?

12

Its not about what im planning to make this “work” since its already working like a charm for both, collision and range detection with the performance I stated in my first post.

What makes it different from all the others? Its fully implemented into Unity, not to replace unity physics (which it btw can) but aswell to go along it so you can use both engines simultanous depending on need. Though, you would want to use EnhancedPhysics most of the time since its absolutly more performant then unitys PhysX implementation. However, from what I saw so far, not even Bullet wrappers can archive the performance of this system. Thats aswell due how most modern physics engines work, they use world lists of objects and compare all their AABB’s for intersection. However, thats not really performance friendly at all. This system implements one of the newest strategies called the hierarchical hash grid. I implemented it dedicated for unity and pure collision/trigger detection with detector based triggers etc etc to enable highend culling and reduce acctual needed processing to a minimum.
Furthermore, the bottleneck is NOT the physics itself. A proper system like this can speed it up a few notches, thats for sure. But the real bottleneck is the unity internal movement processing which will drastically reduce your FPS. So this system aswell implements methods to fully batch and load balance movement calls to unity, getting rid of update loops and so on.
Anyways, the power aswell comes from extensive multithreading which moves all the real costy physics operations to other threads/cores and therefore gives the mainthread more air to breath.

I was aswell kinda surprised when I first benchmarked the system but yes, its true, even c# can get as fast as stated above. You just have to push the right buttons.

However, its already fast as a breeze. Though, I aswell already planned on providing a c++ dll in further releases to target pro users. This is of course currently not a priority since I want to provide this system to everyone.

Sure, I dont see a reason why it shouldnt. :wink:

13

Woah! Question, can I use this for my own standalone mono c# server or must it be used with Unity? I current have BEPUPhysics running on my game servers, and integrated it into Unity for CSP, but what you have sounds more promising. This is a must have for me if I can integrate it with my server engine.

14

Just a question, did you ever considered using unity for your game servers? Theres alot of nice frameworks out there to realize proper and especially fast network communication and overall server/db handling. I can only suggest using uLink from MuchDifferent, im using it myself. The benefit is definitly the ability to use all the awesome stuff that comes with unity. :wink:

Now to your question.
My framework will be provided in a dll. Easy reason, most fields are internally exposed via the internal keyword. In simple code I would have to make them public and possibly having users mess up their version with it. Btw, why making them “internal”, easily to avoid costy getter/setter and methods. You unfortunatly cant always rely on inlining. :confused:
Integrating it in a standalone version shouldnt be as hard. Though, I myself would need to rewrite parts of the framework and decouple it from unitys classes for you. This acctually only means replacing stuff like Vector3, coroutines, position-handling, start and awake. But yea, you unfortunatly wont be able to do it yourself. :confused:

15

I have, and Unity is nicer for mmos, but not for instance based games such as MOBAs or FPS where you need a lot of separate game server instances. Each Unity game server instance has a lot of overhead, even when running without graphics. There may be clever things that can be done by using the same game server, and split network groups into virtual game server instances, but I’d imagine the management of doing it that way would be a nightmare.

That’s too bad that your plugin doesn’t work out of the box standalone, if you ever decide to get it working for standalone game servers, I’ll give it a whirl in a heartbeat(or if I work on an mmo that uses physics)

16

That sounds awesome :slight_smile: The performance sounds superb.

Can I use your physics system for say units, and then use Unity’s mesh colliders on a couple buildings? So use both in the same scene?

Secondly, is your physics/math deterministic?

Thank you.

17

You could do that but this physics system is currently not supporting mesh collider collision. See my post above for further reference.
Though, this framework lets you chose between internal collision (for primitves which it will calculate itself) or on the other side with unity colliders which get turned on when a collider comes in range. With the later method, you would be able to use mesh colliders, though this could possibly get a bottleneck for you if done on to many objects. In most cases you can replace stuff with primitives and that should always be the goal to get rid of meshcolliders which are rather costy.

Deterministic? Yes it will and should always behave the same. :wink:

18

Yeah. It sounds pretty great, the only problem I see for our game, as Vincenzo already explained above, is that we can not use any mesh colliders.
Usually not a problem, we are not using mesh colliders anywhere unless really needed, but setting up our destructible Buildings with primitives is going to be a pain.

I guess you know what we mean, but for better visualization, I made a quick drawing in Paint.
Red is the primitive collider that would fit the most, black is the actual model of the destroyed brick wall piece.

Now, that is obviously not feasible, at all. So one could set them up like the yellow colliders.
But that would be a pain. Some of our larger buildings consist out of hundreds of those pieces, and setting them up by hand would not be feasible.

Then again, We would only need mesh colliders for bullet hit calculations, which we are currently doing with raycasting, so we could maybe make that independent from your System? As you said before, using mesh colliders for bullet stuff, and using your primitive colliders for player - building collision.

19

That would be the way to go since you can fully combine unity physics and EnhancedPhysics physics at once. That infact means you could set up your meshcollider on collision layer A, so only bullets can hit it while PhysicsObjects driven by EnhancedPhysics react to a primitive collider of layer B. The static primitive collider could be a unity Box, Sphere or Capsule collider.

Just as a little note, EnhancedPhysics uses the unity collider primitives for static object collisions.
As another thing to note is, that you can aswell set up a EnhancedPhysics driven PhysicsObject to respond to MeshColliders. This works by specifing that object to use a unity internal collider. This means unity will do every collision detection again instead of EnhancedPhysics. Furthermore, that unity collider wouldnt be always active, but gets enabled/disabled by EnhancedPhysics to increase performance.
You can aswell fully change the behaviour on runtime on your needs. Its as simple as calling a method to switch from unity collision to EnhancedPhysics collision and vice versa. :wink:

20

Any news about when it will be released?