Re: [vos-d] Jerky avatar movement (was Re: Patches for 0.24 in MSVC)

2007-05-05 Thread Peter Amstutz
On Sat, May 05, 2007 at 02:04:01PM -0700, Ken Taylor wrote:
> Wait... unless the purpose of "rot" *was* to caputre and restore the
> previous position, and force all position updates to go through the
> setPosition/notifyPropertyChange mechanism in that case, the main
> problem is you can't guarantee that the property change will trigger a
> syncPosition that executes *before* syncView reads the new position. So what
> was happening is syncView had the latest position, but the mesh hadn't been
> moved there yet, so the avatar lagged behind in some frames causing the
> jerky movement.

Pretty much, yes.  To be perfectly honest, avatar control in ter'angreal 
is kind of a hack.

> I think immediately moving the mesh upon a local move command isn't such a
> bad idea, but the fact that an asynchronous property update gets triggered
> and executed at some time in the future, which *also* moves the mesh, is a
> bit troubling to me. This is also concerning me because it impacts my
> interpolation code -- what happens if you do a local moveTo on an object
> that also can be moved remotely? When do you interpolate and when do you
> update immediately? Any thoughts on what the Right Way to implement this
> would be?

I'm not sure...  As you note, it's tricky because you have both local 
movement commits and the possibility that it can be changed remotely, 
and that change should stick.  It's kind of a race condition, actually, 
which is why it's hard.  The Right Way is probably to fix the semantics 
of property updates to handle this better, but that's more of something 
to consider for s5...

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Jerky avatar movement (was Re: Patches for 0.24 in MSVC)

2007-05-05 Thread Ken Taylor
Wait... unless the purpose of "rot" *was* to caputre and restore the
previous position, and force all position updates to go through the
setPosition/notifyPropertyChange mechanism in that case, the main
problem is you can't guarantee that the property change will trigger a
syncPosition that executes *before* syncView reads the new position. So what
was happening is syncView had the latest position, but the mesh hadn't been
moved there yet, so the avatar lagged behind in some frames causing the
jerky movement.

I think immediately moving the mesh upon a local move command isn't such a
bad idea, but the fact that an asynchronous property update gets triggered
and executed at some time in the future, which *also* moves the mesh, is a
bit troubling to me. This is also concerning me because it impacts my
interpolation code -- what happens if you do a local moveTo on an object
that also can be moved remotely? When do you interpolate and when do you
update immediately? Any thoughts on what the Right Way to implement this
would be?

-Ken

- Original Message - 
From: "Ken Taylor" <[EMAIL PROTECTED]>
To: "VOS Discussion" 
Sent: Saturday, May 05, 2007 1:02 PM
Subject: [vos-d] Jerky avatar movement (was Re: Patches for 0.24 in MSVC)


> I think I discovered what was causing the jerky movement... the only
mystery
> is why it isn't always a problem!
>
> In the csplugin, in vosobject3d.cc, you have this:
>
> void csMetaObject3D::doMoveTo(const csVector3& vec, float timestep)
> {
>   syncPosition(false);
>
>   csReversibleTransform rot =
> csvobj3d->GetMeshWrapper()->GetMovable()->GetTransform();
>   collider_actor.Move(timestep, 1.0, vec, csVector3());
>   csVector3 pos = csvobj3d->GetMeshWrapper()->GetMovable()->GetPosition();
>   csvobj3d->GetMeshWrapper()->GetMovable()->SetTransform(rot);
>   csvobj3d->GetMeshWrapper()->GetMovable()->UpdateMove();
>
>   setPosition(pos.x, pos.y, pos.z);
> }
>
> Now as far as I can tell, the intent of the "rot" transform is to save the
> orientation of the avatar and restore it after you move the collider. The
> only problem is, GetTransform doesn't just get the orientation -- it gets
> both the orientation *and* the origin of the transform!
>
> So effectively what's happening here is this:
> 1) get the old orientation/position
> 2) move the collider to the new position (this does an UpdateMove too)
> 3) save a copy of the new position in "pos"
> 4) * move the mesh back to the old orientation+position!
> 5) update move
> 6) set the VOS position to the saved new position
> - this then triggers a property update which happens at some undefined
> time in the future which finally moves the mesh back to the new position.
>
> So yeah... that doesn't seem quite right. I changed it to this:
>
> void csMetaObject3D::doMoveTo(const csVector3& vec, float timestep)
> {
>   syncPosition(false);
>
>   csReversibleTransform rot =
> csvobj3d->GetMeshWrapper()->GetMovable()->GetTransform();
>   collider_actor.Move(timestep, 1.0, vec, csVector3());
>   csVector3 pos = csvobj3d->GetMeshWrapper()->GetMovable()->GetPosition();
>   csvobj3d->GetMeshWrapper()->GetMovable()->SetTransform(rot);
>   csvobj3d->GetMeshWrapper()->GetMovable()->SetPosition(pos);
>   csvobj3d->GetMeshWrapper()->GetMovable()->UpdateMove();
>
>   setPosition(pos.x, pos.y, pos.z);
> }
>
> ... and this fixes my jerky movement problem, albeit kinda hackily.
Really,
> I should just change "rot" to be the other-to-this matrix instead of the
> full transform. But I was lazy for the moment :)
>
> Another question I had concerned libterangreal  at the end of
> Terangreal::moveAvatar, it calls curAvatar->syncView(). Why does it call
it
> there instead of, say, after curAvatar->applyMovement is called in
> Terangreal::ProcessFrame? Because moveAvatar doesn't actually update the
> position of the avatar -- it just calculates the relative offsets based on
> keyboard state. I moved the invocation of syncView to after applyMovement
> and it didn't have any adverse effect, and it seems like a nicer place to
> put it. If there's no objections, I'll leave that change in when I submit
> all my movement interpolation stuff.
>
> -Ken
>
> - Original Message - 
> From: "Reed Hedges" <[EMAIL PROTECTED]>
> To: "VOS Discussion" 
> Sent: Tuesday, April 24, 2007 9:10 AM
> Subject: Re: [vos-d] Patches for 0.24 in MSVC
>
>
> >
> > Wow, thanks Ken!
> >
> > >
> > > The only thing I haven't really tracked down is that avatar movement
> seems a
> > > bit "jerky" in the MSVC build. If I get more time I might look into
> it...
> >
> > Try it in a release build.  (both VOS and Crystalspace in release mode).
> > MSVC puts a lot of extra code in when in debug mode; CS also has a lot
> > of extra debug utilities that might have been enabled in debug mode.
> >
> >
>
>
> ___
> vos-d mailing list
> vos-d@interreality.org
> http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
>