hiho, basically box2d-jquery is a jquery wrapper around box2dweb, it's quite simple to use

  $("#some_element").box2d({'y-velocity':10});

it was fun to code, basically it

  * creates absolute positioned clones of your selected elements https://gist.github.com/4051578 
  * and animates them usind CSS3 transforms / translate / rotate
  * the values are calculated using box2dweb

i created it as i sponsor a javascript/jquery conference in my hometown (we need more dev-conferences here) and wanted to create something cool.

please fork it on github (zlib license) https://github.com/franzenzenhofer/box2d-jquery

update: more examples linked from github Readme.md

Very cool! I created a small bookmarklet that injects it into the system we're developing over here. It's nice to amaze some colleagues real quick. ;)

    javascript:(function(){var%20s=document.createElement('script');s.setAttribute('src','https://raw.github.com/franzenzenhofer/box2d-jquery/master/js/lib/jquery.box2d.min.js');document.getElementsByTagName('body')[0].appendChild(s);window.setTimeout(function(){$("#main-nav,header").box2d({'y-velocity':5,'x-velocity':-0.05,'debug':false});},500);})();

Note: if you copy this in the omnibox of chrome, you will need to re-add "javascript:" in front of it.

Edit: And a working bookmarklet for HN that also injects jquery.

    javascript:(function(){var%20s=document.createElement('script');s.setAttribute('src','//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js');document.getElementsByTagName('body')[0].appendChild(s);s=document.createElement('script');s.setAttribute('src','https://raw.github.com/franzenzenhofer/box2d-jquery/master/js/lib/jquery.box2d.min.js');document.getElementsByTagName('body')[0].appendChild(s);window.setTimeout(function(){$("td:first()").box2d({'y-velocity':5,'x-velocity':-0.05,'debug':false});},500);})();

cool, here is on for the HN frontpage with a little bit more action (selects every <a> element)

    javascript:(function(){var%20s=document.createElement('script');s.setAttribute('src','//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js');document.getElementsByTagName('body')[0].appendChild(s);s=document.createElement('script');s.setAttribute('src','https://raw.github.com/franzenzenhofer/box2d-jquery/master/js/lib/jquery.box2d.min.js');document.getElementsByTagName('body')[0].appendChild(s);window.setTimeout(function(){$("a").box2d({'y-velocity':5});},500);})();

Oh my god, I will troll my colleagues with this so hard. I'll add this to our website cms for their IP only and watch them panic "Why is our website falling apart?"...

Brilliant idea! I just created a JIRA ticket for this unusual issue we seem to be having with the tiles on the landing pages. Let's see what happens...

Awesome!

Very nice! Though the API of Box2d is a little bit hairy, i really appreciate how stable it is. We built a DOM-based game/ad-thingee with Box2d this spring (http://embassy.de/game/) and using a game + physics engine (CAAT was the game engine) and relative measures was also a pretty good way to make it scale across window sizes!

Does this have collision events? So if A hits B is there a way of knowing?

it's on the todo list, it will work with custom DOM event events.

The future is here. Kiss your boring, practical webpages goodbye. ;)

Forgive me if I am wrong, but shouldn't a true physics engine not behave exactly the same way every time? I refreshed 5 times and every time the word Hey ended up vertical against the word GitHub. I would expect the interactions between colliding objects to vary every reload.

I tried 4 times, but on my machine (Firefox on Linux) I get the exact same result every time, up to the last pixel.

In theory you would expect a physics engine to always behave exactly the same every time (as long as there are no random forces in the simulation, obviously). In practice, I can think of some ways that would influence the result. For example, x86 can use extended (80-bit) precision for intermediate floating point calculations internally, but will always store them as 64 bit in registers or memory. Depending on the timing of thread context switches, you can imagine subtle roundoff errors caused by going from extended precision to double precision. When using SSE math you get similar effects but even more pronounced, because SSE is not always fully IEEE compliant.

Usually the introduced error is infinitely small and most algorithms are robust enough to cancel it out. Stuff like non-linear regression or a physics simulation are notable exceptions, because the calculations they do are iterative and progressive, meaning any introduced error can propagate and get amplified along the way. I've seen deterministic non-linear fit algorithms go in completely different directions for unstable problems on different machines, just because of CPU differences (64-bit vs 32-bit, x86 vs. sparc, etc).

