Matter.js – A 2D rigid body physics engine for the web

by brbcoding • 12 years ago

545 62 12 years ago

jastanton• 12 years ago

I've used this a lot in the past few weeks. It's really amazing. It has some trouble with triangles. But having a physics engine completely written in Javascript from the ground up using good JS principles is refreshing. One of the coolest features is mobile demo. Buttery smooth on my iPhone.

yummybear• 12 years ago

Impressive - on the face of it, it seems both versatile and stable.

swah• 12 years ago

This would have to start talking about the problems with previous attempts (box2d...)

dyarosla4• 12 years ago

Pros: The samples play well, look fun, and it looks like a great solution to small physics demos in JS. Great job!

Cons: Playing with the Stress demos (especially #2) really shows the slowdowns and downsides to using a JS based engine. At 450 boxes (+ 4 bounding walls), it runs at 20fps on my Macbook and thats with a lot of jitter and overlap. Not as fun.

Edit: Significantly better w/ WebGL render, @32fps, and with sleeping+WebGL render @34fps.

I wish I could see a physics engine using WebGL and GPU acceleration for the web. This one is a great start if the author were to take it further and implement some of the logic with shaders.

teamonkey• 12 years ago

How does it compare to, say, Box2D ported to JS using Emscripten?

http://kripken.github.io/box2d.js/webgl_demo/box2d.html

DanielRibeiro• 12 years ago

Good question. I also wonder how it compares to other popular 2D js physics engines:

p2.js: http://schteppe.github.io/p2.js/

PhysicsJS: http://wellcaffeinated.net/PhysicsJS/

maccard5• 12 years ago

Cons: Playing with the Stress demos (especially #2) really shows the slowdowns and downsides to using a JS based engine. At 450 boxes (+ 4 bounding walls), it runs at 20fps on my Macbook and thats with a lot of jitter and overlap. Not as fun.

Have you tried enabling sleeping? Even most AAA games don't actually have even remotely close to that number of bodies active in a game at once. Sure, the engines can handle it, but having a stack of bodies like the stress demos is the absolute worst case, as you normally have to resolve a chain of contacts, in this case a few hundred, iteratively. Most physics engines also benefit hugely from multithreading, something which JS doesn't provide.

I wish I could see a physics engine using WebGL and GPU acceleration for the web. This one is a great start if the author were to take it further and implement some of the logic with shaders.

That was tried on PC and consoles and most game developers are going back to using the CPU for physics calculation, and using the GPU for rendering. Using WebGL with this particular demo shouldn't increase the performance if the bottleneck is the physics simulation.

greggman• 12 years ago

This JS physics engine isn't multi-threaded but it does run the physics on a separate thread

http://chandlerprall.github.io/Physijs/

jsheard• 12 years ago

GPU acceleration isn't going to be practical until >WebGL2, when we get access to compute shaders.

You can technically do compute now by expressing your data as textures and performing rendering passes over it, but trying to do anything non-trivial that way will quickly lead to madness.

dyarosla4• 12 years ago

I mean, this is what I'm looking for. Sure it would be madness, but if you have 450 bodies represented by, say, 10 floats each (random number), that comes to about 4500 pixels of values- something a GPU is fine at.

TheSisb2• 12 years ago

Have you seen PixiJS? http://www.pixijs.com/ It's used by PhaserJS, a very promising JS Game Framework

tlarkworthy• 12 years ago

Pixi is the rendering engine used by Phaser. More relevant is the different physics engine Phaser supports (Box2D, P2 and its own lightweight arcade physics engine). Also Phaser is Typescript but distributed as JS. You can link it directly with Typescript too though which is why I like it a lot.

alexivanovs• 12 years ago

Very cool, love the variety of demos. :)

TehCorwiz2• 12 years ago

http://i.imgur.com/QcKoWLj.png

Doesn't seem to render correctly on Chrome 39. Works fine on latest Firefox.

jonlucc• 12 years ago

It looks ok on my Chrome 39.0.2171.99 m on Win7.

risq• 12 years ago

Same for me (chrome 39.0.2171.99, win 7) But it seems to work using webgl renderer !

Zitrax2• 12 years ago

Indeed, changing that makes it work for me too, using canvas is broken. ( In the settings to the right, Renderer -> renderer )

TehCorwiz2• 12 years ago

Replying to my own post to add details.

Windows 7 AMD HD 7970 3GB

girvo• 12 years ago

Worked perfectly at 60FPS on my 13" rMBP (Intel 5000, I think?) in the latest Safari, of all browsers! I was super impressed.

Zitrax2• 12 years ago

Does not seem to work good in Chrome or Opera for me, all movement leaves trails.

ceronman• 12 years ago

I wonder how it compares with P2.js. Another nice pure JavaScript 2D physics library. https://schteppe.github.io/p2.js/

meandave• 12 years ago

I spent a good deal of last week comparing these two for a side project. I found that while p2.js supports a bit more that I need (specifically compound objects) It was harder to get going since you have to handle your own rendering. Whereas matter.js has it's own swappable rendering engine.

azurelogic• 12 years ago

Pretty slick. I think I might be using this at Global Game Jam this weekend.

On a side note though, it seems that there are some issues if you get things moving fast enough. I was consistently able to fling shapes through the walls on the first demo.

elberto34• 12 years ago

How is the cloth demo done? Is it with partial differential equations

leeoniya• 12 years ago

another cloth using verlet integration:

http://subprotocol.com/system/cloth.html

repo: https://github.com/subprotocol/verlet-js

Mckey• 12 years ago

Physics and collision detection in JS. One can only imagine the horror.

ionwake• 12 years ago

lol

cmpb• 12 years ago

This person has produced some pretty incredible things with HTML/JS/CSS (including Matter.js).

http://brm.io/work/

jchomali• 12 years ago

This is amazing!

hamburglar• 12 years ago

There are some bugs with "enable sleeping" turned on. Occasionally an object that is sleeping seems to fail to have external forces act upon it. For example, you can end up with a sleeping object sitting on top of another object, and when the object falls out from under it, the sleeping object stays stuck in midair. I can reliably make this happen by toggling "enable sleeping" on and off (example: load up "wrecking ball", stop the wrecking ball before it hits the pile, turn on "enable sleeping", wait for all the blocks in the pile to go to sleep, then turn "enable sleeping" back off and you now have a stack of immovable blocks which the wrecking ball bounces off of, and which will hover if you remove the bricks below them), but I saw the bug occur even when I wasn't flipping this setting back and forth.

maccard5• 12 years ago

Enabling sleeping is a difficult thing to actually do, especially in a stack of bodies. You have to enforce a minimum movement threshold over a series of frames usually, and group bodies together to go to sleep, and also wake the same group up when there's motion. It's not always easy to do

hngiszmo3• 12 years ago

demo request:

I want a demo where the user can control a soft body ball such that the ball is comprised of chain segments, connected with string constant k. The pressure of the ball would be calculated depending on the area enclosed by the chain's polygon and would be applied to each segment equally, to the outwards side. Controls would be left/right as a simple added force to all segments of the ball. Jump would be increased air amount (target surface area) and crouch would be decreased k. In my imagination, the ball would be low friction and would grow throughout the game, to take on bigger adversaries.

(Sharing it here cause I didn't get to code it in years but I would really love to see if the control would work.)

chromakode• 12 years ago

Sounds like Gish! http://www.chroniclogic.com/gish.htm

hngiszmo3• 12 years ago

When I saw Gish for the first time, I thought the same but I bet they fake a lot of physics.

seanmcdirmid• 12 years ago

You probably want a soft body physics engine, not a rigid body one. Something that could use Verlet + pressure-based techniques, for example.

hngiszmo3• 12 years ago

Well, I was precisely interested if it could be modeled with a chain. Otherwise thank you for you pointers.

hrqbnvfjshark• 12 years ago

Maybe this is something like what you described: try the 'Blob Test' example from Box2D-html5

https://code.google.com/p/box2d-html5/

AceJohnny2• 12 years ago

I'm especially impressed by the time scaling. Back when I fiddled around with physics collision/physics libraries years ago (ODE), have a fixed timestep was a fundamental design decision and changing that led to weird and unpredictable behaviour.

Things have come quite a long way :)

Edit: still has problems with squishiness of stacked solid objects though :\

z3t42• 12 years ago

This is very impressive! The most advanced JS 2d rigid body physics engine to date! You can do a lot of optimization though, probably double the speed. Tip: V8 loves objects and hates parsing strings.

Your functional spaghetti style is a bit weird though. I hate using the "find in file" function in my editor. I wanted to "rip" some of the functionality, but it's so entangled I would probably need all your other functions too to make it work. But maybe that's intended :P

Many people, me included, would be willing to pay for an engine like this. I tried your "Game physics for beginners" but I'm too stupid to understand all the articles from math professors. I could probably learn, but I rather pay someone who understands.

But for me to use your engine, the API needs to be much easier! Something like this:

  var box1 = new Body(size, position);
  var world = new World({gravity: 9.8});
  world.add(box1);
  world.render();

  console.log('New position: ' + box1.position);

i_s• 12 years ago

It is more advanced than Box2D [0]? What makes you say that?

http://blog.sethladd.com/2011/09/box2d-javascript-example-wa...

z3t42• 12 years ago

Box2D is ported from C++ to Flash and then from ActionScript to JavaScript. So it might be slow to get updates and bug fixes.

But it looks usable and seems to have the same features as Matter.js

scotty792• 12 years ago

Why all those "physics engines" are so jittery? Are there no ways to solve such a system with perceptually exact accurancy in realtime?

Those kinds of approximations are the source of some of the most hilarious bugs in games over last deacade or so.

Please don't read this as a critique of this particular project which is pretty good at what it's trying to do.

I just wonder why AAA games use pretty much the same math? Are there no better math?

I mean CAD systems obviously do something better... Is that the same thing as with drawing triangles vs. raytracing?

JabavuAdams• 12 years ago

Stiff springs. Look it up.

Retra• 12 years ago

Animation is an illusion of motion caused by a sequence of still images. The way a physics engine works is by computing those still images -- the frames -- for each iteration in a mathematical model (the physics you want.)

If you want 60 frames per second for a smooth animation, you have to compute the whole frame less than 1/60th of a second. The more complicated your physics model is, the harder it is to do this.

I just wonder why AAA games use pretty much the same math? Are there no better math?

The math they use is just standard physics, often using some simplifications or optimizations to speed up the calculation. "Better math" is a curious term. If you want more accuracy, you have to give up speed. You can't have both. You either get jittery/jerky motion or you get unrealistic effects. Of course, running on a faster machine or finding a better optimization will help, but that also requires a ton of expertise and is sometimes plain infeasible.

I mean CAD systems obviously do something better... Is that the same thing as with drawing triangles vs. raytracing?

CAD systems with physics engines do the same thing as above, and they have to make the same kinds of decisions. Usually, CAD software is meant for design, so it would opt for higher precision. This isn't suitable for games except on very high-end machines, which would exclude a lot of people from buying your game.

As for ray tracing vs rasterization: Yes, it is the same kind of trade-off. Ray tracing can be made very accurate and do some amazing things, but the frame rate is usually so low that you have to pre-render the whole animation beforehand. That is, if you want high quality.

Rasterization gives medium-low quality at very high framerates. It is very common because it is 'good enough looking' for most purposes, where an equivalent quality ray tracer would be very slow. Of course, a physics engine is independent of your rendering method: you will have to compute physics for your scene whether you use ray tracing or rasterization, so you have to take both into account for determining how jittery your animation will look.

scotty792• 12 years ago

"Better math" is a curious term. If you want more accuracy, you have to give up speed.

What I mean is for example to integrate something numerically you can just add small increments but this will lead often to crap unstable solutions. Or you can use Runge-Kutta and get very accurate stable result.

gugagore• 12 years ago

The math is not just standard physics. That undermines the essences of the difficulties of doing physical simulations. Many of the design choices have to do with numerics, discretization of time, collision detection, etc.

Physics doesn't concern itself, for example, with how to represent polyhedral shapes, or how to compute their intersections. In the world of computer simulation, there are surely more algorithmic developments to be made. Even if the physics hasn't changed (much) for the last 300 years, there are new ways to precondition systems, and solve them, and so on. I think that's what is meant by "better math".

I think you make a good point about the trade-off difference between CAD and games. In addition to requiring that games be simulated in real-time, you also want the simulation to be causal. In a CAD tool, you can take advantage of being able to do "multiple passes" through time to refine your simulation. In a game, once you've computed the quantities pertinent to a frame, you don't get to go back and recompute those quantities and present them.

_random_• 12 years ago

Was it written from scratch or inspired by Box 2D?

zkhalique• 12 years ago

This is really impressive! Just a small bug report:

http://brm.io/matter-js-demo/#bridge somehow had some things fall through to the ground the first time in loaded.

nkg• 12 years ago

Fun!

madethemcry• 12 years ago

I am familiar with P2 JS, looked through PhysicsJS and the two very basic arcade engines grown within Phaser JS. Matter JS seems to have the exact same feature set like any other library. I haven't seen any 2D web engine, besides the JS ports of Box2D, which supports continuous collision detection (CCD), which would prevent a lot of tunneling, especially on slower mobile phones.

Why is that? CCD doesn't look more complex in theory than any other concept in a 2d physics engine.

P2JS: https://github.com/schteppe/p2.js PhysicsJS: http://wellcaffeinated.net/PhysicsJS/ Phaser: http://phaser.io/

tumultco• 12 years ago

When I was evaluating engines for Hype Pro's [1] physics system, I compared based on file size, commit/project activity, how easy it would be to modify and integrate, and the license (for obvious reasons). I looked at Matter.js, Verlet, PhysicsJS, p2.js, JPE, Newton, and box2d-js. While many have their respective strengths, overall Matter.js stood a notch above the rest. The code has been easy to work with and Liam has also been responsive in fixing bugs or accepting patches. It is truly a gem of a project.

[1] http://tumult.com/hype-pro/

xwintermutex• 12 years ago

Nice work. As someone who built physics engines years ago, it makes me kind of happy that solving stacking is still no trivial task.

xedarius• 12 years ago

Really nice, noticed a few jitter issues on the bridge example, that's possibly one of the hardest thing to do in a physics engine (that and fast moving objects).

ifdefdebug• 12 years ago

Very nice. But strange things happen in the "car" demo if you put one car on top of the other: they try to throw off each other like horses.

iamabhishek• 12 years ago

It looks simply great. The efforts put together for creating this library are commendable.

Matter.js – A 2D rigid body physics engine for the web

Related Stories