[WIP] 2d rigid body physics engine

[Alluvian]

Wow, that "show quad tree" option on that demo is trippy. Not a clue what is it doing, but it is trippy.

Certainly a big speed boost over brute force. I always wonder about why the registration of all these arrays is so fast. To my pea-sized brain I would think a lot of speed would be lost in the effort it takes to calculate which regions it is in, and then add/remove it from the proper regions each frame.

I guess that is why it is making 5% of the hitTests, but only just over tripling the speed.

[Sir Davey]

It's nice, but a friend of mine made the same thing, except it runs at about 60 fps.

I'll give you his contact info if you want to get in touch with him.

[Alluvian]

The demo there was not meant to compare it to other collision engines, just to compare it to brute force for this exact example.

I have my doubts that your friend used an identically shaped grid, on an identically sized stage, with an identical scollable canvas size, with identical number of objects moving on an identical number of planes.

ANY and ALL of those variables would change performance. So saying XYZ engine is faster than that is pretty hard to say unless they are performing absolutely identical tasks in an identical environment. I assume your friends engine is 60 fps in a browser of course?

[Sir Davey]

The demo there was not meant to compare it to other collision engines, just to compare it to brute force for this exact example.

I have my doubts that your friend used an identically shaped grid, on an identically sized stage, with an identical scollable canvas size, with identical number of objects moving on an identical number of planes.

ANY and ALL of those variables would change performance. So saying XYZ engine is faster than that is pretty hard to say unless they are performing absolutely identical tasks in an identical environment. I assume your friends engine is 60 fps in a browser of course?

I was talking about the physics engine. I don't think he uses any "regular" collision detection techniques for his engine.

I didn't test his engine in the browser but I doubt it'd go under 20-25 fps. It's pretty amazing to see.

[newblack]

i have a friend that can drink upside-down! lulz

like i've said about 4 times now in reference to performance there is nothing going on to make this run fast; and in most cases for the sake of application design, routines are purposefully un-optimized.

regardless, i'd love to see the same thing running at 60 fps... pls put me in touch! my wager is that it's not REALLY the same.

[Sir Davey]

Jesus do you guys get offended easily.

I just wanted to tell you this so maybe my friend could share his optimization techniques with you, I wasn't trying to say yours sucks.

[Alluvian]

Comparing physics engines is almost always apples to oranges anyway.

They may LOOK the same, but the key to using them in an application is how they function under the hood. Optimizations are usually shortcuts and assumptions. So the engines are usually optimized for a given use, being used in a different application, those assumptions and shortcuts may not work anymore.

Bottom line is that a faster engine is not a better engine. It is a combination of features (like colision dectection, one method may work for one game while being inappropriate for the next), speed, and ease of implementation.

As far as browsers go, putting your swf in a browser can have a 50% performance hit pretty easily if you are not using the latest beta flash player. The game I am working on for instance drops from about 40 fps to about 20 by just putting the swf in a browser. The latest beta flash player plays it fine, but on the older players I am losing half my fps.


As far as getting offended, I am nowhere near offended. I just think it is pretty uninformed to walk into a thread like this, without even reading about what his engine is doing and say "My buddies engine is the same thing but better!"

I have yet to see two physics engines that are the 'same thing'. If they were all the 'same thing' there would only be one physics engine out there.

[Sir Davey]

Comparing physics engines is almost always apples to oranges anyway.

They may LOOK the same, but the key to using them in an application is how they function under the hood. Optimizations are usually shortcuts and assumptions. So the engines are usually optimized for a given use, being used in a different application, those assumptions and shortcuts may not work anymore.

I'm pretty from what I've read in this thread, that the idea behind both this engine and my friend's are the same: easy creation of a world, weighted object, elastics, etc. He can also create new bodies "on the fly", pull objects with the mouse in the same way (creating an elastic from that object to the mouse). To me, and I'm sure to you if you see it, you will not notice any difference (aside from the graphic part of it)

