[reactive] FRP + physics / status of hpysics
daniel.buenzli at erratique.ch
Fri Mar 6 08:34:18 EST 2009
Le 6 mars 09 à 11:17, Peter Verswyvelen a écrit :
> without using recursive signal functions,
If this is because there's this limitation in the frp system you use
then better fix the system. Soon or later it you'll want it elsewhere.
A recursive reactive signal just means that some of what your reactive
program computed will be usefull/necessary for the next step. You'll
see that happen very quickly (e.g. any simple reactive state machine).
> 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.
I stumbled on the same problems. I don't think that's a question of
frp semantics. I also don't think that these are unsurmountable,
however in the end it turns into the question whether you do really
gain something in implementing that with frp (vs. having an frp
interface to the system; a clear benefit to me).
The problem is that when you are doing a timestep with the physics
engine there are a lot of "things" that happen internally that you
don't want the outside world (which implements the concrete simulation
logic) to see. Moreover these "things" are very much control flow
oriented. This means that you have to introduce intermediary clean
signals that are the result of sampling the dirty (internal) signals
when the timestep has eventually finished and a lot of control signals/
events system to handle the control flow.
What we need to remember is that frp is a form of dataflow
programming. Now what I suspect is that the way physics engines are
currently programmed are very much control flow oriented, notably
because you need to be efficient and also because the discrepancy
between ideal real numbers/continuous time and our floating point
numbers/discrete time steps shows up very quickly and you have to
resort to ad-hoc and dirty strategies to handle it.
So my guess at that point is that either you can can find a dataflow
oriented implementation of physics engines and then using frp makes
sense to implement it. Either as you suggest :
> *Using* a physics engine as a blackbox inside an FRP system might
> make more sense.
P.S. I'm only on the reactive list keep me on the cc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Reactive