Great explanation, thank you. Always fun to know about non-determinism at the hardware level.

>> Always fun to know about non-determinism at the hardware level.

Strictly speaking, the non-determinism isn't actually in the hardware, because the OS schedules thread context switches ;-)

Assuming the CPU is running a completely single-threaded program or uses a deterministic way to schedule thread context switches, the result should always be perfectly identical.

Why would you have that as a requirement? Output shouldn't vary unless input does. Real world physics only vary because input conditions are never the same.

It's my impression that it's always easier to add randomness to such an engine. So if you have a deterministic engine you can always sprinkle on some randomness afterwards if you want it more interesting.

But I'm not very experienced in physics engines so I might be on thin ground.

>Real world physics only vary because input conditions are never the same.

Not exactly. Classical physics is a deterministic approximation of quantum physics at macro scales. In reality, outcomes vary even if the initial conditions are the same (although you may need special equipment to observe that there is any difference. You can choose to call all of the quantum events "inputs" but that's dodging the point.

That said, most applications would not benefit from simulating at a quantum level, and doing so at large scales is currently intractable. So while real world physics is not deterministic, macro scale physics engines should be.

nope, a true physics engine behaves the same time, always - if there are no outside forces. if you kick stuff around (use your mouse of fingers on touch devices) == outside force -> different outcome

this 2d world has no intrinsic random/chaotic forces (i.e. no wind) so everything behaves the same, always, forever. if you want your world to be more random you could write something like this (during the world initiation phase a.k.a. the first box2d-jquery call)

  $("h1, code, .box2d").box2d({'y-velocity':5, 'x-velocity':Math.random()}

However, different binaries may generally yield slightly different results due to compilers ordering floating-point operations differently, for example.

like schrödingers cat for physics engines? but with the difference as long as it is the same box, the outcome is always the same?

That is what physics engines tend to aim for. Some even guarantee portably stable results.

What happens to the Heisenberg principle ??? :P

Given identical initial conditions on every reload, I would expect the same thing to happen every time.

Wow very nice. I want to read what it says but I have a hard time keeping the whole thing still! I have some wicked ideas for this.

next version will include collision detection (when to elements colide some custom DOM event will be thrown), so we can start to implement simple (to complex) game logic into the DOM as well.

That would be incredible. When do we think it will be able to do that?

depends on the pull-requests and bug-reports that will hopefully start now (i want this code battle hardend for production use), they will take precedence over new features, but latest january / feb.

This is great, but it seems a little slower than the raw box2d. Is it doing anything else on each animation loop?

mostly a lot of looping and setting CSS, see https://github.com/franzenzenhofer/box2d-jquery/blob/master/... but yes, performance profiling is the next step, also i wonder if position top / position left is faster than transform+translate... any support is welcome

Somebody please make a bookmarklet out of this.

There's something similar for Google search — http://mrdoob.com/projects/chromeexperiments/google_gravity/

A quick and dirty one that only affects h1, divs and imgs (based off the example on the github page):

javascript:(function(){document.body.appendChild(document.createElement('script')).src='https://raw.github.com/gist/4257861/bf99710923dc4512338a9f19...;

The code can be found here: https://gist.github.com/4257861

divs are an issue, because divs commonly include other divs commonly include other divs commonly include other divs ....

jquery-box2d does not animate the DOM of the webpage you see, it animates clones of the elements of the website you see, so basically you create and animated clones of elements that have animated elements of clones of elements and so on... this is probably solvable (everything is), hopefully it will be solved by somebody who is more in love with the DOM than i am

In most sites those three are enough to crash the tab/browser.

that's exactly the first thought that strike my mind.

currently there is a performance overhead to animate deeply nested HTML elements. so we would basically need a sizzle selector that applies to every HTML page that only selects "not deeply nested" nodes. so ":not(:has())" filters will be needed.

I was trying to do this but it seems like the implementation haves a little bug: https://github.com/franzenzenhofer/box2d-jquery/issues/1

thx, all bug-reports are welcome and will be fixed and tested a.s.a.p.

I don't know how this is useful, but I want to use it!

So slow on my browser.

Back to native applications coding.