[opensource-dev] Review Request: [STORM-56] As Builder, I want more decimal places allowed in the Build tool so that I can more precisely align small prims.

[Tateru Nino]

I know that there are certain minimums for position updates. If you move
a prim less than the threshold value it appears to move in the viewer,
but the region considers the prim *not* to have moved. I don't recall
exactly what the threshold value is - 0.005, I think. When you come back
to the region another time, the prim isn't exactly in the position you
thought it was in, as any updates below the threshold never 'took'.

That's one of several causes for so-called prim-drift (the prims look
like they're in the right place now, but later they're mysteriously not
quite where you think they should be).

My workaround for this has always been - that if I need to move a prim
such a small amount - to move it further away, and then apply the larger
delta to get it to where I needed it. That's always worked for me, even
to some quite fine levels of precision.

On 13/08/2011 4:54 AM, Kadah Coba wrote:
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/424/
>
>
>     On August 12th, 2011, 10:09 a.m., *Richard Nelson* wrote:
>
>         We picked the precision values for those spinners based on what would survive the roundtrip via our precision-limited object update packets.  Adding more precision will possibly result in confusion when the values don't respond the way you expect them to.  This is particularly a problem for rotation...position and scale could probably survive another decimal point...I haven't done the math.
>
> This would explain what Vadim found as I couldn't see what could be the cause of that.
>
>
> Perhaps updating such small increments frequently, i.e. with the low increment spinning, will led to small decimal accuracy being lost/ignored? This was something I always wondered about. Phoenix and many other viewers far older than it (I've only propagated the feature :P), had been using the extra decimals without any apparent problems. But that mag vector of 1/2 millimeter seemed to be there for more than just limiting the number of sent updates.
>
> During one of the iterations of porting this to v-d, I had an XUI property for limiting the minimal increment of the spinner buttons. Lower decimal values could still be entered but they could not be "slid" to. So if changing an objects rotation, position or scale by an extra decimal or two occasionally and intentionally, by manually entering it, isn't a problem or too much of one, I could limit the spinner's minimum increment to the original default lowest decimal place, or a multiple there of.
>
> - Kadah
>
>
> On July 29th, 2011, 4:40 p.m., Kadah Coba wrote:
>
> Review request for Viewer.
> By Kadah Coba.
>
> /Updated July 29, 2011, 4:40 p.m./
>
>
>   Description
>
> Adds 2 features:
>
> Adds the ability to use modifier keys to change the defined increment on LLSpinCtrl.
> Alt: increment x10
> Ctrl: increment x0.1
> Shift: increment x0.01
>
> Adds extra decimal places to position, size, and rotation on build floater.
> Also changes LLPanelObject::sendPosition and LLPanelObject::sendScale to set smaller changes in the associated values, no change was needed for LLPanelObject::sendRotation. There should be no ill effects from this, changes are still only sent to sim on button release.
>
> https://bitbucket.org/Kadah_Coba/storm-56
>
>
>   Testing
>
> Same code has been in use on FS beta for some time. I have built and tested this myself on v-d.
>
> *Bugs: * STORM-56 <http://jira.secondlife.com/browse/STORM-56>
>
>
>   Diffs
>
>   * indra/llui/llspinctrl.cpp (UNKNOWN)
>   * indra/newview/llpanelobject.cpp (UNKNOWN)
>   * indra/newview/skins/default/xui/en/floater_tools.xml (UNKNOWN)
>
> View Diff <http://codereview.secondlife.com/r/424/diff/>
>
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110813/9a456c6b/attachment.htm