Hello Peter,

The backtraking in time to solve the collision problem you mentionned is not, in my opinion, efficient.

From a previous life as an aerospace engineer, I remember that two other solutions exist to handle contact or collision constraints, at least if 2nd order diff. equations are used to describe the motion of a solid with mass.

In any case, you have to use a 'serious' variable time step integration algorithm (I.E Runge-Kutta).

1. The naive one: introduce a (virtual) spring between every 2 objets that may collide.  When these objets get closer, the spring is compressed and tries to push them back.
If the mass/velocity are high, that leads to a stiff system and the time steps may become very small.
However, this solution does not require any modification of the equations of motion.

2. The serious one: modify or augment the equations of motion so that the collision constraints are implicitly taken into account. If I remember well, the magical trick is to use langrangian multipliers.
The difficult here (especially in the context of aFRP) is to derive the new equations.

Hope it helps

Regards

Jean-Christophe Mincke


2009/3/6 Peter Verswyvelen <bugfact@gmail.com>
Regarding hpysics, did anybody did some experiments with this? The blog seems to be inactive since december 2008; has development ceased? 

Do alternatives exist? Maybe good wrappers (hopefully pure...)  around existing engines?

Integrating hpysics with Grapefruit might be a good topic for the Hackaton, trying to make a simple game (e.g. Pong or Breakout) without using recursive signal functions, but with correct collision response and better-than-Euler integration, all handled by the physics engine. Other FRP engines could be tried, but Grapefruit hacking is already a topic on the Hackaton, so it would combine efforts. 

It feels as if none of the current FRP engines can handle physics correctly, since a typical physics implementations requires "time backtracking", in the sense that when you want to advance the current simulation time by a timestep, collision events can happen during that time interval, and hence the FRP engine can only advance time until the earliest collision event. So to do physics *with* an FRP engine, the implementation and maybe even semantics of the FRP system might need to be changed. *Using* a physics engine as a blackbox inside an FRP system might make more sense.

Thanks to Wolfgang Jeltsch and Christopher Lane Hinson for having a discussion with me that lead to this.  Interestingly a similar discussion was help by other people in the Reactive mailing list at the same time :-)

Cheers,
Peter Verswyvelen






_______________________________________________
Reactive mailing list
Reactive@haskell.org
http://www.haskell.org/mailman/listinfo/reactive