[Opensim-dev] Some problems with Avatar Movement in BulletSim

[Mister Blue]

Thank you for the comments. The more people looking at BulletSim the better.

Yes, avatar movement is too abrupt as it is implemented. Like, when flying,
taking your finger off the forward key stops the avatar immediately. Not a
smooth thing.

In the file BSMotor.cs I've started building what I hope will be general
classes for velocity change. I've been playing with APIs and such while
working on vehicles. I want to eventually add a "PID motor" that can be
used for hovering/floating as well as avatar acceleration/flight. I don't
like all the if's and logic scattered around the code and I'm trying to
centralized some computation functions.

My plan is to have a movement motor added to the avatar and
'setTargetVelocity' setting the motor target and the current velocity being
read out of the motor and applied at each time interval.

If you have some idea on the best way to generalized such a thing, that
would be very useful.

-- ra


On Sat, Dec 15, 2012 at 8:39 AM, Teravus Ovares <teravus at gmail.com> wrote:

> Hey Robert,
>
> I was looking at the bulletsim code for avatar movement and noticed that
> it's implemented with SetLinearVelocity.  It doesn't really have an
> accumulator or any notion that it shouldn't apply a firm velocity in some
> directions in some circumstances..   and I think directly setting linear
> velocity to the TargetVelocity is the thing that is making avatar movement
> feel unrealistic in many cases.
>
> The way that the Physics.Manager interface was implemented for avatar
> movement was 'target velocity' should reflect where the avatar aims to move
> in force.. not necessarily it's velocity directly.. it's more like a
> representation of 'effort'. This is also why the above scene feeds
> TargetVelocity to physics only when it changes... Physics is supposed to
> hold on to whatever it was set to last and apply it each step until it
> changes.
>
> As it is right now, movement is too 'regular'..    and forces get applied
> in circumstances that don't really make any sense physically.
>
> For example(again, these are meant to point out issues to help by
> demonstrating)...   tap page up repeatedly.    BulletSim sets the linear
> velocity to {<0, 0, 9.983999>} causing the avatar to move up slightly and
> then fall..   but repeatedly..   the avatar will 'hop upwards' against
> gravity in thin air.
>
> It should know not to apply a Z force from Avatar Movement when the avatar
> is not flying and not contacting an object of some kind (best if contact at
> feet level).       The results of applying a Z Linear velocity improperly
> can be demonstrated by falling from the air and pressing a directional
> key.   Note how it improperly affects your Z velocity stalling your fall.
> The other side effect of setting Linear velocity is..  when running into
> objects, you often run through them until, your position moves or you
> release a key because linear velocity is directly being set and passed to
> the client causing interpolation to move your avatar through the object
> until the client gets another update.   The client will get another update
> when the avatar position moves significantly or rotates or the velocity
> changes significantly.
>
> It seems like..   input from the above scene is being applied once per
> button press 'push' via TargetVelocity..   which is setting Velocity.. in
> BSCharacter.Velocity that is then being sent to ForceVelocity and getting
> applied.     Then the scene stops applying new forces..    because the
> targetvelocity isn't changing..     and the EntityUpdate call seems to be
> re-applying the force from the physics engine causing what ever velocity
> the physics engine is reporting to perpetually repeat as long as the entity
> keeps updating.
>
> I'm trying to be helpful with an explanation.      For avatar movement, I
> would take TargetVelocity in and, each step, I'd apply an impulse that was
> likely to get the avatar to the target velocity within certain
> conditions.    If the avatar wasn't flying..   then the Z component of
> TargetVelocity should be treated like a slightly delayed jump.   If the
> avatar is falling and not flying, then Z should be ignored...  the avatar's
> fall shouldn't be stopped because they pressed a direction arrow...      If
> AlwaysRun is set, then the X and Y component of the target velocity should
> be multiplied by a greater then 1 multiplier like 1.3f to increase the
> velocity and give the effect to the user that the avatar is running.
>
> Hopefully this comes across as helpful :)..   that's the intent anyway.
>
> Best Regards
>
> Teravus
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20121215/774f6516/attachment-0001.html>