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" <[email protected]>
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
[email protected]
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
