[Haskell-cafe] Re: [reactive] FRP + physics / status of hpysics

[jean-christophe mincke]

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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/reactive
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090306/0c1fb7a6/attachment.htm