Verlet Max Polygon Physics

[NateTheGreat]

well I finally finished the polygon/softbody physics of verlet max, a physics engine I am writing. Right now I am adding fluid physics and a better rendering system. Here is a vid.

http://www.youtube.com/watch?v=tEGBqZdaee0

and more fractures!

http://www.youtube.com/watch?v=h-rnqCJa8Co&NR=1

and a more primitive version with soft bodies

http://www.youtube.com/watch?v=bnK9hl4WUEg

check out my channel for some fluid demos!

[NateTheGreat]

sorry it wont let me edit my post but my name used to be Nate The Great w/ spaces but I lost that email and password.

[h4tt3n]

Looks good :-)

Are you - as the name suggests - using implicit verlet springs, Jakobsen style?

Speaking of springs, how many are there in the fracturing block? There may be at least a few ways to improve speed for that one (it looks a bit laggy compared to the other sims). For instance, you could skip all the diagonal springs and throw in angular springs instead, they only require a single dot product and no square root.
It's also possible to make large bodies of connected springs without using square root. If you keep a separate spring rest length for each axis and rotate them to fit the body's local reference frame, you can have at least 20.000 to 25.000 springs running fluently on an older single core machine - without calling sqrt() a single time.

Cheers,
Mike

[NateTheGreat]

Are you - as the name suggests - using implicit verlet springs, Jakobsen style?
yep

Speaking of springs, how many are there in the fracturing block? There may be at least a few ways to improve speed for that one (it looks a bit laggy compared to the other sims). For instance, you could skip all the diagonal springs and throw in angular springs instead, they only require a single dot product and no square root.

how would I do angulare springs? it seems like those would take sin and cos calls... I wanted to implement them but they seem slow! The first vid is the most recent (and fastest) version. It doesnt look laggy to me but the other videos do for sure :p The first vid updates physics 20 times a frame at 60 fps so its going 1200 updates a second... thats not bad imo.

oh and there are 6 springs per block.


It's also possible to make large bodies of connected springs without using square root. If you keep a separate spring rest length for each axis and rotate them to fit the body's local reference frame, you can have at least 20.000 to 25.000 springs running fluently on an older single core machine - without calling sqrt() a single time.

how would I avoid sqrt? you lost me there... I am actually going to make it optional to use an array for sqrt() instead which is a lot faster than normal sqrt

[h4tt3n]

how would I do angulare springs? it seems like those would take sin and cos calls... I wanted to implement them but they seem slow!
No need for trig calls :-) The simple version: Consider two springs sharing a particle. The dot product of the two normalized length vectors is cosine to the angle between them. The 2d cross product is sine to the angle. If you want the two springs to stay at a right angle, apply a normal force to the endpoint masses proportional to cosine to the angle. If you want them to stay parallel, apply a normal force to the endpoint particles proportional to sine to the angle.

I wrote a tutorial on this a few years back: http://www.freebasic.net/forum/viewtopic.php?t=9769

Downloadable demos here:
http://www.jernmager.dk/stuff/cpp/soft_body_03.zip
http://www.jernmager.dk/stuff/cpp/softbody_glfw.zip

how would I avoid sqrt? you lost me there... I am actually going to make it optional to use an array for sqrt() instead which is a lot faster than normal sqrt
Consider a spring with rest length zero. The spring force along the x axis is: Fx = -k*Dx, where Fx is force along x axis, k is spring coefficient, and Dx is displacement along x axis. Similarly, the spring force along the y axis is: Fy = -k*Dy. Since the two forces are perpendicular, they do not influence each other. No need to call sqrt(). Fx only depends on Dx and is not influenced by Dy, and vice versa. Now consider a spring with rest length Rx along the x axis and Ry along y. The spring force is then: F = -k*(D-R), where all bold letters are vectors. Still no need for sqrt(), see? You only need square root if the spring can rotate freely, in which case you need to solve the Pythagorean theorem to find the spring's length and the normalised length vector.
If you have a body of hundreds or thousands of springs, all you need to do is keep track of the body's rotation, and then resolve the above type spring in the body's rotating frame of reference.

Downloadable demo here: http://www.gamedev.net/community/forums/topic.asp?topic_id=579582

Cheers,
Mike

[NateTheGreat]

ok I see what you are saying about angulare springs...

You only need square root if the spring can rotate freely, in which case you need to solve the Pythagorean theorem to find the spring's length and the normalised length vector.

um all of my springs can pretty much rotate freely... is there a problem with that?

[h4tt3n]

Well, it's not exactly a problem. It's more about trying to optimize your code by avoiding the sqrt() call. Besides, by implementing the methods I mentioned, you can simply do stuff that isn't possible with "regular" springs alone.

Cheers,
Mike

[NateTheGreat]

I think we had a miscommunication... what are you calling a freely rotating spring? I consider all those not static to be freely rotating. But you might be thinking of something different.

[h4tt3n]

Yes, I probably was a bit unclear about that. By a "free rotating spring" I simply mean a spring that can point in any direction. For instance, a spring between a static point and a particle, which pendulates back and forward. These need a normalised vector and hence a sqrt() call. The spring I mentioned above is not free rotating, since it has a fixed rest length along each axis. It can only point in one direction (which can be good or bad depending on what you need). This spring doesn't need a sqrt() call.

Cheers,
Mike

[NateTheGreat]

oh ok that makes much more sense. good suggestion. Non rotating springs, self colliding squishy objects and other physics body modifiers like keeping it at a certain angle for a platform game will be useful to implement sometime but for now I am working on implementing the core of the fluid physics. It will be nice to see fluid physics along with polygons and will put the engine a little ahead of farseer and box2d as far as real time particle fluids go unless those engines have gotten particle based fluids already.