Any help with this please.
The AS interface uses degrees for bone rotation, internally it uses radians to describe bone rotations.
AS/lua thinks that 120º equals 120 degrees in radians, but 120.00º does NOT equal 120 degrees in radians.
Plus AS by default when opening a saved file AS has converted a bone's rotation to 120.00 even if you set it to 120 before saving it. It always adds the two decimals.
And as you scrub through the animation of a rotating bone the bones rotation will jump from a float to an integer.
There is some kind of rounding problem going on in AS. I think it isn't showing the entire number in degrees. So 240.00 is really 240.00004675786 or something like that.
I'm guessing.
-vern
Math help - 360 is not equal to 360.00???
Moderators: Víctor Paredes, Belgarath, slowtiger
CorrectThe AS interface uses degrees for bone rotation, internally it uses radians to describe bone rotations.
Wrong!AS/lua thinks that 120º equals 120 degrees in radians, but 120.00º does NOT equal 120 degrees in radians.
120º is 120 degrees and that's all!.
If you say:
"AS/lua thinks that 120º equals 120 degrees in radians"
is the same error if you say:
"AS/lua thinks that 45 miles equal 45 miles in kilometers"
It is normal. When you introduce the number in the interface the program read a string and convert it internally to a float number (plus convert it to radians in this case). Then when you request the current value again by the user interface he don't remember the string you inserted before. He show you a string that represents the current value of the internal float number (before show you he converts it into degrees). So its internal convention is to show you 2 decimals. For example for positions it shows you also two decimals.Plus AS by default when opening a saved file AS has converted a bone's rotation to 120.00 even if you set it to 120 before saving it. It always adds the two decimals.
Can you show an example of that?And as you scrub through the animation of a rotating bone the bones rotation will jump from a float to an integer.
Maybe, but it doesn't matter. 240.00 is THE SAME than 240.00004675786 in hearth scale. If we where modeling the earth orbit around the sun and we consider an error of 0.0000467 degrees it represents a distance traveled by earth of 60.957 km what is more or less two seconds in a human time scale.There is some kind of rounding problem going on in AS. I think it isn't showing the entire number in degrees. So 240.00 is really 240.00004675786 or something like that.
-Semi minor axis of the Earth is 149,576,999.826 km
- 0.00004675785 degrees is 0,000000816 radians
- Earth average orbital speed is 29.783 km/s
....
Just kidding
-G
The problem is number comparison
In my script I have two variables in an "if then" statement. I compare them like this:
y >= x
This is what is being compared
x is a value that is 360º in radians divided by the number of layers in a switch multiplied times the increment of a looping for statement.
y is the bone's rotation value which is in radians.
There are 6 layers. x is in radians based on the rotation of a bone to determine when a switch key should be placed.
On the first loop
x = 120 (this would be 120º in radians)
then
x = 180
x = 240
..... etc etc.
120.00º >= 120º in radians
This returns false even though it's true.
If the number in the AS interface is 120 and no decimals:
120.00 degrees >= 120.00 degrees in radians
Then the script returns true.
The only difference are the decimal points in the AS interface.
Create an AS document with one bone with 0 rotation. On frame 1 key the 0 rotation. On regular intervals key the bone rotation at 60º increments until you reach 360º.
If I scrub in between those points and watch the rotation change in the box it will jump from strong to float. Sometimes there will be two decimal places just with 0's and sometimes none, sometimes long strings of ".9999999" etc etc. It depends on the number of frames bettween each key. I believe I used 6 frames.
So a lot of this is caused by perfect division of 360º. Even so it isn't correct.
I am on a Mac... could this have anything to do with platform differences?
I can't convert all the numbers to float since then the script doesn't work. I can't convert to strong since that would really mess things up.
It is the = part that isn't working. The > part is working fine.
-vern
In my script I have two variables in an "if then" statement. I compare them like this:
y >= x
This is what is being compared
x is a value that is 360º in radians divided by the number of layers in a switch multiplied times the increment of a looping for statement.
y is the bone's rotation value which is in radians.
There are 6 layers. x is in radians based on the rotation of a bone to determine when a switch key should be placed.
On the first loop
x = 120 (this would be 120º in radians)
then
x = 180
x = 240
..... etc etc.
120.00º >= 120º in radians
This returns false even though it's true.
If the number in the AS interface is 120 and no decimals:
120.00 degrees >= 120.00 degrees in radians
Then the script returns true.
The only difference are the decimal points in the AS interface.
Create an AS document with one bone with 0 rotation. On frame 1 key the 0 rotation. On regular intervals key the bone rotation at 60º increments until you reach 360º.
If I scrub in between those points and watch the rotation change in the box it will jump from strong to float. Sometimes there will be two decimal places just with 0's and sometimes none, sometimes long strings of ".9999999" etc etc. It depends on the number of frames bettween each key. I believe I used 6 frames.
So a lot of this is caused by perfect division of 360º. Even so it isn't correct.
I am on a Mac... could this have anything to do with platform differences?
I can't convert all the numbers to float since then the script doesn't work. I can't convert to strong since that would really mess things up.
It is the = part that isn't working. The > part is working fine.
-vern
If you are comparing two numbers to know if one is inside one interval of other then you can do following:
I'll repeat the concpets to know if I understood them:
x= a bone rotation angle. It is like a control for the switch layer.
y= current value of the rotation model.
When you rotate y you want to rotate x to select a switch layer value.
So imagine there are N layers in the switch layer.
You'll divide 360º into N layers to obtain N intervals and not N angle values.
Let's say that the interval value is:
L=360/N (converted to radians of course). L is an angle value.
Supouse you have an initial value for x what is the first value of the boundary of the intervals. Let's call it x0
Then then boundaries of the interval are:
x0 = x0 + 0*L
x1 = x0 + 1*L
x2 = x0 + 2*L
...
xn = x0 + N*L
So the comparison must be
if y>=x0 and y<x1 then ...
to see if the y is in the first interval, and so on.
Also you have to normalize 'y' before you compare to the intervals. For example if x0=zero and y is 425 degrees (let's say N=6 for example) then y is in the second interval x1-x2.
To do that there are math fucntions that do that automatically. I don't konw lua API but you have to do this:
Divide y between 360 (2*pi) and take its decimal value (substract its integer value). Let's call it w. Make y*= w*360 (or 2*pi). Then you obtain y* what is y but normalised.
Hope this help you to perform your "turning switch" script.
Waiting for your response and some exaples of your development.
Best.
-G
I'll repeat the concpets to know if I understood them:
x= a bone rotation angle. It is like a control for the switch layer.
y= current value of the rotation model.
When you rotate y you want to rotate x to select a switch layer value.
So imagine there are N layers in the switch layer.
You'll divide 360º into N layers to obtain N intervals and not N angle values.
Let's say that the interval value is:
L=360/N (converted to radians of course). L is an angle value.
Supouse you have an initial value for x what is the first value of the boundary of the intervals. Let's call it x0
Then then boundaries of the interval are:
x0 = x0 + 0*L
x1 = x0 + 1*L
x2 = x0 + 2*L
...
xn = x0 + N*L
So the comparison must be
if y>=x0 and y<x1 then ...
to see if the y is in the first interval, and so on.
Also you have to normalize 'y' before you compare to the intervals. For example if x0=zero and y is 425 degrees (let's say N=6 for example) then y is in the second interval x1-x2.
To do that there are math fucntions that do that automatically. I don't konw lua API but you have to do this:
Divide y between 360 (2*pi) and take its decimal value (substract its integer value). Let's call it w. Make y*= w*360 (or 2*pi). Then you obtain y* what is y but normalised.
Hope this help you to perform your "turning switch" script.
Waiting for your response and some exaples of your development.
Best.
-G
Yeah...
Something weird is happening. There is definitely some kind of bug.
Same problem. The script behaves differently depending on if the bones angle was typed in "by hand" or the angle was in there when the file was just opened.
The same thing is happening. The values are not being "compared" the same way each time.
Typing values into the bone angle box with the rotate tool gives a different result than if AS does it. Like when opening the file with preexisting rotation values.
I will have to figure out a way to deal with these numbers so they end up the same each time.
It works as long as you always set the bone angle to be higher than the rotation units. I could just make that "the rule" but it seems annoying that I can't do it "the right way".
-vern
Something weird is happening. There is definitely some kind of bug.
Same problem. The script behaves differently depending on if the bones angle was typed in "by hand" or the angle was in there when the file was just opened.
The same thing is happening. The values are not being "compared" the same way each time.
Typing values into the bone angle box with the rotate tool gives a different result than if AS does it. Like when opening the file with preexisting rotation values.
I will have to figure out a way to deal with these numbers so they end up the same each time.
It works as long as you always set the bone angle to be higher than the rotation units. I could just make that "the rule" but it seems annoying that I can't do it "the right way".
-vern