For people playing with the BulletSim physics engine, the latest version in
master fixes llSetBuoyancy() and fixes/improves llApplyImpulse().
That's the short report. Now for WAY more detail than anyone but a few physics
tweekers care about:
llSetBuoyancy now works for physical objects. The problem here was an oddity
with how Bullet sets an object's gravity when the object is made physical.
Today, buoyancy is implemented by changing the gravity effect on the individual
object. Sometime in the future, buoyancy will be changed to apply an additional
force to the physical object (like to push up and negate the effect of
gravity). This will allow the setting of gravity for individual objects (a new
SL feature that is not yet in OpenSim).
llApplyImpulse now works close to how it does in SL. I spent some time pushing
around blocks in OpenSim and SL in order to get movement about the same.
Vehicle developers have mentioned that the implementation of llApplyImpulse has
always been wonky and values from SL don't work in OpenSim. In digging into
this, I've found some confusion in OpenSim's implementation of llApplyImpulse.
llApplyImpulse is defined as a simple mass/force transfer. That is,
"llApplyImpulse(V * llGetMass(), false)" will set the object moving at velocity
V. The way forces are defined in physics engines is "force per second". This
means that for any individual simulation step (there are 11 per second in
OpenSim), only part of the force is applied ("forceAppliedThisStep =
forcePerSecond * fractionOfSecondForThisSimulationStep"). Since llApplyImpulse
is an "instantaneous" push (it happens only once), to account for the reduction
in the force based on the simulation step time, the impulse force can be
multiplied internally in the physics engine driver to overcome this.
It seems this correction has been implemented haphazardly in OpenSim. For
instance, ODEPrim.AddForce multiplies the force by a constant 100[1].
SceneObjectGroup.GrabMovement divides the force by a constant 10[2] before
calling PhysicalActor.AddForce. There are various other multiplications and
divisions by 10 scattered about. I presume the "10" is because it is close to
the number of simulation steps per second ("11") and would give results that
would seem correcter.
The current resolution for BulletSim is to scale up the force specified to
BSPrim.AddForce so the total force is applied the next simulation step. This
makes llApplyImpulse work as it does in SL. A similar change was made to
BSCharacter.AddForce. Hopefully, some weapons people will tell me if this is
good or bad.
Anyway, what users will notice is that llApplyImpulse is different with
BulletSim and hopefully "correct".
-- ra
[1] Why "100" I don't know as it is more than the 11 that would overcome the
step time division. This could be for how ODE does sub-steps, but not sure.
[2] I presume this was to overcome the 100 in ODE and to get a multiplier
closer to the step divisor of 11.
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
