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

[Peter Verswyvelen]

Thanks for the info. With backtracking I actually meant the computation of
the exact collision time, and let (part of the simulation) only go that far,
so it's not really "back tracking" in the physics engine; does that
correspond to your 2nd proposal. I just got this from a physics
book<http://www.amazon.com/Dynamic-Simulations-Multibody-Systems-Coutinho/dp/038795192X>that
implements it that way (at least that why I got from reading it
diagonally, the books contains a lot of advanced math...)
But do you mean that with your proposed methods the simulation will advance
a full "time step" anyway, so the time interval does not need to broken up
into smaller ones, where each sub-interval ends with a collision event? I
wander how this could work since most of the time in a game when a collision
happens, the game logic decides what forces to apply next, so the simulation
can't really advance a full time step anyway (although that could be hacked
I guess). Converting the game logic into differential equations with
constraints seems very hard.

However, I must admit I haven't used any modern physics engines the last 5
years or so... But it's interesting to hear from people that did.


On Fri, Mar 6, 2009 at 11:59 AM, jean-christophe mincke <
jeanchristophe.mincke at gmail.com> wrote:

> 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/79d107c1/attachment.htm