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 < [email protected]> 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 <[email protected]> > >> 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 >> [email protected] >> http://www.haskell.org/mailman/listinfo/reactive >> >> >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
