Objects falling into each other

Topics: User Forum
Dec 3, 2008 at 8:44 AM
I have wrapped all the physics (-> no Factories are in use), thus I can easily use it with my engine. But now all objects are slowly falling into each other (it runs more stable if I use 1000 FPS instead of 100 FPS... but 1000 FPS are far to much to run smooth with much more objects)

And here are my settings:

 * I'm just using rectangles currently
        + the vertices are same as the one of the factories (4 intersections on each side)
        + FrictionCoefficient = 0.4f
        + RestitutionCoefficent = 0.2f
        + GridSize is shortest-side * 0.1f

 * PhysicsSimulator is running at 100 FPS with a gravity of (0f,-9.81f)
         + the origin is at the lower left, and scales are grwoing to the upper right
         + 1 unit in the simulation (interpreted as 1 meter) equals 100 px on the screen, thus recangle-side-sizes of 0.5f and smaller are common

 * PhysicsSimulator.BiasFactor = 0.4f
         + I had already tried smaller and greater values, but the problem still occured

 * PhysicsSimulator.MaxContactsToDetect = 5

That's all I think. Has anybody an idea where the problem might be?
Dec 3, 2008 at 1:07 PM
If I may ask: Why not use the factories? Should yield the same results, but are easier to use. (and they perform common calculations needed such as moment of inertia and collision grids size)

As for the physics vs. display units, we have the ConvertUnits class to help you with that. In case you don't already use it.
In the "Known Issues" chapter from our manual we have all the fixes for this issue: Known Issues
Dec 3, 2008 at 2:41 PM
Why not use the factories? Yes, good question. Main reason is that they don't fit very good into the engine design concept. They take the possiblity to attach more than one geom to a body. I noticed that they don't calculate the correct centroid for polygons (same for the moment of inertia I think, at least because of the incorrect centroid) especial for more than one geom attached to a body. And that I'm using just rectangles at the moment is just because of testing purposes, later on there will be enough polygons.

By the way... I didn't knew that there is a class like ConvertUnits (and just realized that you cannot flip the y-aixs) *g*, but I don't need it because the conversion is done by a matrix. Yes very confusing I know ;-) it's part of a highly plugin-able system (I hope so) (every thing is organized with "modules", which have a virtual update and a virtual draw function and can house other modules...). It's my first project with C#, XNA and Farseer thus maybe it's all just a big house of cards which may collapse soon... (*sending an ejaculatory prayer towards heaven that it won't collapse* ^^).

But back to my original problem, the objects aren't falling through each other directly, the collision works allmost perfect but when they came to rest they begin to sink slowly into the thereunder object. Subdeviding the sides doesn't fix the problem, in contrast if the subdevisions are to small the collision gets broken because of the MaxContactsToDetect.

Hope you will draw conclusions from my drivel, sunDiver
Dec 3, 2008 at 6:22 PM
To attach 2 bodies to one geometry, you just supply the same body to another geometry. The same as without using the factories.

What do you mean by not calculating the correct centroid? It should be the real center of the geometry. Vertices are centered around the centroid, that's confusing some people, but the engine like it this way better. MOI (Moment of inertia) should also be calculated correctly. Only the ellipse does not have the correct MOI but it's close to it (approximate).

I can't seem to replicate the problem you have. If you have a demo of the project you can send it to me. (upload it to a public share somewhere)
Dec 4, 2008 at 11:36 AM
Edited Dec 4, 2008 at 11:38 AM
OK, I uploaded the demo to: http://uploaded.to/?id=p3o4yg
I prepared a setting where you can see pretty good my problem (a pyramid and a simple tower)
By pressing [F12] you enter editmode and drag objects with your mouse.
Right click makes them static/non-static.
[P] toggles pause-mode (just in editmode) where you can drag static objects, too

To the centroid, what I was supposed to say was: if you interpret the polygons as filled shape-polygons (instead of lines connected together) the centroid isn't placed correct (assuming that the centroid is the center of mass). The centroid currently used is the center of the AABB ("... the engine like it this way better.") but I additionally hav a positional offset to the body thus the real center of mass is on the body's (center) position.
OK a sample where the center of mass is missplaced:

|  \
|    \
|      \
|        \

On this traingle the centroid is placed on the bisection of AC, but the center of mass actualy is inside the triangle (not important if you see just A,B and C as mass points, the lines which create the polygon as masses or the whole shape as a mass).

greets sunDiver

PS: thanks for your patience :)
Dec 9, 2008 at 10:29 AM
Hi genbox, me again. I played a little bit around with my scalation.
If I change the scalation from 100 px/unit (like my demo) to 1 px/unit (every thing else the same as in the demo), every thing reacts exactly the same as in your demos :)
For me this could be a sign of a non relative constant ("magic number") somewhere in the collision code... maybe *g*

But all in all... very NICE work, thx :) (I cannot start to hate things just because of some small bugs while they're still in developement ;-) )
Dec 10, 2008 at 9:46 AM
... finally I found the problem, it wasn't an constant anywhere hided in the code. Actually I just had to modify PhysicsSimulator.AllowedPenetration (default = 0.05f which was for my scalation 5 pixels).

To everyone who has similar problems try modifying PhysicsSimulator.AllowedPenetration.

Greets sunDiver
Dec 16, 2008 at 9:08 PM
@ sunDiver... what are you refering to when talking about "scalation"?
Dec 16, 2008 at 9:50 PM
Edited Dec 17, 2008 at 1:26 PM
Edit: See sunDiver's answer
Dec 16, 2008 at 11:48 PM
@genbox: Thanks for the reply that was very informative! I was unaware that by simply decreasing the size it would speed up your calculations; that is really great to know.
Dec 17, 2008 at 8:36 AM
Edited Dec 17, 2008 at 1:39 PM
@shaku: Main reason to let me do this was to get the physics units indipendent of the pixel size, thus one physics unit equals more a meter in game. The scalation of 100 is just when you have a screen height of 1024 for me and will differ on other resolutions.

@genbox: What exactly do you mean with "small calculations sometimes equal faster calculations"? As far as I know needs floating point calculation always the same times, cause is done by the co-processor (I think 3 to 4 ticks...)
Dec 17, 2008 at 1:39 PM
I've edited my post to point to your answer.

Removed the text to make sure that people did not get their hopes up and everyone starts using scaled models, just because they think they can get better performance.

@sunDiver: This is not directly related to C# programming language, but more to the physics engine (collision algorithms). Another thing is that higher numbers gives more numerical problems, more corrections and unstable simulation. Having a world that is scaled up by x1000 would cause huge numbers to pile up inside the engine and might lead to an exception in the end. To reduce all this, you can scale your physics model down and if you manage to do it correctly, you can scale your drawing on the fly but let the physics simulation stay the same. (it needs to be, there is no easy way to scale rigid bodies in Farseer)
Engines such as Box2D (Farseer is built on this engine) has actually gone over to a 100% MKS (Meter-Kilogram-Second) system and support (you can build bigger and smaller) anything from 0.1 to about 10 meters in size. They had problems with people using pixels as mesurement and the engine would end up with huge value calculations. (and a lot of errors)
Dec 18, 2008 at 8:18 AM
@genbox: *g* good to know, thx. ^^