|
|
|
This may be the same bug causing prims that are moved using llSetPrimitiveParams(). In my case, it only occurs when the prims are flexible.
I found this issue when using llSetPrimitiveParams, like you said. The script above was my attempt to reduce this to the simplest script that will show the problem. A prim rotation looks different if the object is left in-world, vs. when it is selected. I thought this was a rendering issue in the viewer, but it could be related to how the server sends out the updates.
When llSetPrimitiveParams() is used on a flexible child prim to set position and rotation in the same call, the two settings are not applied together. The rotation change takes effect quickly, while the position change happens 'smoothly', and more slowly. This causes the prim to visibly 'jerk', because it snaps to the new rotation and then smoothly moves to the new position, instead of moving to the new position and rotation together. This is very noticeable with long thin prims like wing feathers. It is more noticeable in a sky box than on the ground.
If the object is selected (with a right-click or in the Edit menu), the rotation and position changes are applied together, and the prim movement looks smooth. If the prim is non-flexi, that seems to help the problem too. I'm not sure that a selected prim should be able to set its rotation, or position, any more than a selected physical prim gets to keep moving.
I reported about this issue in the forums already in mid-february.
http://forums.secondlife.com/showthread.php?p=1410667#post1410667  I am rather upset that not only I got ignored, but even experienced scripter with in-depth know how pointing to the problem and giving easily reproducable testcases... Argent, you're right, I got 2 issues mixed up in this bug report. The selected/unselected difference is the expected behavior, I understand that now. There's still an issue with how the viewer damps position and rotation changes on non-physical objects. From Daniel's post, it looks like he's talking about the same thing.
Pasting from an email, so we have a paper trail here: !!~ You're right, I got 2 issues mixed up in that bug report. OK, so no interpolation/damping when an object is selected - that's expected behavior, I understand that. I'm more concerned with the second issue. Think of a long flat flexi rectangle that's a wing feather. When the wing flaps, the prim needs to move around its flexi anchor point. This is non-physical movement, and I'm using llSetPrimitiveParams to set the position/rotation together (with values calculated to make it look like the prim rotated around its endpoint). As far as I could tell (from eyeballing the movement in an empty sim), the interpolation/damping applied by the client is different for rotation vs. translation. I can see the prim 'slide into' its final position/rotation, but it reaches the target rotation before it reaches the target position. It was hard to tell if the position change was damped and the rotation change was undamped, or if the two were damped but by different amounts. The difference is more visible when framerates are higher. This makes the prim jerk, because you see the rotation applied around the prim center, followed by the prim moving to its new position. So instead of looking like the prim turned around its anchor endpoint (so the anchor endpoint shouldn't move), what you see is a prim rotate around its center (which moves the anchor endpoint in the wrong direction), followed by a position change (which moves the anchor endpoint back to where it needs to be). So I don't think it's a lag issue - the new position/rotation should both come to the client in the same update message, right. I think it's an issue with how the client smooths the movement. The visual effect of the smoothing applied to the position change is different from the smoothing applied to the rotation change. And this behavior changed when the first-look code was integrated into the main viewer, and has been this way since then. I was playing around with updateXform and updateDrawable last night. If I turn off damped motion completely, my wings go back to the way they used to work. But that's probably not a viable solution, and I didn't see what that did to physics and llTargetOmega. But at least it tells me I'm in the right area of the code. I'll play with changing the interpolation for rotation vs. position changes to try and understand this better. !!~ I got this confused with the selected/edited issue, because when a prim is selected, all movement is undamped, and that makes the rotation/position changes happen together. When the prim is unselected, the two are happening at different times/speeds. I like the visual effect of the damped position change, and I think the rotation change should also be damped over the same time duration. I'm more than happy to meet someone in-world to demonstrate this. Editing the description to describe a better way to reproduce this. The original description combined two separate issues, one of which is expected behavior.
[15:33] WarKirby Magojiro: the second one beinfg that rotations and translations are interpolated at different rates
Notes from triage
[15:30] SignpostMarv Martin: 332, still borked Thanks for updating the title, and apologies for not doing it myself to make things clearer. I started out with two issues mixed up, and one of them turned out to be a non-issue, and the comments got kinda hard to follow. I re-wrote the main description to be a repro for the translation/rotation interpolation issue, but didn't update the title.
This issue lists an outdated viewer as the affected version. Can you update the "Affects Version/s" if this is still an issue for you for the latest viewers?
I still see the exact same behavior with 1.21.6 and 1.22.4
Re-opening after adding the requested information.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Reopened
Normal
LSL translate and rotate interpolate at different rates (Was: Scripted prim movement rendered differently when object is selected)
The script I'm using calculates a new position/rotation to make the prim rotate around its endpoint. Prior to the update, this looked perfect. Now, the prim movement is jerky. And as reported initially, this only happens if the object isn't selected. If the object is selected in the edit window, both the movement and the rotation look like they happen instantaneously. So in my case the prim snaps into place, but the visual effect is what I'd expect if the prim were rotating around its endpoint.
So... I'm guessing that someone 'slowed down' non-physical movement, in order to make it look nicer/smoother? It does look good, but I'm guessing the timing for that is different for rotation changes. I think they should be smoothed the same amount, so that when the two are applied together using the set primitive params call, the effect looks right. Right now the prim kinda jerks/slides into its new position/rotation.