[ODE] Damping

[james at 6msoft.com]

Clamping prevents velocity from reversing in the event someone puts a very
large damping value with a very large time step in (and somehow I think
that a flying object that suddenly reverses directions might not be
desired). And how is it less of an issue with forces in this case? Forces
are scaled linearly by the time step in the same way I am scaling the
damping values. You end up with the "problem" of 5 steps at 0.2 not
equalling the same result as 20 steps at 0.05, so as I said before, you
yield the same results, but simply multiply and then divide by mass
(anyone guess what mass/mass is equal to?).

-James.

>
> "Exponential curves" was not what I meant at all.
>
> Specifically, the reason I mentioned powf() was that
> you have to take a power of the time step to make sure
> that you get the same result with the same damping with
> different time steps. With forces, this is less of an
> issue.
>
> However, powf() is *REALLY* slow (slower than division,
> and slower than a poorly predicted branch), so my mention
> of the function was more a question about whether it was
> a good idea to change velocity directly, than an actual
> suggestion. I would be against adding multiple calls to
> powf() into the step function of ODE.
>
> Anyway, I don't see what the clamping function adds to
> the behavior. I'd rather just get rid of it, if someone
> will actually accept this submission into the mainline.
>
> Cheers,
>
> 			/ h+
>
>
> -----Original Message-----
> From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf Of
> james at 6msoft.com
> Sent: Friday, July 30, 2004 12:17 PM
> To: ode at q12.org
> Subject: RE: [ODE] Damping
>
>
> I see what you are saying, but the fact is, I don't think you will find a
> physics engine on the planet that is perfectly deterministic with
> different tickrates. And certainly using forces wouldn't be either
> (specially when they dont take tickrate into account at all). Having an
> exponential curve for damping might make it more correct though, so I will
> look into it. Might also allow for different interpolations (like how you
> do fogging in OpenGL), so you can do pure linear or exponential.
>
> -James
>
>>
>>> the equation is something like...
>>
>>> a = damping * timeStep
>>> a = clamp(a, 0, 1)
>>> vel *= 1 - a
>>
>> This looks wrong. If I step five times with time step 0.2
>> using this method, I will get a different end velocity than
>> if I step twenty times with time step 0.05. I believe you
>> need to involve a powf() in the calculation of the actual
>> timestep dependent damping to apply, if you apply it to
>> velocity in this way. Alas, powf() is sadly quite slow :-(
>>
>> If you don't want to involve the powf(), I'd suggest not
>> scaling damping by timestep at all, and save both a multiply
>> per body and the clamp (which may possibly branch, which may
>> be more expensive than a divide).
>>
>>> For disabling, right now setting the damping of a body to 0 disables
>>> it,
>>> but currently no way across a world (but it can obviously be done.
>>
>> May I suggest that you make the damping API mirror the
>> auto-disabling API as closely as possible, for consistency?
>>
>> Cheers,
>>
>> 			/ h+
>>
>>
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>
>