rigid body physics
Community Forums/Showcase/rigid body physics
| ||
| test the rigid body engine i'm working on... http://www.kotiposti.net/naama/rigid.zip what kind of fps do you get? thanks. |
| ||
| Very cool, full framerate at all times (87 which is the max). You are not using Blitz' collision system are you? Is it 2D only or does it work in full 3D? To everyone else trying this: Arrows - Moves the snake E/D - Enable/Disable gravity Great work! Fredborg |
| ||
| wow, it looks really realistic. very fast and smooth. I get 51 fps on default start with 800 x600 and 43 fps with full 200 objects. |
| ||
| Very nice! I get the same as Fredor. I'd really like to know how you make the objects stack so nicely. I would very much appriciate it,if you would share a few pointers on how you do it. |
| ||
| again same as Fredor, good stuff :) |
| ||
| I get the same as Fredor also, great stuff, will you be releasing it as a lib? |
| ||
| 120 fps in 1024x768 windowed 200 objects. Excellent work! 2.53GHz, Radeon 9700 Pro, 512MB DDR333, XP Pro SP1, DX9 |
| ||
| Collision engine is currently 2d, but it's very easy to modify to 3d. It's just one axis more. Collide objects are basicly restricted particles which are connected with springs. Same size 3D mesh is then attached to the collision model and rotated accordingly. For example the box is made of 5 points (circles). 1 in every corner and one in the middle. That is the collide model for a box. It's not perfect because the edges are actually round, but looks realistic enough. So it really just does circle to circle collisions. Using this technique you can make any kind of objects you wish and they act very realistically. This method is faster and more stable than the more heavier and accurate rigid body simulations. In particle physics the engine uses verlet integration instead of euler's method. The verlet integration is more stable and the system doesn't explode. Also collision response is handled by projection of points. You only have to change position and the verlet integration updates the velocities. If you don't know what the hell i'm talking about ;) read about rigid body physics and ecspecially check out the article of Thomas Jakobsen about Advanced Character Physics. It's somewhere around the web. |
| ||
| By the way CopperCircle, I checked out the island storm screenshots and I must say they look stunning. Also I'm very impressed about the techincal specs and the fact that your using ode to create real physics. Can't wait to see the demo. |
| ||
| Very nice Naama. Any chance of selling this at some point? Very nice indeed. |
| ||
| Nifty. I got 60FPS with 200 objects, which is what my monitor runs at. Dr Derek Doctors did something very similar using verlet integration BTW, but in his case it was spheres only (well, that and some very cool interactions with rigid lines) which was very helpful to me when trying to nut out this kind of stuff (thanks again, Graham!) Clever idea using the multiple spheres, and that. How about objects with an off-kilter centre of gravity? Putting them in would be cool. Can you get the crates to act like crate instead of being all springy? |
| ||
| Hmm. Sometime ago I tried the exact same thing in 3d , and failed. I used 9 pivots, parented to the cube, and Blitz collisions. It resulted in this feature request: http://www.blitzbasic.com/bbs/posts.php?topic=16026 |
| ||
| Peter helped me out too. Thanks Peter! Sorry you couldn't help yourself :o( |
| ||
| I used the same paper to implement verlet integration in my Thrust Deluxe game. It's ace. |
| ||
| Every point in an object has own mass, so adjusting the point masses creates off-kilter center of gravity. I still have lot's of things to be done with the engine. First I need to rewrite the hole thing to get it into more understandable and faster form. I'll be back... |
| ||
| neat! |
| ||
| Brilliant! Runs at full pelt at 1024x768 |
| ||
| I use a very similar system for my 2D platformer I'm working on. Can you stack your boxes up properly without them falling over at the slightest movement with your program? Only that's a problem I always have when I use circle to circle collision, because as soon as they aren't *perfectly* stacked, they just slide off of each other. |
| ||
| Impressive physics demo. Runs full steam with 200 objects. It's just like playing in one of those funfair things which are full of plastic balls ,-, |
| ||
| Dr Derek Doctors: No... that's the problem with circle to circle collision. As for boxes one solution (not so good one) is to add more points to the collision model. For example every side of the box is made of four points, so instead of 5 points in a model, there's 13 points. Another option is to use large enough friction in the x - axis to prevent sliding when there's not much movement. The best way would be not to use circle to circle collisions, but to use circle to line collisions. So basicly comparing the points of source object to the lines connecting all the points in a destination object. But that's alot slower, so there you have to decide speed vs. realism. That is a big issue since only in my engine demo there can be 200 boxes and they are made of 5 points each. So you have to check for 200*200 = 40 000 collision to find out which boxes overlap. And if they do you have to check all the points in both objects for each other eg. 5*5 = 25. So in the worst case scenario (all the boxes are in the same coordinates overlapping - which would actually cause a huge explosion ;) ) you have to check 200*200*5*5 = 1 000 000 circle to circle collisions. So optimizing the collision checks is the main thing when building a rigid body simulation. |
| ||
| Oh excellent! |
| ||
| Yeah, I suspected that the only way to do it properly is line collision and that would be a bit slow so I'll not bother I think. As for the amount of check you're doing, you might want to put in place an optimisation which I use which uses up a chunk of memory (depending on the size of your gameworld which is active at any time) but which'll HUGELY cut down the number of checks you're doing. Try creating an array (or bank, like I did) which basically represents the world as a load of X unit by X unit bins. Then every frame you dump the ids of each particle into the appropriate bin and then you go through the particles as usual but you only check for overlaps with particles either in that bin and the neighbouring 8 bins (ie, up-left, up, up-right, left, right, down-left, down and down-right). When you're dealing with large amounts of objects you'll find that you can get a huge performance gain. |
| ||
| Works great! I'd be a bit concerned about simply taking the 2D math and using it for 3D, however - in a simple 3D engine that I was writing recently, for example, I found that I could not simply use combinations of 2D rotations to rotate objects properly in 3D. Perhaps the same principles won't apply here, though. |
| ||
| this is supercool man! will you release the sourcecode in the future? |
| ||
| I'd like to see your "square" logic model, Naama. I've knocked together a similar physics system using verlets and springs, and my "square" seems to require 10 internal springs to keep from acting really wacky (four corner-to-corner, four corner-to-center, and two cross springs). All these calculations just to hold the squares together slow things down a bit, of course. Also, I've never been able to make the square-root approximation from the Gamasutra page work. Luckily, I've tested BB's Sqr() function to be amazingly fast. My version isn't as fast as Naama's, but I can get a steady 75 FPS out of ~30 bouncing squares. If Naama doesn't release his version first, I'll pop mine up later today. |
| ||
| Yes. A lot of springs is required to keep complex forms collapsing. That cannot be avoided. If you have 5 points you need 4+3+2+1 springs and so on... But that is not the slow part of this kind of physics engine. Calculating springs is fast. Collide handling is the area what you want to optimize. I use many kind of tricks to lower the amount of collision checks needed. In my engine the drawing is starting to be the most time consuming part, which is good, because I know my engine can't be much more faster. But you can allways optimize the collisions and calculations more ;) God I want the Inline ASM ,like back in the old Amiga days. That would REALLY speed things up. Because a lot of variable handling really slows things up in this kind of engines where you need tens of thousands of checks. |
| ||
| hmm.. verlet.. calculus.. out of my league :) |
   |