Repulsion stops working when Particles collide

[PEM--]

When a Repulsion with negative strength is applied from one Particle A on a Particule B, the Particle B is attracted to the Particle A. Which is good.

But when the Particle B touches Particle A, the Repulsion is not applied anymore.

In this reproduction scenario, if you remove the initial velocity on Particle B (the satellite) (removal can be done by commenting line 49), it should end up crashing on the Particle A (the planet) with a spring motion.

[speigg]

FYI, it's easier to see the bug if you make the repulsion force smaller (-1.1 or -1.2) in your example (in addition to commenting out line 49)

[PEM--]

Thanks @speigg. At least, it confirms the bug. If basic forces cannot be achieved, we are stuck trying to create a presentation engine relying on physic.

[AdamCmiel]

It looks like without collisions, when the two particles become close together, the second gets a velocity applied greater than the escape velocity of the vector field. This seems to be the implementation, not the library.

Here's an updated pen: http://codepen.io/anon/pen/KwPxOQ

[PEM--]

@AdamCmiel What?

Mass of both particles is 1. The initial velocity is not altered in space: no friction, therefore it will stay constant. The velocity vector applied has a normal below 1. Just set the gravity above -10 (an attraction of 10N) and the particle in movement will simply go through the fixed particle. It should be re attracted back by the attraction force which is greater than the product of the mass and the normal of the initial velocity.

Even simpler. Comment out your line 51: no initial velocity at all. The particle in movement should be attracted to the fixed particle.

Actually, it is even worst than that, both particles should move towards each other.

PS: You are talking about escape velocity aka the slingshot effect. This could not be the case. There is no velocity nor mass difference for that.

[tdsfugal]

Looks like a singularity problem to me. A usage error. Not a bug.

The repulsion force computation is essentially dividing by zero when the two particles are close enough. Since it is a discrete simulation the force errors appear as impulses to the velocity. Normally the errors are imperceptibly small and tend to average out, but when the satellite falls "through" the body the particle centers come very close, so close that the force error is an impulse that kicks the satellite out of the system.

(That's why it's always smart to wear eye protection and step back whenever there is a possibility of dividing by zero...)

There are ways to mitigate the singularity blow-up (see range, cutoff and cap in the Repulsion code), but these are essentially cheats that introduce other physics errors. The pro solution is to set up the world so that the centers can't get close enough for the numerical round off error to matter. Wrap the centers in a Collision, for example, to better simulate physical objects. If the particles really do have to get that close in the simulation then the physics engine needs to either use a smaller delta-T or a more insensitive (and expensive) integration technique (e.g. Runga-Kutta-Fehler), or both.

[PEM--]

Hi @TDSFugal. Indeed, it is either a division by zero or Number limit reached within the particle and force calculations.

You're talking about usage error in my reproduction scenario. Well, maybe. What is wrong with it?

Note that it's a reproduction scenario. The real case is not to launch a sattelite using famo.us. I'm just launching web apps leveraging the physic engine for display as a constraint solver :smile:

For the use case, I don't need a better physical approach. I'm just using 2 particles: one is the upper left corner of a surface and the second is the lower right corner. And yes, width and heigth of the surface may be 0 at given time.

[tdsfugal]

i don't see much wrong with it. It has a precession error that wouldn't pass muster in a science or engineering application but is probably acceptable for a game application. is the precession error a show-stopper for your constraint solver display or can you live with it?

As for "it blows up when they get too close" problem, well, that's just going to be a problem. The governing equation has a singularity at r = 0. Your application has to make sure that r stays large enough to avoid the blow up.

When I'm faced with a singularity in one of my simulations the first thing I consider is, "what is the physical significance of the singularity?" Adding that natural answer almost always solves the problem. For example, planets have surfaces and/or atmospheres. A real satellite would crash. Space vehicles can pass gas clouds, but as they get closer to the center of the cloud the gravitational attraction goes to zero. A force model based on gas cloud gravitation doesn't have a singularity at r=0 so the problem is solved.

So if your exemplar world is a satellite orbiting a planet, have the simulation "crash" when r <= R_planet. If the solver is a learning solver then give it a strongly negative penalty score (and if not then make sure that r > R_planet + safety_margin is one of the constraints!) and restart.

[MylesBorins]

closing for now. Please feel free to re open