In my experiment, i conclude these:
YourView.transform = CGAffineTransformMakeRotation( positive value );
will rotate the view clockwise, and
YourView.transform = CGAffineTransformMakeRotation( Negative value );
will rotate the view counterclockwise,
But the document says:
The angle, in radians, by which to rotate the affine transform. In iOS, a positive value specifies counterclockwise rotation and a negative value specifies clockwise rotation.
does those contradict with each other?
Your confusion is quite understandable.
In truth, a positive angle represents a rotation from the positive X axis toward the positive Y axis. A negative angle represents a rotation from the positive X axis toward the negative Y axis.
The “native” Core Graphics coordinate system is modeled after the standard Cartesian coordinate system, in which the Y axis increases upward on the page. In this system, a positive angle represents a counter-clockwise rotation:
So if you create your own CGContext (for example, by using CGBitmapContextCreate or CGPDFContextCreate), rotations will work as you expect.
However, computer systems have historically used a coordinate system in which the Y axis increases downward on the page. In a flipped coordinate system like this, a positive angle represents a clockwise rotation:
Notice that in both coordinate systems, a positive angle rotates from the positive X axis toward the positive Y axis.
It turns out that UIKit flips the coordinate system of the graphics contexts that it creates for you. This includes the graphics context it sets up before sending you drawRect: and the graphics context it sets up in UIGraphicsBeginImageContext. (The Quartz 2D Programming Guide explains this.) You can check this by looking at the current transform matrix (using CGContextGetCTM). You will find that it has a -1 in its d element, meaning that the Y axis is flipped.
A UIView also uses a flipped coordinate system for laying out its subviews, which affects the meaning of the UIView transform property.
Related
We rotated a transform by setting Euler angles at runtime.
obj.transform.eulerAngles = new Vector3(0,270,90);
We are trying to export obj.transform.rotation quaternion rotation information to absolute rotation in degrees (i.e. X, Y, Z- World axis) as we need to send this information to a non-unity system where rotation applies in world axes only.
How can we calculate absolute rotation in world axes?
I am having doubt to the used equation in the function of imgradient.
In the line of 127:
Gdir = atan2(-Gy,Gx)*180/pi; % Radians to degrees
Why the Gy have to be negative?
The y-axis is inverted in images (it increases downward instead of upward). This causes the angles to increase clockwise instead of counter-clockwise as you're used to. By flipping the y component of the gradient, this line computes an angle in the "normal" sense.
Using the graph that #Dan linked in his comment:
In this graph, y increases upward, and angles increase counter-clockwise. In an image, the coordinate system is flipped. This leads to counter-intuitive angles. Hence they invert the y axis to compute the angle.
I need a way to rotate a given image plane along an axis of which the ends are specified by the user. After the desired rotation the user must be able to get the projection of the image which he is looking at in the screen.
rotate(h,direction,alpha)
rotates the graphics object h by alpha degrees. direction is a two- or three-element vector that describes the axis of rotation in conjunction with the origin of the axis of rotation. The default origin of the axis of rotation is the center of the plot box. This point is not necessarily the origin of the axes.
Positive alpha is defined as the righthand-rule angle about the direction vector as it extends from the origin of rotation.
More detail is here
My math is too rusty to figure this out. I want to derive the onscreen angle (the angle as seen on the 2d screen) of a 3d vector.
Given the x and y rotation of a vector (z rotation is zero and doesn't mstter), what does the angle on screen look like?
We know when y is zero and x is positive, the angle is 90. When y is zero and x is negative the angle is -90. When y is 90, for any value of x, the angle is 180. When y is -90, for any value of x, the angle is 0.
So what the formula here so I can derive the angle for the other values of x and y rotation?
The problem, as stated, doesn't make sense. If you're holding z to zero rotation, you've converted a 3D problem to 2D already. Also, it seems the angle you're measuring is from the y-axis which is fine but will change the ultimate formula. Normally, the angle is measured from the x-axis and trigometric functions will assume that. Finally, if using Cartesian coordinates, holding y constant will not keep the angle constant (and from the system you described for x, the angle would be in the range from -90 to 90 - but exclusive of the end points).
The arctangent function mentioned above assumes an angle measured from the x-axis.
Angle can be calculated using the inverse tangent of the y/x ratio. On unity3d coordinated system (left-handed) you can get the angle by,
angle = Mathf.Rad2Deg * Mathf.Atan(y/x);
Your question is what will a 3-d vector look like.
(edit after posted added perspective info)
If you are looking at it isometrically from the z-axis, it would not matter what the z value of the vector is.
(Assuming a starting point of 0,0,0)
1,1,2 looks the same as 1,1,3.
all x,y,z1 looks the same as any x,y,z2 for any values of z1 and z2
You could create the illusion that something is coming "out of the page" by drawing higher values of z bigger. It would not change the angle, but it would be a visual hint of the z value.
Lastly, you can use Dinal24's method. You would apply the same technique twice, once for x/y, and then again with the z.
This page may be helpful: http://www.mathopenref.com/trigprobslantangle.html
Rather than code this up yourself, try to find a library that already does it, like https://processing.org/reference/PVector.html
I drew Globe object using OpenGL and i can rotate it with finger touch , but it doesn't work well in some cases because i am rotating using the difference between x and y
Rotation3D rot = sphere.currentRotation;
rot.x += diffX ;
rot.y += diffY ;
rot.z += 10 ;
sphere.currentRotation = rot;
when you move your finger from Top Right to bottom Left it isn't work good.
Any ideas ?
Thanks
Peter Gabra
To arbitrarily rotate objects, it's easiest to store their current orientation as a transformation matrix and manipulate the elements. I explain this in detail here.
The only difference is that in that other question, the OP wanted to apply rotations from two controls (horizontal and vertical), whereas you are after drag-based rotation. The technique is basically the same, but instead of rotating around either the X or Y axis, you need to compute an arbitrary axis of rotation from the touch's delta vector as follows:
axis = [0, 0, 1] ⨯ [diffX, diffY, 0]
(⨯ = "cross product")
Then you rotate the U, V and W vectors (as described in my other answer) around the axis by some angle in proportion to the length of the delta vector:
M = rotation(k * length([diffX, diffY, 0]), axis)
U = M * U
V = M * V
W = M * W
If you find the object rotating in the opposite direction to what you expect, there are three possibilities:
If it's only the vertical rotation that goes the wrong way, you need to negate diffY. This is a common mistake I make due to inconsistencies between OpenGL and UIKit coordinate systems.
If it's all rotation, you can either swap the arguments in the cross-product or use [0, 0, -1]. This is usually because of confusion between left- and right-handed coordinate systems.
If it's just the horizontal rotation, make both adjustments. (Don't negate diffX, no one uses left-to-right X-coordinates.)
In case you're using Euler angles: I recommend not using Euler angles to model rotations. Use Quaternions instead. It might seem like it makes your code more complicated, but rotations work well when you use Quaternions. Here's some advantages:
it's very straightforward to apply user interaction to current rotation state
no gimbal lock problems
no need for matrix drift adjustments after repeated rotations
you can interpolate rotations easily
Note that Apple give you a Quaternion type to use: GLKQuaternion. No need to write your own Quaternion class.
See also:
http://www.ogre3d.org/tikiwiki/Quaternion+and+Rotation+Primer
Euler angles vs. Quaternions - problems caused by the tension between internal storage and presentation to the user?