As far as browsers go, putting your swf in a browser can have a 50% performance hit pretty easily if you are not using the latest beta flash player. The game I am working on for instance drops from about 40 fps to about 20 by just putting the swf in a browser. The latest beta flash player plays it fine, but on the older players I am losing half my fps.

I know about performance drops in the browser, I'm a flash developper as well. The point is that flash games are, as far as I'm concerned, made to be played in the browser. I don't know about your computer, but this engine (while it's an amazing engine) runs too slow on mine to be of any practical uses in a game.

As far as getting offended, I am nowhere near offended. I just think it is pretty uninformed to walk into a thread like this, without even reading about what his engine is doing and say "My buddies engine is the same thing but better!"

You're assuming I didn't read the thread. I did, and though it might not have looked like it from my post, I did see all the previous examples posted in this very thread.

Just because I'm newly registered here doesn't mean I'm a newbie on the internet, or any forum for that matter.

I have yet to see two physics engines that are the 'same thing'. If they were all the 'same thing' there would only be one physics engine out there.

I don't see why there would only be one physics engine out if they were "all the same". Unless I'm mistaken, the laws of physics are the same everywhere on the planet (even the universe, but I don't count that as a group of people make Flash engines). That doesn't stop people from making their own and thus having a different engine from someone else-while still abiding to the same laws.

[newblack]

I really wasn't offended- I was just trying to be funny...

And I had mentioned before that there were a bunch of reasons why performance specifically had not been addressed yet.

[jasonpeinko]

so hows this project going, have not herd from you in a while.

[newblack]

unfortunately i haven't made much progress- i rewrote the engine which was necessary to handle some of the constraint stuff i've been playing with. the goal is to find a global constraint solution rather than letting all constraints/collisions fight against each other and it's not easy stuff so it's got me held up atm.

to give you an idea of the structural change(s) being made-
beforehand the simulation loop looked like:
1. integrate with respect to time
2. resolve collisions on a pairwise basis
3. repeat 1 & 2 a set number of iterations

it's now:
1. detect collisions
2. create contact constraints from contact points
3. accumulate forces
4. globally solve for constraints
5. integrate with respect to time

[newblack]

i also keep a blog here: http://blog.generalrelativity.org
i'll be posting my progress there in a more granular way as well as other stuff that may be interesting if you're into physics and teh maths

[Viza]

Black, after checking out your blog it's quite apparent that you know far too much mathematics for your own good

Viza

[rachil0]

I was also wondering where this had gone. I saw a small game on another gamedev website that I think would be a brilliant application for your engine, called "crayon physics". Truly addictive, and I think you could imitate and improve upon it with more primitives (elastics and more rigid body shapes). Here's a link to it:

http://www.kloonigames.com/blog/games/crayon/

[jasonpeinko]

know what would be amazing? A blob class.

[Alluvian]

@rachil0: Crayon physics has a lot of potential as an idea, they really need to marry that to some more complex shapes. For instance, marrying that concept to the convex wrapper algorith that you posted the other day could do some really cool things.

Maybe have different colors of crayons draw different materials. Red for rubber, gray for steel, brown for wood... Straight lines would be platforms, enclosed shapes would be solid objects. Maybe add yellow for rope or something as well to make suspension designs.

Not sure what a good objective would be... Possibly something like armadillo run.

[rachil0]

Never played armadillo run - but a lemmings-like game, where you have to build a physical system to safely transport lemmings from one point to another, could work too. Really, I think that's exactly what Crayon physics is ... it's just that there's only one lemming to worry about and it's completely docile. Having lemming-to-lemming physical interaction, and giving it a (slight) will of it's own would be the real changes from Crayon physics.

I like colors = materials.

As far as a blob primitive is concerned, the engine is pretty much there - just connect masses and springs to make the hull and interior structure of the blob. Then smoothly spline together the vertices on the outside of the blob somehow and render it as one cohesive blobbygon (TM) , and I think you've got it covered.