Hi HN. I recently open sourced a verlet physics engine that I wrote for fun. Four example experiments are in there so far. I have a few other experiment ideas in mind that I hope to get implemented soon. Anyways, it was a blast creating this and thought others might like to look/play with it too.
Looks great, thanks for sharing. One thing I would suggest is to not worry about rendering the physics on the canvas, threejs is good at what it does and lacks a good physics engine. It's just my opinion, but I think the project would benefit from either making it work with threejs or by not solving the render problem, and just focus on doing great physics, so that people can use the results in their threejs scenes.
This is a really great point. Abstracting it away shouldn't be bad, and it is possible to extend by vec2 implementation to 3d. After I finish my next batch of examples I will venture down this path.
This is one of the few demos I can try on Linux without jumping through hoops since it's canvas-based, so I appreciate your choice to not go with WebGL actually. Looks good; looking forward to reading the code more closely!
There is a physics engine for threejs- it's somewhere on their demo page. I'm actually working on a physics engine as well- I'm willing to help you extend it in whatever direction.
A question, Why did you chose Verlet integration? I know it's great for particles but I always had issues trying to do angular mechanics.
Are you thinking of Physijs [0], which is made to work well with ThreeJS? Its a wrapper around Ammojs for ThreeJS.
It does look good and integrates well, but to be honest ThreeJS is so mature and battle tested with multiple renderers (canvas, webgl etc) that when building a physics engine, I really think it would be better to spend ones dev time on the physics and not waste* time reimplementing a portion of ThreeJS.
Great question- I was reading about verlet integration and started doing some coding to play with it, and I just kept on going with it. Would love some help with it! First thing I would like to do is abstract out canvas.
There seems to be some numerical instability in the rotation. In the shapes demo, several of the shapes start spinning faster and faster when I pick them up. Particularly when I press the outside edge nodes into the center so that the shape sort of flips inside out, after that the shape just spins continuously when it is in the air.
Another way to exhibit it is to take the center node of the wheel and press it against the wall. The whole shape will spin.
I wrote a verlet based physics engine years ago and had similar issues. Relaxing distance constraints tended to add a bit of angular momentum in to the system. Sometimes having a drag term in the integrator was enough to compensate, but this appears to be in verlet.js already.
Another issue with defining shapes via distance constraints is that they sometimes have alternate solutions / stable minima. For example, you can smash the circle in to the ground and get it to crumple: http://i.imgur.com/UzxbKvJ.png
But, this is still an awesome demo. Good work subprotocol.
Comments
Hi HN. I recently open sourced a verlet physics engine that I wrote for fun. Four example experiments are in there so far. I have a few other experiment ideas in mind that I hope to get implemented soon. Anyways, it was a blast creating this and thought others might like to look/play with it too.
Cheers
Looks great, thanks for sharing. One thing I would suggest is to not worry about rendering the physics on the canvas, threejs is good at what it does and lacks a good physics engine. It's just my opinion, but I think the project would benefit from either making it work with threejs or by not solving the render problem, and just focus on doing great physics, so that people can use the results in their threejs scenes.
Great work though
This is a really great point. Abstracting it away shouldn't be bad, and it is possible to extend by vec2 implementation to 3d. After I finish my next batch of examples I will venture down this path.
Thank you for the feedback!
This is one of the few demos I can try on Linux without jumping through hoops since it's canvas-based, so I appreciate your choice to not go with WebGL actually. Looks good; looking forward to reading the code more closely!
If you use Chrome/Chromium, you can try setting the "Override software rendering list" option in about:flags. Worked for me.
There is a physics engine for threejs- it's somewhere on their demo page. I'm actually working on a physics engine as well- I'm willing to help you extend it in whatever direction.
A question, Why did you chose Verlet integration? I know it's great for particles but I always had issues trying to do angular mechanics.
Are you thinking of Physijs [0], which is made to work well with ThreeJS? Its a wrapper around Ammojs for ThreeJS.
It does look good and integrates well, but to be honest ThreeJS is so mature and battle tested with multiple renderers (canvas, webgl etc) that when building a physics engine, I really think it would be better to spend ones dev time on the physics and not waste* time reimplementing a portion of ThreeJS.
[0]: http://chandlerprall.github.io/Physijs/
*Obviously not actually 'wasted' time, hacking is great even just for the sake of it - but I'm sure you know what I mean.
Great question- I was reading about verlet integration and started doing some coding to play with it, and I just kept on going with it. Would love some help with it! First thing I would like to do is abstract out canvas.
There seems to be some numerical instability in the rotation. In the shapes demo, several of the shapes start spinning faster and faster when I pick them up. Particularly when I press the outside edge nodes into the center so that the shape sort of flips inside out, after that the shape just spins continuously when it is in the air.
Another way to exhibit it is to take the center node of the wheel and press it against the wall. The whole shape will spin.
I wrote a verlet based physics engine years ago and had similar issues. Relaxing distance constraints tended to add a bit of angular momentum in to the system. Sometimes having a drag term in the integrator was enough to compensate, but this appears to be in verlet.js already.
Another issue with defining shapes via distance constraints is that they sometimes have alternate solutions / stable minima. For example, you can smash the circle in to the ground and get it to crumple: http://i.imgur.com/UzxbKvJ.png
But, this is still an awesome demo. Good work subprotocol.
Thank you for open sourcing this. The spider example is just awesome!! Good Job!