aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/bin/Robust.32BitLaunch.exe
diff options
context:
space:
mode:
authorteravus2012-10-03 02:30:23 -0400
committerteravus2012-10-03 02:30:23 -0400
commite56ef2720ecd603c9b3c81cbb7c3a0d49d24bf85 (patch)
tree0eadc9f514dc5e0372f26204c51a229101bfd9cc /bin/Robust.32BitLaunch.exe
parentMinor Modification, switch /2 to 0.5f in ODEPrim.Velocity (diff)
downloadopensim-SC-e56ef2720ecd603c9b3c81cbb7c3a0d49d24bf85.zip
opensim-SC-e56ef2720ecd603c9b3c81cbb7c3a0d49d24bf85.tar.gz
opensim-SC-e56ef2720ecd603c9b3c81cbb7c3a0d49d24bf85.tar.bz2
opensim-SC-e56ef2720ecd603c9b3c81cbb7c3a0d49d24bf85.tar.xz
I propose that 0.5m/step change for linear velocity is too big of a change to control the reporting of a new angular velocity. I think that this could be here for one of two reasons, 1. vehicles and llMoveToTarget with axis lock, or 2. To attempt to make things look more stable in the physics scene then they really are, however, this also really affects the angular velocity reporting negatively causing things to spin wildly and jump back into place repeatedly. To compromise, if the prim is a vehicle or is being used as a motor target, the original functionality is still applied. If that's not the case, angular velocity is reported with a linear velocity of 0.02m/step. To be clear on the effect of the physical world... When you push things, there's still a lag time where you walk into the object but once the object is in motion, it begins to move as you would expect so results in slightly more realistic motion.
Diffstat (limited to 'bin/Robust.32BitLaunch.exe')
0 files changed, 0 insertions, 0 deletions