Verlet Integration Demo

[Jake]

I decided to make a 2D demo with Verlet integration in METAL before I actually implement it into my 3D Game, and boy was it easy! Well actually learning the tutorial was challenging, but easier than 3D collision detection, and you really didn't need to know that much advanced math (just a little calculus to understand WHY it works).

Here is a little demo I wrote, its uncommented and unoptimized (there is a nice way to get rid of sqrt but I haven't added it because its just a demo). The code and an executable with a data file are included.

http://nuclearnova.com/temp/Jakes Verlet Demo.sit

It only took like an hour to get it working, and they physics act exactly like they should. Tell me what you think.

[Sohta]

Nice job!

For those who haven't tried it, it's not just verlet integration, but also the whole constraints mecanism, as described by Thomas Jabcobson in a nice article ... somewhere :blush: ( can't recall )

Edit: Hum... I just saw Jake's thread in the GL forum, so... yep, that's the article I was talking about :p

[Jake]

Here is the article that explains it http://www.gamasutra.com/resource_guide/20030121/jacobson_01.shtml , it requires free registration but if you hit the stop button in safari before it loads all the way you can get in :).

For anyone looking into this, it is FAST! The only thing slowing down the demo is METAL, but I think it was worth it considering I did that in under an hour, and I didn't optimize at all, right now every ball collision is checked with every other ball (no square root though)

[Sohta]

I have some nice physics planned for my Udg entry that is based on the same principle and I must agree that this works really well if you can tolerate the small inaccuracys involved

[Jake]

I wonder how it would work for a Pool game, is its accurate enough? It was talking about the more times you call the function the faster it is, with 15 balls you could easily call it 200+ times per second without a noticeable speed hit. What do you think sohta? That could be a good 1 week shareware game for someone new to 3D :)

[Jake]

I just updated it a little bit, same download, now you control a big string of 10 balls that is fixed at one point and attached to your mouse. It works really good at slow speeds, especially watching the hex roll down its hill, but if you move it to fast it skips over stuff, but we are in metal here at some really slow FPS.

[Sohta]

Hum... yes... but I think that those maths are a bit overkill for a pool game. Good-ol newtonian physics could do the job faster here. In pool, you have only sphere-sphere and sphere-line collisions.

This system is best used ( I think ) for systems where the particles are linked together ( characters, bikes, ropes, stuff like that... ).

However, Yes!, a pool game would be a good simple 3D game for someone starting OpenGL ( IMHO ).

[skyhawk]

I just updated it a little bit, same download, now you control a big string of 10 balls that is fixed at one point and attached to your mouse. It works really good at slow speeds, especially watching the hex roll down its hill, but if you move it to fast it skips over stuff, but we are in metal here at some really slow FPS.
solid 102 FPS on this MirrorDoor G4

[Jake]

Oh, by slow I meant relatively, 100 FPS is pretty good for 2000 collisions each frame

[DM6]

real nice. i use this method too and it works great provided you're willing to put up with the loss of accuracy. don't think a pool game would be the most fitting application for this technique.

[SOUR-Monkey]

That's really cool. I read parts of that article a while ago, but got lost in the maths and sort of forgot about it.

What about things like sprite rotation? Not rotating a sprite, but determining rotation velocitys and so forth for collisions. Does SPK or Jake's code handle this?

[tod_baudais]

Here's the logical extension to the technique:

http://www.gdconf.com/archives/2004/baltman_rick.pdf

I coded it up over the weekend and it works really well. There seems to be a few errors in the document though.

Tod.

[Skorche]

I'll have to read over that, It seems to answer some things that I've been looking into. I'll have to brush up on quaternions though. ish.

Sour Monkey. No, neither this or SPK handle rotation of single particles. (yet ) ;), but you can trick it into doing it by making a box and stretching your sprite onto the corners. It probably won't quite behave like you want though. It's also pretty pointless unless you're using openGL.

[SOUR-Monkey]

Sour Monkey. No, neither this or SPK handle rotation of single particles. (yet ) ;), but you can trick it into doing it by making a box and stretching your sprite onto the corners. It probably won't quite behave like you want though. It's also pretty pointless unless you're using openGL.
No, I didn't think they did. I would think that as far as rotation went, the method you describe could be done convincingly, but it would need many particles. The line segments joining particles don't respond to collisions themselves, do they? At least not in Jake's demo they didn't, which would have the unfortunate side-effect of letting the cube fall through where the particles weren't supporting it (ie. on a cliff).

Well, it is an interesting subject anyway. Just the kind of thing to reinforce my nerdiness with :P

[Jake]

Correct, the lines do not have collisions, but it wouldn't be that hard to implement. Currently I am adding this to my uDevGame (3D racing) and it is almost done except when you hit the ground your bike goes flying into the air... I think I have a fix though

[aarku]

The line segments joining particles don't respond to collisions themselves, do they?

Yep they do in SPK. As far as I know, there currently are circles, line segments joining the circles, and terrain (array of heights) that SPK can collide.

-Jon