I wrote something like this a couple years ago[1]. I also attempted to support ball-to-ball collisions. I rarely do any graphics type programming so this was a fun diversion.
However, the simulation would slow down considerably after adding a few dozen balls. This was largely due to the quadratic nature of my naive collision detection. In order to remedy the speed problems I implemented[2] a quadtree I found online to assist me in culling a lot of my expensive collision checks. The bounds of the quadtree sections will appear as you begin to add balls.
Unfortunately the quadtree wasn't the performance savior I expected it to be. I didn't notice a dramatic improvement in the number of balls I could support. I also introduced a bug with the quadtree version where certain collisions are missed entirely.
Perhaps I should revisit this simulation and see where I was off.
I know it is educational and it does not matter in presence of dissipation, but it would be nice to mention that Euler method is not only an approximation but also terribly inaccurate one. It won't produce any stable oscillations or orbits for instance.
I actually mentioned that in a comment lower on this page. I will be talking about ODE solvers a couple of articles from now. The Euler method isn't acceptable for actual simulation but it's the easiest to understand and it gets the job done for now!
I've messed around a bit with the Bullet physics library and was wondering if anyone knows how it works under the hood. It's not brute forcing the collisions, because it can handle thousands of objects.
Does anyone know how they do the approximation? There is a fudge factor you can set for say a 10% boundary around an object, where it's almost like it moves all of the objects and then takes a best guess where they should be placed for the next physics frame. But I'm curious what their approach is called, if it's a general solution.
Look into quadtrees, that's a good way to do collision detection in 2d. Or just partition your world into a fixed grid and only consider collisions with objects in the same grid square. Quadtrees are just a smarter way of doing that.
I recently did something somewhat physics related, implementing Kepler's laws of planetary motion in JS to produce a 3d simulation of the solar system: http://www.asterank.com/3d/ ...I plan to generalize it into an open source educational tool that allows people to build arbitrary space simulations on top of its physics engine.
Another interesting JS physics experiment that I found while looking into this stuff is this n-body gravity simulator: http://www.spacegoo.com/solar_system/
Very good article and very good explained. I have a hard time really getting physics but if my teachers would have explained it this way I might actually have had fun with it :)
Thanks! That's what this series is all about. Physics and math really are fun, you just need to figure out an application that excites you and also have someone teach it to you in a manner that keeps you engaged. That's what I'm trying to do here, so if you're interested you can sign up for the mailing list and I'll send you emails when new articles are posted!
You really want to play with physics/math with ECMA 262? O_O (hint JS knows nothing of integers)
Floats are way to slow (and faulty when div/mul are called) compared to int to do anything serious.
All 3D engines tricks are about doing complex math with integers (EDIT: or other tricks http://en.wikipedia.org/wiki/Fast_inverse_square_root#Overvi...)
[+] [-] Simucal|13 years ago|reply
However, the simulation would slow down considerably after adding a few dozen balls. This was largely due to the quadratic nature of my naive collision detection. In order to remedy the speed problems I implemented[2] a quadtree I found online to assist me in culling a lot of my expensive collision checks. The bounds of the quadtree sections will appear as you begin to add balls.
Unfortunately the quadtree wasn't the performance savior I expected it to be. I didn't notice a dramatic improvement in the number of balls I could support. I also introduced a bug with the quadtree version where certain collisions are missed entirely.
Perhaps I should revisit this simulation and see where I was off.
[1] - http://jsfiddle.net/simucal/RvA9w/33/
[2] - http://jsfiddle.net/simucal/RvA9w/
[+] [-] mrhyperpenguin|13 years ago|reply
[0] http://www.gamedev.net/page/resources/_/technical/game-progr...
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] mbq|13 years ago|reply
[+] [-] bkanber|13 years ago|reply
[+] [-] zackmorris|13 years ago|reply
Does anyone know how they do the approximation? There is a fudge factor you can set for say a 10% boundary around an object, where it's almost like it moves all of the objects and then takes a best guess where they should be placed for the next physics frame. But I'm curious what their approach is called, if it's a general solution.
[+] [-] bkanber|13 years ago|reply
[+] [-] typpo|13 years ago|reply
Another interesting JS physics experiment that I found while looking into this stuff is this n-body gravity simulator: http://www.spacegoo.com/solar_system/
[+] [-] bkanber|13 years ago|reply
If it will help at all feel free to poke through the source code!
[+] [-] mweibel|13 years ago|reply
[+] [-] bkanber|13 years ago|reply
[+] [-] hrabago|13 years ago|reply
[+] [-] bkanber|13 years ago|reply
[+] [-] akldfgj|13 years ago|reply
[+] [-] viraj_shah|13 years ago|reply
[+] [-] gbrindisi|13 years ago|reply
[+] [-] bkanber|13 years ago|reply
[+] [-] ObnoxiousJul|13 years ago|reply