# Physics Engine For PlayCanvas

So I’ve decided to bite the bullet ( ) and try to build a complete physics system for PlayCanvas. There are basically three types of help I need:

• Review and input to the requirements
• Development and mathematical support
• Testing of the iterations

I’d be delighted if anyone would like to pitch in.

At present my theory is basically this:

## In Use

• Simple physics with fast resolution
• Not an “engineering grade” simulation - but one that looks ok
• No object penetration at the expense of incorrect conservation of energy and one frame partial loss of velocity
• Imperfect friction and sliding in stacks of non-sleeping bodies
• Support for Capsule/Box/Sphere and Convex mesh - no possibility of any support for concave meshes without dividing objects into multiple convex shapes
• Spring joints, ball joints, rods (without breaking strengths in the first releases)
• No support for joint motors in the first releases
• Basic isotropic friction (not directional) and simple restitution

## Technical

• Use Speculative Collisions - (this basically means things never collide and get penetration resolved, rather they just touch - this has an effect of bleeding a little energy during a physics step, but is faster to do and generally more stable). The technique used is call Conservative Advancement and supports rotational collisions.
• Use sequential impulses - this is way faster than the other choice (using a technique called LCP to resolve all collisions at once by root solving) - but provides less realistic interactions. Non-sleeping bodies might slide unrealistically when stacked for instance.
• I intend to do contact categorisation via GJK and closest point resolution to identify 6 possible types of contact and code special cases for them (vertex/vertex, vertex/edge, vertex/face,edge/edge (non parallel),edge/face,face/face) excluding the special case of edge to edge perfect collision.

# What I need from you

• How do you want to use physics in games? What game styles are you looking for?
• How do you want to move your entities in the physics world? Forces? Kinematics?
• Mathematical support if you know one end of a Jacobian root solver from another then I definitely need your help
• Testing stuff when it comes available - might need to test and build specific code for different cases.
• Help in developing test cases
• Help in coding/debugging - once I have the basic structure

Let’s say goodbye to Ammo and build something fast enough for our games!

4 Likes

Nice! Personally I would love if we had a javascript physics library instead of Ammo even though Ammo is very powerful. I mean OK the best thing would be for Ammo to run really smoothly everywhere then we wouldn’t have to change anything.

Some things I believe would be important, is to be able to create compound shapes / colliders. Also some way to make vehicles as we’ve done various demos with vehicles before.

Other than that I’ll help however I can

Yeah agreed on Ammo - Bullet is bloody amazing when you get into it and is bound to be the source of a huge amount of what is built. I am going to diverge from their LCP approach to solving forces and will use Conservative Advancement for all objects (they just use it for high speed items). I think I have a working theory that combines the best of bullet with some other stuff and it “could” be really fast/good. Though of course I might be disappearing down a blind alley others have explored

I looked at Oimo - but no collision detection and i hate the way it does its contact patch resolution. In fact my working theory seems to be different to most other people’s versions of contact patches - so I’m waiting for the big gotcha that sends me scurrying off back to the traditional approach!

• Compound colliders - yep definitely got to be in there. Was thinking of doing this with fixed rod joints.
• Good point on vehicles - I played with the Unity wheel thingy a bit - but I’m no expert on writing things using wheel collider physics - so yeah - better “keep me honest” on that one.

I like the sound of this. I also hope it weighs in at less than the 1.5mb that ammo.js does. It’s about 1/3 the size of my entire project.
However, one decision really limits it’s usefulness and that is … “no possibility of any support for concave meshes without dividing objects into multiple convex shapes”

I have built levels before, both out of BSP (only convex shapes) and using traditional mesh-based, and I can tell you which is easier to use: mesh-based. Take for instance the room around you. It’s concave because it’s a room. To make a cube room from convex geometry takes six cubes instead of one. And most game levels are interior, or at least have interior parts.
Also consider this level:

It took two hours for a friend of mine to whip up this mesh. It would take another four to do BSP/convex-only geometry to match it.

From a technical standpoint, yes, convex only is simpler to implement, but the level designers and users will kill you. I don’t mind if it doesn’t support mesh-to-mesh collisions, but it should at least support sphere to mesh. In theory you only need one to be a primitive to resolve the direction of ‘out’ to resolve penetration.

All the other choices (speed over accuracy) I think is fine. Fun and performance over accuracy any day in my mind.

How do you use physics in games?
To make it real enough the player can associate with it. A player expects that if you drop an object, it will hit the floor. A player expects they will not be able to walk through walls.
In most games, there are maybe 4 types of physics ‘objects.’ The first is the player. Often a cylinder in FPS’s, a sphere in my game, sometimes ragdolls etc. Next is the level. I often represent this is a single physics mesh at relatively low poly count Somtimes multiple if moving parts (eg doors) are required. Third are enemies. Normally the same representation as a player. Finally there are pickups. These are often modeled as spheres.
And that is how I use physics in-game. To make the interactions between these four classes of objects believable enough for players to be able to figure out the environment they are in.

How do you want to move your entities in the physics world? Forces? Kinematics
Both. Some things have set velocities, like bullets. Simulating that with forces would be a right pain. Other things you need to apply forces, such as the modion of a space-ship, or torques on wheels. TBH, the difference is very minor, one simply has mass and is applied iteratively.
The way I would implement is is two methods :
applyForce(force_vector)
setVelocity(velocity_vector)
(actually four, repeated again for angular).

To fully constrain a system you need to be able to control position, velocity and acceleration. Position is self explanitory as is velocity. Acceleration is linked to mass and often applying force is more intuitive to a user who understands physics. Forces are real, accelerations are mathermatical artefacts.

