Flipping an angle horizontally - math

I want to know a way to flip an angle in a horizontal axis, without having to do many operations. Say I have an angle of 0 ("pointing right" in my code's coordinate system), the flipped angle should be 180 (pointing left). If 90 (pointing up), flipped it should still be 90. 89 is 91, and so on.
I can operate on the X/Y speeds implied by the angle but that would slow things down, and I feel it's not the proper way to go.
I don't know much math so I might be calling things by the wrong name...Can anyone help?
EDIT: Sorry I took long, I had to be out of the computer for long, OK...
http://img215.imageshack.us/img215/8095/screenshot031v.jpg
This screenshot might do.The above structure are two satellites and a beam linked to the white dot in the center. The two satellites should inherit the angle of the white dot (it's visible for debug purposes), so if it's aiming at an angle, they will follow. The satellite at the left is mirrored, so I calculated it with 180-angle as suggested, although it was my first try as well. As you can see it is not mirrored but flipped. And when the white dot rotates, it rotates backwards. The other does alright.
This is the angle recalculation for something linked to something else, pid would be the parent, and id the current. pin.ang is the angle offset copied when the object is linked to another, so it keeps position when rotated:
if(object[id].mirror)
object[id].angle = 180 - (object[id].pin.ang + object[pid].angle);
else
object[id].angle = object[id].pin.ang + object[pid].angle;
And this is the specific rotation part. OpenGL. the offx/y is for things rotated off-center, like the beam about to come out there, it renders everything else right.
glTranslatef(list[index[i]].x, list[index[i]].y, 0);
glRotatef(list[index[i]].angle, 0.0, 0.0, 1.0);
glTranslatef(list[index[i]].offx, -list[index[i]].offy, 0);
The rotation also seems to miss when the rotation speed (an integer added every redraw to the current angle, positive for rotating clockwise, like in this next one:
http://img216.imageshack.us/img216/7/screenshot032ulr.jpg
So it's definitely not 180-angle, despite how obvious it'd be. The mirroring is done by just reversing the texture coordinates so it doesn't affect angle. I am afraid it might be a quirk on the GL rotation thing.

The reflected amount (just looking at the maths) would be (180 - angle)
Angle | Reflection
------+-----------
0 | 180
90 | 90
89 | 91
91 | 89
360 | -180
270 | -90
Note the negatives if you fall below the "horizontal plane" - which you could leave as they are, or handle as a special case.

Isn't it simply
result = 180-(your angle)

As already explained, you find the opposite angle by subtracting your angle from 180 degrees. Eg:
180 - yourangle
Directly manipulating the X/Y speeds would not be very cumbersome. You simply reverse the direction of the X speed, by multiplying it by minus 1, example: speedx = (-1) * speedx. This would change the left-right direction, eg: something moving to the left would start moving to the right, and vice versa, and the vertical speed would be unaffected.
If you're using sine/cosine (sin/cos) to recalculate your X/Y speed components, then the *(-1) method would probably be more efficient. Ultimately it depends on the context of your program. If you're looking for a better solution, update your question with more details.

This solution is for -Y oriented angles (like a watch)! For +X orientation (like school math) you need to swap X and Y.
public static float FlipAngleX(float angle)
{
angle = NormalizeAngle(angle);
angle = TwoPi - angle;
return angle;
}
public static float FlipAngleY(float angle)
{
angle = NormalizeAngle(angle);
if (angle < Pi)
{
angle = Pi - angle;
}
else
{
angle = TwoPi - angle + Pi;
}
return angle;
}
/// <summary>
/// Keeps angle between 0 - Two Pi
/// </summary>
public static float NormalizeAngle(float angle)
{
if (angle < 0)
{
int backRevolutions = (int)(-angle / TwoPi);
return angle + TwoPi * (backRevolutions + 1);
}
else
{
return angle % TwoPi;
}
}

Aah, seems the problem came from negative numbers after all, I ensured them being positive and now the rotation does fine, I don't even need to recalculate angle...
Thanks to everyone, I ended up figuring out due to bits of every response.

to flip counter clockwise to clockwise (270 on right -> 90 on right)
angle - 360
--
to flip vertical (180 on top -> 0/360 on top)
Math.Normalize(angle - 180)
--
both:
float flipped_vertical = angle - 360
float flipped_vertical_and_horizontal = Math.Normalize(flipped_vertical- 180)

just 360-angle will flip your angle horizontaly but not verticaly

Related

How to determine if need to swap start and end angle when drawing an arc

I have multiple polygon maps (made up of lines and arcs). I am using turf.lineArc() to calculate points on an arc and to do this the start and end points of the arc need to be clockwise, if not they need to be swapped around.
I have the following code to swap the start and end points around (but it is not quite right)
if (endAngle < startAngle) {
endAngle = endAngle + 360;
}
if (startAngle < endAngle) {
var e = endAngle;
endAngle = startAngle;
startAngle = e;
}
while (startAngle - endAngle > 180) {
startAngle = startAngle - 360;
}
var arc = turf.lineArc(center, radius, startAngle, endAngle, options);
My problem is knowing when to swap the start and end around and when not to. In my attached picture Map1 works correctly without being swapped around but Map2 needs to have the start and end points swapped. (and they both need to use the same code). If map 2 does not have the start and end swapped around turf.lineArc draws a major arc of 353 degrees which is not what I want.
How do I fix my code so I only swap the start and end points when travelling from start to end is in an anti-clockwise direction?
Thank you :)
Edit: Arc can be < 180 or >180 and I know if it is major (>180) or minor (<180)
If your desired arc always should be < 180 degrees, then you can apply the next approach to overcome periodicity and zero-crossing pitfalls:
if Math.sin(endAngle-startAngle) < 0 then swap
I think, angles should be in radians in turfjs.
Also check - perhaps you have to change <0 to >0 to provide clockwise direction in your coordinate system.
I used this by Corrl to determine clockwise direction so then knew if to swap or not.
JavaScript - Find turn direction from two angles

How to set Raycast direction to 90 degrees instead of through camera

I have a problem with my 3D Project. It is quite complicated to describe the purpose so I try to abstract it to the minimum.
I have an live videostream of the unity program which I bring up to fullscreen (1920 x 1200). One user clicks on the screen to send the coords to the unity app.
sending coords:
// relative coord
float x = mouse_x / 1920.0f;
float y = mouse_y / 1200.0f;
The receiver is the unity app, which trys to make an 3D coordinate of it and finds a wall or an obstacle to place a mark.
1. Attempt
// 1268 x 720 receiver viewport size
Ray ray = Camera.main.ScreenPointToRay(new Vector3(Position.x * 1268.0f, Position.y * 720.0f, 0));
2. Attempt
// * 1268 not necessary
Vector3 far = Camera.main.ViewportToWorldPoint(new Vector3(fix.Position.x, fix.Position.y, 1));
Vector3 near = Camera.main.ViewportToWorldPoint(new Vector3(fix.Position.x, fix.Position.y, 0));
Vector3 dir = far - near;
dir.Normalize();
Ray ray = new Ray(near, dir);
RaycastHit hitInfo;
if(Physics.Raycast(ray, out hitInfo))
{
// place mark
}
Both attempts results in the same way. If the coordinate is around the center then it is in the center on the receiver as well. But the more it goes to the edge it will be much farer from the position it should be. The picture shows what I think happens. The red circle is the current behaviour and the green is what I was expecting. I'd rather have a 90 degrees ray from the screen to the wall than right through the cam.
I really do not know what to do. Thank you very much for your help in advance.
You're right about your drawing, this is indeed what's happening.
Here is a test I did using Debug.DrawRay.
The blue ray is the output of this code.
Debug.DrawRay(Camera.main.transform.position, Camera.main.transform.forward * 100f, Color.red);
And here is the drawing of the red, like you did.
var viewportPointRay = Camera.main.ViewportPointToRay(viewportTouchPos);
Debug.DrawRay(viewportPointRay.origin, viewportPointRay.direction * 3f, Color.blue);
I was expecting a truly simple answer but I wasn't able to find one. I did found a trick to do what you want though.
var ray = new Ray(viewportPointRay.origin, Camera.main.transform.forward);
Debug.DrawRay(ray.origin, ray.direction, Color.green);
Result

THREE.js: Why is my object flipping whilst travelling along a spline?

Following up from my original post Three.JS Object following a spline path - rotation / tangent issues & constant speed issue, I am still having the issue that the object flips at certain points along the path.
View this happening on this fiddle: http://jsfiddle.net/jayfield1979/T2t59/7/
function moveBox() {
if (counter <= 1) {
box.position.x = spline.getPointAt(counter).x;
box.position.y = spline.getPointAt(counter).y;
tangent = spline.getTangentAt(counter).normalize();
axis.cross(up, tangent).normalize();
var radians = Math.acos(up.dot(tangent));
box.quaternion.setFromAxisAngle(axis, radians);
counter += 0.005
} else {
counter = 0;
}
}
The above code is what moves my objects along the defined spline path (an oval in this instance). It was mentioned by #WestLangley that: "Warning: cross product is not well-defined if the two vectors are parallel.".
As you can see, from the shape of the path, I am going to encounter a number of parallel vectors. Is there anything I can do to prevent this flipping from happening?
To answer the why question in the title. The reason its happening is that at some points on the curve the vector up (1,0,0) and the tangent are parallel. This means their cross product is zero and the construction of the quaternion fails.
You could follow WestLangley suggestion. You really want the up direction to be the normal to the plane the track is in.
Quaternion rotation is tricky to understand the setFromAxisAngle function rotates around the axis by a given angle.
If the track lies in the X-Y plane then we will want to rotate around the Z-axis. To find the angle use Math.atan2 to find the angle of the tangent
var angle = Math.atan2(tangent.y,tangent.x);
putting this together set
var ZZ = new THREE.Vector3( 0, 0, 1 );
and
tangent = spline.getTangentAt(counter).normalize();
var angle = Math.atan2(tangent.y,tangent.x);
box.quaternion.setFromAxisAngle(ZZ, angle);
If the track leaves the X-Y plane things will get trickier.

Calculating if or not a 3D eyepoint is behind a 2D plane or upwards

The setup
Draw XY-coordinate axes on a piece of paper. Write a word on it along X-axis, so that the word's centerpoint is at origo (half on positive side of X/Y, the other half on negative side of X/Y).
Now, if you flip the paper upside down you'll notice that the word is mirrored in relation to both X- and Y-axis. If you look from behind the paper, it's mirrored in relation to Y-axis. If you look at it from behind and upside down, it's mirrored in relation to X-axis.
Ok, I have points in 2D-plane (vertices) that are created in similar way at the origo and I need to apply exactly the same rule for them. To make things interesting:
The 2D plane is actually 3D, each point (vertex) being (x, y, 0). Initially the vertices are positioned to the origo and their normal is Pn(0,0,1). => Correctly seen when looked at from point Pn towards origo.
The vertex-plane has it's own rotation matrix [Rp] and position P(x,y,z) in the 3D-world. The rotation is applied before positioning.
The 3D world is "right handed". The viewer would be looking towards origo from some distance along positive Z-axis but the world is also oriented by rotation matrix [Rw]. [Rw] * (0,0,1) would point directly to the viewer's eye.
From those I need to calculate when the vertex-plane should be mirrored and by which axis. The mirroring itself can be done before applying [Rp] and P by:
Vertices vertices = Get2DPlanePoints();
int MirrorX = 1; // -1 to mirror, 1 NOT to mirror
int MirrorY = 1; // -1 to mirror, 1 NOT to mirror
Matrix WorldRotation = GetWorldRotationMatrix();
MirrorX = GetMirrorXFactor(WorldRotation);
MirrorY = GetMirrorYFactor(WorldRotation);
foreach(Vertex v in vertices)
{
v.X = v.X * MirrorX * MirrorY;
v.Y = V.Y * MirrorY;
}
// Apply rotation...
// Add position...
The question
So I need GetMirrorXFactor() & ..YFactor() -functions that return -1 if the viewer's eyepoint is at greater "X/Y"-angle than +-90 degrees in relation to the vertex-plane's normal after the rotation and world orientation. I have already solved this, but I'm looking for more "elegant" mathematics. I know that rotation matrices somehow contain info about how much is rotated by which axis and I believe that can be utilized here.
My Solution for MirrorX:
// Matrix multiplications. Vectors are vertical matrices here.
Pnr = [Rp] * Pn // Rotated vertices's normal
Pur = [Rp] * (0,1,0) // Rotated vertices's "up-vector"
Wnr = [Rw] * (0,0,1) // Rotated eye-vector with world's orientation
// = vector pointing directly at the viewer's eye
// Use rotated up-vector as a normal some new plane and project viewer's
// eye on it. dot = dot product between vectors.
Wnrx = Wnr - (Wnr dot Pur) * Pur // "X-projected" eye.
// Calculate angle between eye's X-component and plane's rotated normal.
// ||V|| = V's norm.
angle = arccos( (Wnrx dot Pnr) / ( ||Wnrx|| * ||Pnr|| ) )
if (angle > PI / 2)
MirrorX = -1; // DO mirror
else
MirrorX = 1; // DON'T mirror
Solution for mirrorY can be done in similar way using viewer's up and vertex-plane's right -vectors.
Better solution?
if (([Rp]*(1,0,0)) dot ([Rw]*(1,0,0))) < 0
MirrorX = -1; // DO mirror
else
MirrorX = 1; // DON'T mirror
if (([Rp]*(0,1,0)) dot ([Rw]*(0,1,0))) < 0
MirrorY = -1; // DO mirror
else
MirrorY = 1; // DON'T mirror
Explaining in more detail is difficult without diagrams, but if you have trouble with this solution we can work through some cases.

Cocos2D/Math - clean angle conversion

Mornin' SO!
I'm just trying to hone my math-fu, and I have some questions regarding Cocos2D in particular. Since Cocos2D wants to 'simplify' things, all sprites have a rotation property, ranging from 0-360 (359?) CW. This forces you to do some rather (for me) mind-humping conversions when dealing with functions like atan.
So f.ex. this method:
- (void)rotateTowardsPoint:(CGPoint)point
{
// vector from me to the point
CGPoint v = ccpSub(self.position, point);
// ccpToAngle is just a cute wrapper for atan2f
// the macro is self explanatory and the - is to flip the direction I guess
float angle = -CC_RADIANS_TO_DEGREES(ccpToAngle(v));
// just to get it all in the range of 0-360
if(angle < 0.f)
angle += 360.0f;
// but since '0' means east in Cocos..
angle += 180.0f;
// get us in the range of 0-360 again
if(angle > 360.0f)
angle -= 360.0f;
self.rotation = angle;
}
works as intended. But to me it looks kind of brute forced. Is there a cleaner way to achieve the same effect?
It is enough to do
float angle = -CC_RADIANS_TO_DEGREES(ccpToAngle(v));
self.rotation = angle + 180.0f;
for equivalent transformations
// vector from me to the point
CGPoint v = ccpSub(self.position, point);
actually, that's vector from point to you.
// just to get it all in the range of 0-360
you don't need to do that.

Resources