Jitter physics engine vs built-in Physx

I'm trying to integrate Jitter Physics in Unity. There is no specific reason, just the curiosity. I spent a couple of hours yesterday and got box and sphere colliders working. Bricks could fall, balls could roll, the objects could collide with each other. It was a surprise actually, I wasn't expecting any results that soon.

Jitter has little to no documentation, so it's hard to see its pros and cons in comparison with PhysX. The differences I know at the moment:

1. Jitter supports multithreading, however it still seems to be a bit slower than PhysX.
2. Jitter has cone and cylinder colliders in addition to box, sphere and capsule ones.
3. Jitter seems to be able to check for intersection between a pair of arbitrary colliders. PhysX has CheckCapsule() and CheckSphere() methods only.
4. Jitter supports soft bodies.
5. Jitter is 100% managed.
6. Concave meshes can collide with each other in Jitter (however it is slow.)
7. Jitter is open source (and free for even commercial use.)
8. Jitter has no built-in character controller.
9. Jitter doesn't natively support kinematic bodies.
10. ..?

I wonder, does anyone have any experience with Jitter? What is it good at and what are its limitations? Do you expect any particular difficulties to use it inside Unity?

PS
https://bitbucket.org/alexzzzz/jitter-physics-for-unity

 

I created a set of components for Jitter's rigid body and collision shapes: box, sphere, capsule, cone, cylinder and mesh. Everything is fine so far.



Arbitrary mesh shapes can collide with each other in contrast to Physx, but such collisions are veeeeery sloooow.

 

Thank you for the link. I will finish the wrapper for Jitter physics and then create a common benchmark scene to test the performance of all three engines.

 

Standalone demo (18Mb): download

The torus uses convex hull collider, other objects use primitive colliders.
White horizontal lines show fps levels. The lowest line is 60 fps, the next one is 50 fps, then 40, 30 etc.

 

Has some big fps drop after 900, otherwise runs smoothly.

 

I have the same experience.

This demo uses PhysX: download
PhysX seems to be 1.5-2 times faster. The same fps drop happens at ~1300-1400 objects.

 

About same here. (although in physx the objects went through arena walls, so not all are visible)

 

you have a mac build?

 

I don't have a Mac, so can't build for it. And web player doesn't work at the moment, I don't know why yet. Jitter is 100% managed, it should work fine in the web.

 

Terrain colliders seem to function correctly. Now I'm working on raycasts.

 

I will smile when you get cloth sim working with this... great work so far...

 

I started to integrate soft bodies yesterday, but very soon realized that I would have to mess with mesh vertices. Not a big deal, but it would take time to do it properly. So, I decided first to implement terrain collider, compound shapes, constraints, joints and other basic stuff. PS: And reinvent character controller too.

I hope the performance of soft bodies will be acceptable.

 

Cool.

 

It turned out that a proper character controller implementation is a pretty tricky thing. Jitter has not built-in implementation. There are examples on its forum and I'm trying to improve one of them. It runs fine except it slows down at stairs and doesn't support moving platforms.

 

How about this tech for cloth http://www.gamasutra.com/view/feature/132771/the_secrets_of_cloth_simulation_in_.php ?
I think it would be pretty cool for character cloth and stable enough

 

Finally got webplayer working: current character controller progress

Q - drop a ball
E - throw a ball

 

I've had Jitter working in Unity for years And in my testing it works fine in both web-player and iOS (and by extension, likely every other platform).

Initially I used it to prototype a MMO with server-side physics that went no-where, these days it's in production thanks to the inbuilt support of capsules. Beyond that I enjoy the flexibility and power of the API - far beyond that of Unity's physics. On the downside of course it's not natively supported nor as matured/polished as the built-in systems.

 

It seems that web-player's Mono doesn't implement some method in ReadOnlyCollection<T> which recent versions of Jitter implicitly use (I took the latest one from the repository.) It causes an exception inside IslandManager's constructor. I changed ReadOnlyCollection<T> back to List<T> and now Jitter works again.

Have you used it on client side? Completely in background or just using its internal multi-threading?

PS
Compound objects support is almost done:

 

I've seen demos of Jitter running fully in background inside Unity. That way it doesn't affect fps at all, even if there are thousands of cubes on the scene. Looks impressive, however I expect a lot of synchronization issues:

1. The physics engine may update a body's position or orientation when a user reads or writes to it.

2. The physics engine has to buffer collision events somewhere until the main thread is ready to fetch them.

3. I have no idea how to implement synchronous raycasts since the world is constantly changing in background. Locking the physics calculations isn't the answer - raycasts will become very expensive, especially several ones in a row. But asynchronous raycasts will be a pain to use.

 

You can build for Mac on Windows also.

 

With the PhysX demo I was able to get to about 1400 objects before the graph started to spike a little bit.

With the Jitter demo I was getting spikes with the first few objects. The graph was definitely more irregular then PhysX.

 

Stress testing:

1. Jitter - webplayer
Jitter runs in background (only one background thread). Keys 1 and 2 turn rendering on and off.

2. The same but using PhysX - webplayer
It still uses Jitter for character controller, but everything else use PhysX.

 

Jitter - I was able to get about 1400 physics objects on screen before the FPS started to dip down into the mid 50s.
PhysX - Was able to squeeze out a bit more, 2200 physics objects, before the FPS dipped down into the same area as the previous test; the mid 50s.

Quite impressive, personally, for a library that isn't built into the core engine.

