On Wed, 2005-03-30 at 12:34 +0200, Jan Ciger wrote: > Sean Lynch wrote: > > Since one of my goals is to have Soya able to do everything the Blender > > game engine can do and more, we need a more stable and flexible physics > > API. > > > > I've documented my proposed changes at > > <http://soya.literati.org/PhysicsApi>. Please read and comment. Feel > > free to comment directly in the wiki page. > > Hi, > > I do not agree with the hiding the step() interface for Physics. You > *need* to be able to provide the step duration there. Why? It is simple > - your app has rarely constant framerate. If you couple the framerate to > the physics sim in a fixed manner (e.g. one frame = one step), you are > going to get problems with the physics, as each frame takes a slightly > different amount of time.
There is no such coupling. I have already done the coding to expose the step interface. Most likely this will be handled in a PhysicsIdler class, in the advance_time method, probably with interpolation, which has been requested by Jiba and Arc. Actually, Arc wants me to recode ODE to allow variable timesteps ;-) Another option would be to hide it in the advance_time method of the simulation class. In neither case would it have anything to do with the application frame rate. It never has been coupled to the frame rate, in fact, only to the *round* rate, which is constant just like the timestep. > What is typically done to avoid this problem is to "cut up" the elapsed > time between the frames and feed it into the simulation as several steps > of constant length. But for this to work, you have to be able to specify > the length of the step. You cannot just take one "good" value and > hardwire it somewhere - for the next application it may not be good enough. It's not hardwired. It's a public attribute on the simulation class (still called ode.World). Actually, I think it will be overshadowed if you try to set it the way I have it set up right now, so I will probably need to change it to a property. It will stay as a property because it should only be set once per simulation, not each round as is implied by having it be a parameter to the step method. > Do not try to be very abstract with the physics engine. ODE can be very > finicky and typically every application requires a lot of tweaking to > get it working right. If you hide the "knobs" to do so, it will be very > hard to get it to do anything non-trivial. Well, I'm learning that it's hard to be abstract with it. Jiba would like me to hide everyting inside normal Soya objects, but there's just too much complexity there to hide. Geoms and spaces, for example, *must* be exposed to the user, otherwise there's no way to get collision without physics simulation, and games with a lot of colliding objects will have no way to optimize.
signature.asc
Description: This is a digitally signed message part
