I'm trying to rotate elements in a c++ script. Basically i have two set of coordinates.
So I have two coordinates, each representing the origin of one of the elements. And I would like to rotate both elements by a certain degree. But I would like to keep the same layout. For example, if i want to rotate my element of 90degrees i'm going to obtain something like that (every degrees is working).
And this is where my problem comes in. As the rotation is done from the origin, the two elements will not remain in the same position despite the rotation, and will totally change place and will no longer face each other. And that's the opposite of what I'm trying to achieve. To have a rotation of the two elements as at present, but leaving them face to face in the same arrangement as below.
With only two origins and a value in degrees, is it possible to perform a rotation as above, keeping a logicallayout like the first picture ?
Do not rotate the origin coordinates, as they do not change. Only rotate the element coordinates with respect to the center of rotation of that element.
In 2D, rotating a point $(x, y)$ by angle $\theta$ into point $(x^\prime, y^\prime)$ is $$\left\lbrace \begin{aligned} x^\prime &= x \cos \theta - y \sin \theta \\ y^\prime &= x \sin \theta + y \cos \theta \\ \end{aligned} \right.$$ To rotate with respect to some other point, you subtract the coordinates of that other point first, then rotate, and finally add back the coordinates of that other point. Essentially, you translate origin to that other point for the duration of the rotation.
Let's say you have the actual world coordinates $(x_k, y_k)$ for $k = 1 \dots N$ for some element –– say the vertices of a polygon ––, and you want to rotate it by angle $\theta$ around $(x_0, y_0)$. If we call the rotated coordinates $(X_k, Y_k)$, then $$\left\lbrace \begin{aligned} X_k &= x_0 + (x_k - x_0) \cos \theta - (y_k - y_0) \sin \theta \\ Y_k &= y_0 + (x_k - x_0) \sin \theta + (y_k - y_0) \cos \theta \\ \end{aligned} \right.$$
Note that because you use floating-point numbers which are not exact, you need to keep the original, un-rotated coordinates, instead of using $\theta$ as the "additional" rotation, because when applying multiple rotations in sequence, the rounding error due to floating-point numbers not being exact will accumulate. It is not perceptible for the first hundred or so rotations, though.
Even better is to keep the unrotated element coordinates relative to the elements own center of rotation. Then, to draw the element, you specify the world coordinate center point $(X_0, Y_0)$, rotation angle $\theta$, optional scale factor $L$ ($L = 1$ for no scaling), plus the relative coordinate list. If the element coordinates with respect to its local center of rotation are $(x_k, y_k)$, for $k = 1 \dots N$, then the world coordinates $(X_k, Y_k)$ are $$\left\lbrace \begin{aligned} X_k &= X_0 + L x_k \cos \theta - L y_k \sin \theta \\ Y_k &= Y_0 + L x_k \sin \theta + L y_k \cos \theta \\ \end{aligned} \right.$$ For example, the relative coordinates for a rectangle with edge lengths $w$ and $h$ with its center of rotation at the corner closest to origin would be $(0, 0)$, $(w, 0)$, $(w, h)$, and $(0, h)$.
For the same rectangle, if the center of rotation is at the center of the rectangle, the relative coordinates would be $(-w/2, -h/2)$, $(w/2, -h/2)$, $(w/2, h/2)$, and $(-w/2, h/2)$.
Note that if your relative coordinate lists are the vertices of a polygon, depending on the libraries you are using to draw the lines or polylines, you may need to add an edge between the last vertex and the first vertex, by appending the first point to the end of the vertex list. You'll notice you need to do this, if your drawn polygons are otherwise missing one edge.