Bloody Rotations!

Why is it that certain prims will have an unavoidable desire to accrue small degrees of rotation when in certain positions?

It doesn't seem to matter how I move them or try and avoid t, they just persistently get that extra .1 or .2 degrees. I can change it, but it immideately swings back when I'm done.

Anyone have a fix or workaround for this? I'm currently in a large-scale, precision project, and it's worthless if the rotations keep changing.

AM

I've had major problems with this issue this week, either makes work extremely difficult, or the results substandard.

Anybody else? maybe time for a bug report?

Add '.0' to the end of your rotation.

This is a common myth... This does not, in fact, represent a true fix. It seems to work sometimes, sometimes not and even when it seems to work I'm unsure if theres any actual change, given what Kelly was telling me the problem relates to.

Alright, this error is driving me up the wall.

I'm wprking on a huge project right now, but unless this can be fixed, I'll never be able to finish it due to all of the miniscule errors that keep accumulating, and after all the work I've put into it, that would really not be cool.

Does LL know about this? does anyone know why this happens in the first place? Personally, I'd think this would be an easy fix, but I suppose it could be related to a deep problem, and not easily remadied.

*phew* alright, we've got some bright minds here, discuss.

AM

This problem only started since the last update - I gather that we have been offered the chance to "perfect" our builds with the addition of this more precise measurement function - however, I prefer the previous "imperfect" function which allowed me to more easily match up edges of prims, rotate them, etc. The update needs to be updated!

I'm bumping this because I'm having the same problem. adding .0 after rotations does not work. Does anybody know how to fix this? It's driving me nuts. I'm making a room with transparent walls, but the walls keep rotating themselves oddly, adding the .1 after a rotation. It makes little white cracks appear in the sides of the walls. Please help?

Perhaps the .11 update exacerbated the problem, but it's been around for many months prior. I think it is a rounding error caused by keeping rotations internally as quaternions, but showing them in the edit window as euler triaxials. The conversions back and forth seem to induce these little rounding errors that show up as .1 here and there.

I believe its a problem with using eular rotations, called gimbal lock. Maybe if the lindens allowed us a way to enter all 3 axes without updating untill all 3 were entered we could get around it? works script wise anyway. Heres how I get around it:

default
{
    state_entry()
    {
        // Change the <0,0,0> to set rotation. order is x y z.
        vector Rot = <0,0,0>;
        llSay(0, "Setting rotation to: " + (string)Rot);
        llSetRot(llEuler2Rot(Rot * DEG_TO_RAD));
    }
}

Sometimes I wish they would use fixed point math instead of floats.

Olmy, this problem has been around quite a while... look at the original post date. But indeed it's been around much longer than that.

A good part of the problem is just the nature of floating point numbers within a binary
system. There's no such thing as a perfect binary representation of a floating point
number. It will always round to some nearest hundredth or thousandth.

There are of course other issues within the client/server software of SL that exacerbate it
some have been worked out, some haven't, some have gotten worse here and there.

Amazing how a 100/th of a degree can throw things off after a few repititions isn't it?

UU

P.S. Good one Eggy

When I tried to enter rotations in the numeric entry fields they frequently change similarly to what has been discussed but the amount is not .1 degree but rather .01 degree. In all cases but one the change has added .01 to the entered amount, for example 180 changing to 180.01, but in one case the value reduced by .01 leaving me with, for example, 179.99 instead of 180. I have no patience for performance such as this from something billing itself as a 3d modeling program so I just gave up on building anything worth keeping. I don't even want to build a big serious project, I just want to build something simple for fun, but with a problem like this, the aggravation outweighs the fun in just a few minutes, so why bother?

It occurs to me that it might be possible to alleviate the problem by including a script that would allow setting the rotation from within a script, possibly by issuing a chat command or perhaps a script might round off angles within a certain range of integer values.

Just wondering: does anyone ever enter values like 179.99 and have them change to 180, or is the change always from an integer to not an integer? Do integer values that aren't possessed of special significance with regard to trig calculations, such as 8 degrees, suffer from this problem or is it confined to multiples of 90 degrees or other values at which trig calculations have trouble with?

it's not just the rotations that seem to creep its the translations as well, things constantly seem to shift by .004 or .007 of a whatsit and it drives me mad! I've been trying to make nice curvy things by blending cylinders and cut toruses together and there are always little speckly lines appearing because things wont stay stuck where I put them. Why is this?

Ohhh this drives me absolutely bonkers! This and it also seems like there is a .0001 variance in the position of prims as well. This is not as noticable in larger objects, but in prim jewelry, even when all the numbers are exactly the same, pieces still are not lined up. I am constantly having to maually move pieces so that they are lined up. Since I have noticed this in small pieces like jewelry, I have started to notice this similar effect in larger objects, but in larger objects it is almost impossible to get close enough to the edge you are looking at while still being able to move the object.

The script solution is the way to go. the problem is in the fact that Havok uses quaternions to represent rotations and the client uses Euler rotations. The reason for the use of quaternions in havok is because it makes the math alot easier (read faster).

If you want accurace you best build your own quaternions.

Doing math on floats is always ugly, because floats are not very accurate (takes 8->12 characters to represent a 32 bit float without loosing data). More importantly as you work with them data is lost.

I believe LL could improve accuracy if they replaced the backend handling of this conversion by using degrees instead of radians. Now before you folks who understand what i'm saying start flaming me hear me out. PI radians = 180 degrees. 180 can easily and accurately be represented in a float, PI can not be represented accurately it will be rounded. 1 Radian is generaly meaning less; 1 degree holds meaning. Using degrees would reduce some of these rounding errors that people have been complaining about for the last year+.

thanks Strife, I wish I understood what you're on about

good point. I tend to think of pi as a symbol only and to me 1.0 means half a circle, 2.0 means a whole circle. but I suppose the backand is actually based on PI, which is bad since PI is a bad number for precision.

I fully endorse this solution. Radians are insane for this kind of building.

It seems that when i try to rotate and object via edit mode using the rotation feature this is what happens to me..................

I get the sphere - -white with three circles red green blue.......
I click and hold on say just for example the red one
I start to slide my cursor and the sphere jumps madly i land my cursor in the white zone of the sphere and my object is rotated all askew.

Is it just me? Ive tried building in sand boxes, on my own land totally stripped of all scripted objects on my person and i just cannot seem to get that ball to settle down.

Totally frustrated!!!!!

Ame, spin your camera around a bit so that the circle you are trying to grab isn't perfectly overlapping the white sphere. That should help. Try to be at about 45° from the axis you want to spin your object on.

This problem has been driving me nuts for months. Even without repetitions, the eye can pick out the error easily. It changes the build from a seamless one to one with flashes of lights and lines. I have bug reported this countless times with no response.

Strife - Excellent point, if Pi is being used then to me thats nothing short of lunacy!

Thank you both ! Mike that does seem to help some. It at least makes it better than before. I too have reported this.