Physics Collapse!

I was just messing around after I saw the "liquid" demo... thinking to myself "That is a shite load of code to make something happen... why didn't he just use physics objects?".

So that's what I did.

Works great until you start to "fill" the bucket up (around 2500 objects or so should do it). Try and see what happens.... it collapses in on itself and crashes :/

linky: http://www.fileden.com/files/2007/8/21/ ... llapse.cap

~Sol

Changing the collison mask from bounding box to ellipse makes it work a lot better... however I am determined to break it again, so I made "right click to drop a heavy object" in the code there, and this large ball with more mass comes crashing through the smaller box objects sending them flying all over the place quite nicely. This is fine until, again, there are lots of ojects and it crashes.

I used the debug window and it gave me this error:

A crash inside a plugin's non-event code has been intercepted! This may be a bug in the plugin or a problem in Construct. The application has exited.

Plugin- Physics.csx

Object Name- movement_3_2

Instance ID- 0 (of 4)

Will see if I can make it work, then make it break again.

~Sol

It definitely shouldn't crash. But the important thing with a Physics engine is due to the limited precision of computers, and shortcuts taken for speed, there are boundaries on reasonable use and stability. If you use the physics engine in a manner which is realistic, it should be stable, but if you try colliding something with the mass of a planet in to something with the mass of a speck of dust, you can't expect a realistic result. Collapsing may be because you've hit some limit of the Box2D engine - it's probably not designed for such complex simulations.

i've had the physics crash a few times, too. if you end up with too many particles applying force toward one another, they'll eventually cave in and you get an error.

this also happens when 2 many objects are intersecting, and the cpu cant perform the resulting calculations, then it just lags out and freezes.

as you said ellipse helps fix this very well, as when you have a lot of objects,boxes tend to create very little spaces, like bricks, vs ellipse that when stacked still have space (like stacked tubes) that something can move into and fill, this is why a stack of tubes can roll off itself easily, but a stack of bircks cant.

imagine this stackability as, the harder it is for a shape to roll off itself, the harder it is on the cpu.

Nice analogy Quazi... makes perfect sense when you think of it like that. I kinda figured the same thing after I discovered it is more stable with spherical collision masks since there is less touching surface area.

The only reason I tried this was to see exactly how far I could push the physics in an applicable situation, since I am wanting to experiment in making a test application similar to "Armadillo Run". I think the amount of objects that can be used is more than satisfactory for such an idea, though it kind of caught be by surprise when it crashed like that. I just expected it to either run really slow, or start missing collisions (IE objects falling through the floor or each other), or both...

If it's fixable in any way then that would be awesome, but if it's not then that's ok as well... I can't really see the need for 3000+ tiny physics objects on the screen at one time! Well, maybe I can, but I could live without it lol.

~Sol

i think there should be a REALLY inacurate mode on colision finding, im not sure if his is possible, but sometimes you just want objects to know their colliding,but not do anything until they can, instead of affect objects alot, so that if the "tubes" intersect, its not at the high priority or even medium for them to move and push everything out of the way to make a space, only things which can easily move will move,but not have to be 2 percise about what theyre hitting or not, i think there should be an option for such a thing, like "dumb collision" finding. it would make fluid simulations (which i reallly need for a project) easier.

"dumb collision"

Yes, this would be awesome... this kind of collision could even allow physics objects to pass right through one another in order to find a "gap" to fit in to... this WOULD indeed make liquid dynamics using physics objects way easier and convincing to achieve.

~Sol

dumb collisions... it would make fluid simulations (which i reallly need for a project) easier.

I don't know how these "dumb collisions" would work, but yeah, fluid simulations seem like a remote possibility with the current physics system.

Click to drop a ball into the bucket... it stalls like crazy and this is only 400 objects.

http://www.fileshack.us/get_file.php?id ... =water.cap

Perhaps setting the water drops to "no collision" with everything but the walls of the bucket and manually coding a loop that simultaneously repels and attracts individual drops to one another would work (something like the gravity simulation going on in Help right now). You might be able to get them to spread out and fill a volume that way. As for making things float/sink and otherwise affect the flow of water you could code that behavior in with overlaps. Worth tinkering with anyway, because as it is now it the physics object is getting overwhelmed trying to calculate all those collisions at once.

Click to drop a ball into the bucket... it stalls like crazy and this is only 400 objects.

http://www.fileshack.us/get_file.php?id ... =water.cap

runs fine for me

runs fine for me

Well fine then mr. fancy computer pants

> runs fine for me

>

Well fine then mr. fancy computer pants

Computer... pants.... that would be freakin' AWESOME! I guess you would unzip the front to access the hard drive? Hmmm, it better come preinstalled with WinZip or something then... otherwise you'd be in trouble when you had to defrag.

~Sol

> runs fine for me

>

Well fine then mr. fancy computer pants

No, seriously. On a Pentium 4 3.06 GHz / Geforce 4 ti 4200 it runs between 65 and 80 fps even while dropping half a dozen beachballs simultaneously. Not blazing perhaps, but by "between 65 ..." I mean "never below 65 fps" (except while moving the runtime window; that takes it to ~50.)

>

> > runs fine for me

> >

>

> Well fine then mr. fancy computer pants

>

Computer... pants.... that would be freakin' AWESOME! I guess you would unzip the front to access the hard drive? Hmmm, it better come preinstalled with WinZip or something then... otherwise you'd be in trouble when you had to defrag.

~Sol

<img src="http://www.ohgizmo.com/wp-content/uploads/2008/04/keyboard-pants.jpg">

one step closer

>

> > runs fine for me

> >

>

> Well fine then mr. fancy computer pants

>

No, seriously. On a Pentium 4 3.06 GHz / Geforce 4 ti 4200 it runs between 65 and 80 fps even while dropping half a dozen beachballs simultaneously. Not blazing perhaps, but by "between 65 ..." I mean "never below 65 fps" (except while moving the runtime window; that takes it to ~50.)

Welp, you have more gigglehertz than me and I guess that's what matters with mathy collisionable stuff. Graphics card doesn't mean much when calculating physics thingers.

Try making more of those little water drop things and see how many you can make before it goes bonkers.

Anyway, if I drop the ball from really low so it hits softly it runs fine, it just freezes up if I drop it from really high. The really strange thing is the framerate crashes before the impact, and you can see the water balls sort of shrink away from the ball before it even hits, like they're scared of it or something.