Specs:
2.8GHz/1.9GHz AMD Quad-Core A8-4500M
6GB DDR3 SDRAM
AMD Radeon HD 7640G

 

Hi Alexxxx I was wondering what your plans with the wrapper was. I am intersted in doing the exact thing, but do not want to do things double.

Also I was wondering, did you translate Vectors to JVectors or did you remove the jitter math library and replaced everything with unity classes?

-- Jan

 

I dropped the idea.

In single thread mode Jitter is way slower than PhysX. When using internal multi-threading, Jitter is a bit slower (or just not faster) than PhysX. In order to get a significant speed improvement, Jitter should work totally in background thread. But this mode is not natively supported and brings a lot of synchronization issues which you will have to deal with by yourself:

1. Adding/ removing a rigidbody to/from the scene.
2. Reading/writing positions and orientations.
3. Raycasting.
4. Collision events.
5. ...

For example, when physics runs in background, you no longer can just call AddRigidbody method whenever you like. You will have to put the new rigidbody to a synchronized queue and the physics engine will collect it when it's ready to do it.

In case of raycasts, you will have to keep a recent copy of all active rigibodies' positions and orientations and calculate raycasts using these copies, because the actual positions may change while you are raycasting.

I made helper conversion methods, like

Code (csharp):

1. public static class Vector3Extensions
2. {
3.     public static JVector ToJVector(this Vector3 vector)
4.     {
5.         return new JVector(vector.x, vector.y, vector.z);
6.     }
7. }

PS
I played for a while with BEPUphysics that is also a managed physics engine, but it natively supports both types of multi-threading. Maybe I did something wrong, but in my benchmarks PhysX was showing times better results than BEPU.

 

Yea I just tried the Bepu implementation in the forks and it's not good. I had about 350 boxes and the whole system started to jitter. I haven't tried Jitter yet since it requires more work, Bepu was ready to test.

I am looking for a solution where I would be able to simulate physics on a server, without a Unity instance running on it. This would require a much better physics implementation than the Bepu implementation ( I am not saying Bepu is slow, but the implementation I tried was for sure) that could handle running on a dedicated server for example.

Is this the same reason you were looking around for a "custom" physics implementation? If so, what were your findings? I don't think one implementation can match the other, meaning I cannot use PhysX in the game while running jitter on the server for example. The prediction etc would not match.

 

I was thinking about a new game mechanic that would use physics in a bit unusual way and I had some issues with PhysX because of that. I was curious, whether Jitter could help me to solve them. After a while I realized that Jitter in its current state would give me more problems than solutions and that it would require a lot of effort to make the work-flow as smooth with Jitter as it is with PhysX. At the same time I solved my issues with PhysX (it turned out they were mostly imaginary) and haven't touched Jitter ever since.

 

Hi Alexzzzz
would you like to share the code?

I have a tennis game released with another game engine, and I used jitter. I would like to port it into unity.

how do you rewrote the threadmanager class, in order to works on mobile too?

 

Ok. If the sources still exist (I believe they are) I'll publish them.

 

https://bitbucket.org/alexzzzz/jitter-physics-for-unity

I just didn't. I ignore mobiles.

 

Thank you

 

What are the advantages of Jitter vs PhysX?

 

Im using this and its really great! Bur for some reason my JCharacterController can freeze if i will move and jump on rough terrain. And if i try to debug PrepareForIteration and Iterate function on my characterController, i will not receive any update to this functions. Do you know where is problem Alex? (sry for my english.. im not good in that :x )

 

How to make it support kinematic bodys, any suggestion,thanks!

 

How do you use the JHingeJoints e.g. for a chain of balls?

 

Why project is abandoned?

 

Probably for personal reasons, since it was while, when OP created this thread.
Also, Physx supports now multi threading.

 

PhysX can’t be used on server side(

 

https://forum.unity.com/threads/jitter-physics-engine-vs-built-in-physx.186325/#post-1423112

• It just doesn't worth the effort. Too much work for no benefits.
• Jitter is far from being finished. It has bugs and lacks some functionality. I'm not competent to add functionality or fix bugs in physics engines.
• Jitter itself is abandoned (and already was in 2013). PhysX is constantly getting better and better.

 

I'm interested in this because of its potential to transform it into a fixed point, deterministic physics engine, but it does lack features (something I can live with) and has problems with raycasts, with false positives, and it looks like meshes have a skin width for some things but not for others.


Edit: I just discovered that TrueSync from Photon is Jitter Physics + FixedMath.Net

 

hi alexzzzz, i have built a vr jitter physics first person controller inside of unity with voxels using your jitter physics to unity migration, as a portefolio/suite/demos/series/tutorials that i am developping on unity 2017.4.40f1 that i wanted to share with you and the community. I thought maybe anyone who had a hard time understanding voxels and vr-ik just like i did, would find your work for the migration and my portefolio as a very basic helper solution, to start their own projects in vr with ik and voxels. (please note the movement isn't completely fixed yet and i will be working on it more very soon).

Thank you, for migrating jitter to unity because i know migrations are long and tedious work and i am not done either with the visual debugs onscreen (ongui) but i am sure it can easily be re-integrated by going over your code again.

download link - https://github.com/ninekorn/sccsvrunity-portefolio-draft-wip

my wip post is on the link below in a short description of my parkour in order to get to this point with my portefolio/suite/demos/series/tutorials https://wordpress.com/post/sccoresystems.wordpress.com/649