[sldev] Help with VWR-332 (Re: Investigating how the viewer creates object)

[Able Whitman]

In the comments for VWR-322, you mention two separate issues: the bug itself
describes the behavior where selecting an object stops it from moving and
snaps it to it's final rotation. This is actually the expected behavior when
selecting an object. I'm pretty sure the pertinent code is in
LLSelectMgr::selectObjectOnly(), in llselectmgr.cpp at line 289 (in the
1.15.0.5 release):

    // Stop the object from moving (this anticipates changes on the
    // simulator in LLTask::userSelect)
    // *FIX: shouldn't zero out these either
    object->setVelocity(LLVector3::zero);
    object->setAcceleration(LLVector3::zero);
    //object->setAngularVelocity(LLVector3::zero);
    object->resetRot();

There is similar code in the selectObjectAndFamily() methods, which act on
the root of a linkset to stop it from moving as well.

The other issue you mention is the fact that repeatedly changing the
rotation of an object via a script is jerky. I'm honestly not sure exactly
what might cause this, but I can try to make an educated guess:

Scripts run at the sim, so whenever a script changes the rotation of an
object, it sends clients that can see the object an ObjectUpdate message
with the new rotation. From a cursory inspection of the code, it looks like
changes to an object's scale, rotation, etc. result in a call to
LLViewerObject::updateDrawable() when a viewer object processes an
ObjectUpdate message. The updateDrawable() method in turn calls
gPipeline.markMoved() with a flag indicating whether the movement is damped
or not. I'm pretty sure that in the client source terminology "damped" is
the term for the client-side effect of smoothing the transition between
rotations, etc. I think the damping effect is handled in the
LLDrawable::updateXform() method, but I'm not entirely sure.

Remember of course, that the damped motion is a client-side effect, so if
there is a noticable lag between when the script requests a rotation change,
and the sim sends an ObjectUpdate, and a client processes the ObjectUpdate,
the result will be a jerky motion. It's because of exactly this situation
that the llSetTargetOmega() LSL  function exists; this tells the client to
smoothly rotate a prim at a given angular velocity, and since this is a
client-side only effect, it isn't subject to the jerkiness that message lag
between the sim and the client can suffer from. In other words, I'm not sure
that there is a lot you can do to avoid the jerkiness of rotation changes,
except to use llSetTargetOmega().

--Able


On 6/3/07, Ziggy Puff <ziggy at planetziggy.com> wrote:
>
> I'd submitted VWR-332 a while back, and today I thought I'd try and
> figure it out myself. Since I just downloaded the code, this description
> helps a lot. VWR-332 appears to be an issue in how scripted prim
> movement is rendered, specifically, the interpolation applied to
> rotation and translation. If anyone has pointers on where to look, I
> would really appreciate that. I found the LLVOVolume class, and
> LLCriticalDamp (though that's probably used for physical movement?).
> There are lerp and slerp functions in LLQuaternion, and there's
> LLDrawable::updateXform which seems to calculate damping/interpolation
> for translations and rotations. Right now I'm trying to figure out how
> all of these fit together, and which portions I should be looking at.
>
> https://jira.secondlife.com/browse/VWR-332
>
> Thanks,
> Ziggy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070604/34132777/attachment.htm