Problem in Collision, again

Jul 22, 2009 at 6:27 PM
Edited Jul 22, 2009 at 6:30 PM

Regarding the previous problem as tunneling, I made the rectangles and circles thicker.
This fixed the trembling problem, but still the objects were moved strangely.

Their speeds were growing faster as they collided with each other.
In the end, they popped out of the box again. (I intended to make some completely elastic collision)

As you can see in the demo below, when an object collides, the speed(the length of velocity) changes randomly in quite a large range.
The speed should be the same after collision if this works as I intended to.

http://www.mediafire.com/?oty2qlywn1l

thanks for the comment in the previous thread anyway :)

Jul 22, 2009 at 7:04 PM
Edited Jul 22, 2009 at 7:18 PM

I am running into the same issue.  GEOMs accellarate rapidly and at high speeds one GEOM goes right through another GEOM.

http://sync-io.net/go/www/Dl/frb_farseer_test_jul22.zip

Push the down arrow to see how one GEOM goes right through another.

 

Coordinator
Jul 22, 2009 at 7:37 PM

@anonymousquito: In Farseer Physics Engine, circles are not circles. They are an approximation of circles using polygons. Whenever your ball hits the wall, it will not make a perfect hit and thus it will change speed.

I have a solution for you since you have a special case. Simply insert the line:

_circleBodies[i].MomentOfInertia = float.PositiveInfinity;

On line 68 in your Game1.cs file. That causes the ball to stop rotating at all and the vertices on the siddes of the balls are always hit perfectly. Have in mind that the speed can change, but only within epsilon (float error value = very little value).

 

@fixitchris: Tunneling is a big issue for many physics engines. High velocity geometries can go right through another if they are too small or if the velocity is too high. We are working on getting this issue resolved in Farseer Physics Engine 3.0. You can limit the issue in other ways such as using raycats or the like. Some examples on how to prevent (or at least limit it) is described on the forums and in our manual.

Jul 22, 2009 at 7:51 PM
_circleBodies[i].MomentOfInertia = float.PositiveInfinity;

This is only a temporary solution, since the rotation of the sprite might be a desired visual effect.

I'm not sure what all this means: http://en.wikipedia.org/wiki/Quantum_tunneling
but I'm sure there is a good reason for it. Until then I will limit velocities.


Coordinator
Jul 22, 2009 at 7:57 PM

Yes, that is correct.

I might build a solution for that by adding an ignore-rotation property on the body instead. Rotation will still be reported and calculated, but the geometry attached to the body will not rotate.

If this functionality is required, tell me and I will add it right away.

--

As for tunneling, it has nothing to do with quantum tunneling, it is simply a term used when geometries/shapes go into each other or simply pass each other. I think I will create a wiki page about tunneling to make it easier for you and others. Stay tuned.

Jul 22, 2009 at 8:06 PM

The ignore-rotation property would be a good idea.  I'm ok with waiting until the next release for this functionality.

Does increasing the numberOfEdges on a CircleGEOM help with the problem?

FYI, I'm using BODY.Rotation to position my SPRITE.

Coordinator
Jul 22, 2009 at 8:11 PM

In some cases yes - in most cases no.

I've seen some people fix their collision problems by adding a lot of edges to their circles, others have solved it with less. It is a question of tweaking until you get the right amount.

In anonymousquito's case, he have the perfect number of edges since he has one directly on top, left, right and bottom. If he adds another ball and would like rotation and friction between the two balls, then he too will have to tweak the amount of edges and the no-rotation fix will be useless.

I would like to mention that real circles have been implemented into Farseer Physics Engine 3.0. This means we no longer approximate a circle, we use some algorithms to make it perfect instead.

Jul 22, 2009 at 8:16 PM

Ok.  Real Circles sound good. 

What is the collisionGridSize used for on a Geom?

I'm running into an issue where a circle actually intersects a sloped rectangle while rolling down the rectangle.  The higher the downward velocity , the more the circle intersects the rectangle, until it finally goes through the rectangle.  What could be causing this?

Coordinator
Jul 22, 2009 at 8:35 PM

The collisionGridSize argument is the distance grid cell size used in the narrow phase collider. It basically defines the precision of the narrow phase. A smaller number will make small cells and will give a higher precision of collisions at the cost of memory and CPU time.

You can let the physics engine calculate a reasonable grid cell size or give it one yourself. Sometimes when you have narrow geometries or weird collision it might be worth giving it a lower grid cell size and see if that works.

Coordinator
Jul 22, 2009 at 8:56 PM

The new wiki page about tunneling is here. Hope that helps.

Jul 23, 2009 at 1:51 AM

I have a theory about this: are you guys setting your Restitution Coefficient above 1? this will cause bouncing to grow out of control unless used properly.

Jul 23, 2009 at 2:03 PM

No,  = 1.

Good point though, could the velocity increase be due to two objects having a Rest Coeff  =1 ?

Jul 23, 2009 at 4:20 PM
Edited Jul 23, 2009 at 4:26 PM
_circleBodies[i].MomentOfInertia = float.PositiveInfinity;

Appling this works very well when there's one circle in the demo.
But when I add some more circles, the same problem occurs still.

If you want to check out,
private const int count = 5;
find this code in the demo and replace 1 to 5 and try.

Circles grow faster and run out of the box about three(~five) minutes later.
It's not that serious as before, but It seems that collision 'between the circles' still have a problem.

p.s. 1 Could you let us know the approximate date releaseing 3.0?

p.s. 2 @RogueCommanderIX : Of course 1. even LinearDragCoefficient = 0

Coordinator
Jul 23, 2009 at 7:41 PM

Yes, the solution does not work with multiple circles. The only thing is to tweak the number of edges on the circle until you get something that looks real. The only other way of making it look real is to turn the circles in such a way that it always hit another ball or wall head on (a polygon point).

As for the question about the release data on 3.0; it is very difficult to say because it does not depend on us, but on another team. When they are finished with their work, I will release an estimated release date.