Mathermatical Support
Sorry, I’m not up to date on physics engines, but I know my way around math, linear algebra, calculas and control theory. It’s been a couple years since I last wrote any heavy math programs though. If you want to bounce ideas at me, I can listen and offer advice, but I don’t have the time or inclination at the moment to actually write a physics engine.

I know how useful it is to explain issues to another guy while you’re working, and I’m happy to be the other guy.

Developing Test cases
This I can do.

Help in coding and debugging
Once the engine reaches a state which it can be tested, if it supports concave meshes, and it it is smaller/lighter/faster than ammo, I will leap on board and be happy to file bug-reports, find problems and maybe write a few lines. Or at least I’ll give it a shot every month or two and give feedback.

Hmm. I suspect I’ll be helping out in another physics engine in a year or two, so it probably isn’t a bad idea to get my feet wet…

Did you consider Oimo or Cannon.JS ?

I used to use BabylonJS before switching to PlayCanvas and they basically had the same debate going around at some point, They were also using AmmoJS if I’m not mistaken and urgently wanted to get rid of it as it was just ported to JS rather then written specifically for it.
They ended up using both of the above, that is the user can switch between the two for that both have their advantages. I belive Oimo became the new standard physics engine used in BabylonJS

We were thinking to make a physics components generic enough, that they will still work even if there is no physics engine plugged in.
Then you could add physics engine of choice and do a “bridge” library that will glue playcanvas physics component system with physics engine of choice. This would allow to use any physics engines that has bridge library available, or even write one yourself.

@sdfgeoff Well I don’t think we can get enough performance out of Javascript to handle concave objects - the algorithms and assumptions for the collision detection are all way too big if you can’t assume convex (plus most of the algorithms for collision detection that are fast just don’t work). However, this isn’t necessarily a problem as you can divide down a concave object into multiple convex ones - just it’s a different algorithm - we could certainly consider doing that.

The free Collision Detection library I’ve released handles stopping object penetration and super fast cases for pickups etc. This will be the basis of the physics library detection - with the added stuff about swept volumes to detect the chance of collision.

I’d be delighted to work with you as “the maths guy” - my high school calculus is stretched at times - mostly the reading of the damn formulae.

@dinkelborg yes I considered both of those. I don’t like how oimo works - especially the fact it doesn’t really have the right structure for collisions, the way it creates contact patches etc. Cannon is ok. But I guess I got to the point of really wanting it to work differently - which is what lead me to writing Collision Detection as a good way of building most of the games I need. Collision Detection has lead to thinking about physics and making me feel there’s a good way to go about this.

@max - yeah not a bad plan! Would be good to have a choice - the way that collision components are updated at the moment is part of the problem with Ammo integration with PlayCanvas. A very large amount of time is spent syncing things and iterating for…in style over components with super long guid keys (even if they are disabled). I built Collision detection to use the existing colliders - but they could also do with properly gizmoing and supporting scaling of the parents.

Some other things off the top of my head that would be nice to have:

• Ray casting with support for layers / masks (to be able to ignore hits with certain objects)
• Sphere casting
• Triggers

There was something else too but I’m forgetting what it is at the moment

So this is all based off CD as a starting point.

Sphere casts: CD’s raycaster for meshes uses a GJK approach, I just have to do it for the other colliders and we get Sphere casts for “free”. Unity has swept capsules too - that might be interesting. CD handles layers more generically by having an “exclusion object name list” and a predicate function so you can do what you like to ignore things. Already got triggers in CD.

Thanks whydoidoit, this is definitely interesting enterprise, I’ll be following your progress.

I think it’s important to take a look at a bigger picture and consider really typical use cases. First of all, PlayCanvas at its current form is intended for small to medium sized projects - small games, 3d multimedia, product demos, web archviz, etc. By the end of 2016 I think it will have enough magic to power medium sized MMOs, especially considering their upcoming lightmapper (edit: already released!), new scripting solution and enhanced collaboration. Compared to Unity WebGL, PlayCanvas offers “web first” approach, quicker iteration cycles, collaborative editor (distributed teams), and much less overhead when it comes to small web projects. I think PC team will keep building on these strengths, while closing the gaps in other areas (like already mentioned lighmapper and such).

So what are typical physics uses cases for such projects?

1. Ray casting with layers and mask was already mentioned. But what would be really nice is at least its partial independence from scene complexity and the number of colliders in the scene. Ray casting is probably the most casually used feature in PC physics, since it’s usually directly tied to input - you click things, drag things, etc. Also, if we could do a ray cast directly against world geometry, that would be great. Let it be expensive, but sometimes it can be useful.

2. Also general independence of collision detection from scene complexity, at least when it comes to a number of static colliders. That would help to build medium sized world chunks without extra pain of managing trigger zones, etc.

3. Collision primitives are a huge area for optimization. Making them to work as fast as possible is essential. Also, consider adding a simple plane with width and height as a primitive. And also a disc. In lots of cases assembling collision wireframe from planes and discs is relatively faster compared to cubes and spheres.

4. Continuous collision detection - not a big item for me, but action games would benefit from it tremendously.

5. Switching an object from dynamic to static state should be beneficial for performance. Also, if we could have hundreds of sleeping objects without affecting performance, that would be awesome.

6. Particles. Let’s build a simplified point collider (zero radius) with low precision when it comes to collision resolving, but which could be simulated in thousands without affecting the performance. Let it ignore world colliders and only collide with a special type of colliders like particle-specific cubes, spheres and planes, for maximum performance.

1 Like

Yeah, and also compound dynamic bodies are really lacking in the current state of things. Forgot to mention them, until got stuck with a project that requires them!