Verlet Physics Engine for flash

[ozmic66]

Verlet based physics engine have been done and overdone, but mostly in c/c++/blitz3d? based applications.

I have only seen one fully working flash verlet based physics engine out there called the flade engine which has some impressive features and runs considerably fast (on flash that is)

I have also seen traces of the NinjaEngine (which seems to have been discontinued)

The problem is that although flade is pretty simple to use, it lacks documentation, which is the most important part of any engine...

More technically, it also lacks features like particle-dynamic line collisions...

So i've set out to start my own verlet based engine built specifically for flash.
so far I have the basic integration described in Jacobsen’s article "Advanced Character Physics" (if you haven't read it yet... read it here

Here are some examples I put together… all built with my engine

A ragdoll/hangman type example

A gish type jello cube (sorta)…

a simple particle/constraint editor for hours of fun:


So please tell me what you think of my idea… a full/free/open source (easily implemented) physics engine for flash with documentation and tutorials, which will definitely help non-physics savvy flash game designers to produce some cool games in the future…

So if you like the idea and are interested in helping please post here or email me at oz@fileitup.com

peace.

[OpethRockr55]

YES!!! Finally someone to chat Verlet with!

I think that this would be really cool idea for those who want to implement physics and have it be easily customizeable. Great idea.

The farthest I have ever gotten were ragdolls (I've attempted boxes, but they get the shakes), and I've learnt just about everything for those and I would love to implement a decent collision detection system for it.

Yes... I would love to be a part of this.

[ozmic66]

hey, great seeing some interest in this

As you can see i have the constraints working pretty well and my next step is collision detection and response

here's what i have so far:

spring constraints (with infinite stiffness)... i haven't really needed springy constraints yet since the whole system is pretty springy by itself

I also have what i called rope constraints which is simply a spring mith a minimum and maximum value so that it can limit the distance between two points (that's what i used in the ragdoll to keep the head from swinging all over the place and to keep the legs from crossing)

Now here's what i want to have: (hopefully)

particle-particle collisions - or circle-circle (which i pretty much figured out but haven't implemented yet)

i thought about raycasting for this but it might be 2 slow...have to make it and see..

particle-line collisions... here u probably have to use raycasting but it gets a little tricky with dynamic lines

Another dilema i've been having is whether i should use velocity or not...
when there's no collision reaction it doesn't really matter, but it might help for figuring out the future velocities....tell me what u think

So this is pretty much what i've had in mind, and i think great u wanna help out with this.

Hope we make this work

[OpethRockr55]

I hope we can, too.

The particle-particle would be a either a spherical collision or an AABB collision, so those would go hand in hand, in a sense. The Particle-line collisions, I would think, might be easier than a tile system. You wouldn't have to use raycasting, but rather you would need the equation of the line drawn (so a dynamically drawn line is the only way to go). Then, you would have to find a good function to figure out the penetration distance of that line. That would require an inequallity to figure out which side of the line to actually look at.

As for velocity- In addition to the Jakobsen article, I also did a little reading on "Verlet Integration and Constraints in a Six Degree of Freedom
Rigid Body Physics Simulation" by Rick Baltman and Ron Radeztsky Jr. who used a heavily modified Jakobsen method, which included velocity. They state in the article that velocity was used to introduce a damping term and to make collision detection much simpler. We could do the same thing with the original verlet code with a little modification (actually, I have already done it).

As for raycasting... do you mean to test for collisions or just have raycasting for user implementation?

[ozmic66]

Hello again

I really think that particle-particle collisions should work with bounding circles rather than bounding boxes, but we could also allow for either one and leave it up to the user

As with the particle, line collisions i pretty much figured the detection and reaction part... so here's what i've come up with so far:

I would find the equation of a line representing the velocity of the particle and find where it crosses the surface line... i simply use y=mx+b and simul. solve for the equations of both lines

then i check if the point lies on both lines and i'm done

next I do some dot product stuff for projecting the particle's velocity onto the surface and find the final velocity

Right now this works pretty well in theory (I'll upload some experiments i did with it) but there is some rounding error at small velocities which makes the particle go through the surface (but it's not really a major problem)

so using all this, finding out the penetration length is a piece of cake.


When i first read jakobsen's article i skimmed most of it and never really saw the 'no velocity' part so i built my whole engine with velocities

then when i re-read it i changed my code to have no velocity and i really found no difference in performance or ease of use...so if you say that velocity would be better for collisions then we should go with that

[NoSkills]

awesome stuff!
would it be possible to support nonflat grounds like stairs for example?

please release this as open source

[OpethRockr55]

I think we should go velocity-less. That we wouldn't have to make serious changes to our systems. I also have my code with no velocity.

If the rounding system isn't clearly noticeable, then I wouldn't worry about it.

I would love to see those experiments as well. I really think that it would be easier for particle-line because it easier to implement things with irregular curves.

As for your question NoSkills: We are going to try and code a way so that stairs (or bubbles, walls, ledges, etc.) could be rounded, square, starlike, anything the user would like and have it be used with ease. However, it's probably going to take a while with only two people. *wink* *wink*

[jonmack]

Welcome to FK, ozmic66.

First of all, nice demo's. It's always nice to see this kind of stuff in flash.

What I don't quite understand are these comments:

The problem is that although flade is pretty simple to use, it lacks documentation, which is the most important part of any engine...

More technically, it also lacks features like particle-dynamic line collisions...

The whole point of free software is that if it lacks something, you can contribute and help the project. If it is lacking documentation, and you have the right knowledge, why don't you offer to help out with the Flade project?

I guess I just don't see the point in re-doing everything someone else has done so you can add the features you want, when you could just build upon what has already been done. If this is more of a learning exercise for yourself, then fair enough - getting grips with the fundamentals is an important thing. But if your goal is to produce a fully stable package for others to use, then you'd probably be best to try and start with as much as possible.

Anyway, different opinions aside, I wish you guys the best of luck with this project. Get some sources out, a website or whatever, and I'll definitely keep an eye on it for the future. I too have done the odd verlet experiments over the years, but never anything useful. I'd offer to help outright, but I'm a bit busy at the moment, otherwise I'd love to have a real go at this stuff.

[ozmic66]

Hey, just posting a small example as promised....

Link

now this is an old experiment but it's a pretty good visual...

it lacks the whole penetration and friction element, which i have in other small experiments i have to find, and it also lacks collsion with the endpoints of the line...(same case as above)...but i don't think it's that cpu expensive (and its also frame independent)

Just to reply to what was said above,

Jon i have to say that you make a great point - i was actually wondering when someone would bring that up...

Flade is a good engine, and i will be pretty happy when mine is at the same level, but when i posted here i had the intentions of having an engine started from scratch.

I'm not exactly a physics expert, but i love learning about it and trying to simulate it, and this is really about learning how to make a physics simulator - and making it work

Perhaps i shouldnt have said that the reason is simply because flade is lacking some things.
it really is something i aspire to make myself, so i posted here so that i could join with other other people who like physics (and flash) as much as i do and make something really cool and useful - and what's a better motivation that making an engine that game developers will actually use

well, that's my spiel... and i hope that perhaps one day i, and everyone who wants to join this little project can get together with the people who made flade (or any other physics engine) and really make something great but right now what i want is to be able to work all the small things (like collisions) for the sake of knowing it myself.

Thank you for the interest jon, and i will gladly post any links i find usefull!

maybe if this thing catches on we could even start a website for it, and maybe even a 'flash physics community'....it all really depends on ppl's interest

so for now, we'll take it one step at a time and see what happens

[ozmic66]

hey, just found a pretty cool thread on this forum which linked to this

it was created by a user on this forum (Frag )
thread

this whole thing got me thinking about what approach we want to take here...

we could take the simpler approach of simply checking collisions based on current positions of particles (like what frag did above) - this works very nicely accept when the objects move quickly and pass through eachother

which leads to the other approach of first testing if the velocity of the particle will lead it to any sort of intersection in the next point by checking if the velocity line crosses any other surfaces or circles (like my prev. example)

So do we go for speed or percision (or perhaps a mix of both?)
maybe we could leave the choice up to the user and implement both in the engine...

Just thought we should get this fundamental decision out of the way...i'm leaning towards trying the simple one first and taking it from there.

So that's all for now...tell me what you think (i'm really open to suggestions here)

[OpethRockr55]

Huh... guess I didn't read that Baltman-Radeztsky article paper well enough.

Velocity would make things soooo much more precise. But I think your right about taking things slow. Once we develop both methods, we could simply choose one of the two to go with (or find a way to meld both as you stated above).

Nice example, too.

[ozmic66]

I think we should stay with no velocity...keep it nice and simple
after all we're more about speed here than exact, percise collisions

I've actually made a whole lot of progress in the last few days...

I managed to get circle-cirlce and circle-line collision to work..and it's very stable

(I'll post some examples in a bit..right now we can actually make something like the java example i linked to in my last post)

but the one problem is that at higher speeds the particles go right through eachother..and right through other lines so perhaps sweep tests would come in handy

(I'll explain exactly what i did in my next post, and i'll try to make some cool examples)

[ozmic66]

Alright, an example

link

click the mouse to add a circle...
arrow keyes
try pressing control...
..maybe shift?
...alt if you are brave

(try making a pool of balls and throwing some sticks in... loads of fun )

you may flood the screen but dont expect high frame rates (this code isn't that efficient anyway)

btw - this movie runs at 3 iterations per frame

i haven't gotten line-line collisions as they are kinda tricky...

so this is what i have gotten to so far, and am starting to think of sweep tests, what's your take on this?

sorry about the missing explenation..it's kinda late, i'll check back 2moro

[d3s_inc]

cool stuff guys...
did not read through all your posts, too much reading for me,
but yeah, your stuff looks very similar to my own endevours.... a couple months ago...
I even have a few demos around on me blog
http://www.d3s.net/?p=17
and http://www.d3s.net/?p=6

Line v line collisions are the hard part
Though I have my environment set up for tile-based games...