Roll Back Change To Rotation Clamping?

The following is in the 1.6.0 release notes:

This means that where we could previously define rotations to the thousandth place, we can now only go so far as the tenth place. This means less exact rotations and greater difficulty in aligning prims.

This was likely in response to complaints that rotations would sometimes be "off" by .001 (i.e., 270.001) and were unable to be "fixed." Of course, these rotations were not actually inexact, and were simply rounding error caused by converting the numbers from quaternions to Eulers, then from radians to degrees for the edit window.

Put more simply, the rotations were not inexact; the rounding was.

Of course, this resulted in a few complaints. The Lindens have apparently chosen to address this by, essentially, hiding the rounding error and reducing the precision with which we can rotate prims. The apparent inexactness would no doubt still be there, if we could see it.

Thus the Lindens made a choice to reduce the precision of rotations, not to fix any real problem, but to get people to stop complaining when they thought their rotations were off by .001. Personally, I don't feel that losing precision in my rotations was worth it.

So I have a proposal! Roll back the change to rotation clamping, give us the thousandth place back, and if we have to explain why 90.001 is not an inexact rotation but rather rounding error for the rest of eternity, so be it. What does everyone else think?

I'm scared to think where else the rotating inaccuracies will turn up. How often are rotations clamped? Will things that rotate a lot find themselves walking all over even faster than before? How about physical things?

I already have enough of a problem with the inaccuracies in things like hole size and top size. This just compounds the problem. This makes by-the-numbers non-rectangular building even more difficult, and it'll result in more seams and parts that are less perfectly aligned than even before. I really think limiting our precision was not the right way to go with this.

My name is Gorky Gorky and I approve of this.

However, showing in degrees seems more for usability than anything else. I'd really like an option that lets us set rotation in radians by giving it a numerator/denominator that's then multiplied by pi internally.

Ok, I've done some more testing on this.

First of all, it seems the precision in the edit window is clamped to 0.05, not 0.5 like the release notes say. This may need some further testing. It may be that the axis rotation handles still clamp to 0.5.

Internally, rotations can still be more precise than 0.05 degrees (as shown by using llGetRot() and converting to Euler and degrees). Things like physical objects will end up with rotations more precise than can be set in the edit window.

Still, this is really limiting. The only way to build with rotations as precise as before is to write a script to help you rotate things. Ugh.

less exact? Yes you are right. The problem is EVERY thing will be held to the same place. It is not like you are going to make something and they will now be off by .001. As a Mechanical Design Eng I would like the freedom to work to .000000001 but as a Mechanical Design Eng I can tell you that you are lucky if you work to .5 degrees. I wanted to be able to import files for objects in and people here pointed out file size problems. Well every number in the system will make for a problem. A Simple Box type home will take less region time then some one with all the rounds and funky angles. So maybe they were fixing that not the rounding problem you pointed out. I feel they have done a good job and hope they don’t change it back.

Well... considering there are a few methods for making wedge shapes (right triangles) that have any dimensions, defined down to the thousandth place, I'd say it's possible to make angles that nothing will align with. Although I'd hate to see their solution to that... perhaps we'd end up clamping size to the nearest half-meter too.

But seriously, try out Cadroe Murphy's shapebuilder if you want to see how well prims align in SL. With topsize and hollow clamping, we lacked sorely needed precision even in 1.5; this just makes it that much worse. Try, also, to build something with lots of prims spaced out radially, like a gear or a spoked wheel. I got to just my fourth iteration of duplicate-and-rotate before the rotation tool started getting flaky and not giving me the precision I needed. This wasn't just a theoretical rant, it's something that's already hurting my building.

Thing is, though, they haven't actually changed/fixed anything fundamental, or anything at all for that matter. Rotations, internally, are just as precise as before (check llGetRot()) and have 5 or 6 significant digits as always. It's not streaming or recording any less information. What's changed is that we can no longer see nor set precise rotations without, as Lex said, a script to do it for us. I can almost foresee a tool like the shapebuilder I mentioned which replaces our edit window... ugh. I'd rather the client tools be up to the task.

As much as it pains me to say this, you should not rely on the building tools for precision work.
If you need mathematical precision, you need to learn how to script things to build for you.
That is, until LL decides to give us better building tools. And I don't mean these nonsensical random changes, I mean high level stuff, like ShapeMaker - automatically creating certain patterns, automatically aligning existing objects to a certain shape, etc.
I want to be able to draw an arch, or a random spline, using a 2D pixel tool built into the UI and have prims automatically rezzed to match it.
Bonus points if you let me parameterize it with actual numbers instead of relying on my shaky hand to eye coordination.

Those better building tools are what we're talking about, Eggy. A solution to the lack of precision is scripts, just like in the last version, but we've lost some of the ability we had to work with our hands.

This may be madness, but I think we should be able to do anything by hand that we can by script. The inverse applies too. Anything we can do by hand we should be able to script. The current tools are a step backwards from this. 1.5 was imperfect but at least then we could try.

Ideally we could work in radians as an option (see above idea about working in ratios of pi) but until then the poll seems to be showing that people would prefer working with two shaky hands than to have one chopped off.


That's a neat idea! It'd simplify stuff a lot. However, it suffers the same problem - automating what cannot be done by hand. While awesome, it seems a lot like asking for a forklift to lift crates when you can't even lift a small box yourself.