Hello. I'm trying to rotate 2D polygons. The polygons are drawn with standard library/API line routines, and no anti-aliasing. It's working, but the vertexes (I don't like vertices :) don't move in complete unison, which causes polygons to distort a bit, and also to grow/shrink by 1 pixel at times, depending on the shape and position. My test program is an analog watch. When the hands rotate, they seem to distort and swim instead of moving like solid objects. When tracing the path a rotated point takes, the plotted circle is not ideal -- some of its edges are 2 pixel wide, which may explain the size fluctuation, and also why small rotation increments causes some points to seem to "stick" in the same place while others move on. This explanation may not be clear enough, so have a look at http://members.fortunecity.com/xgt/rot.htm for a visual explanation of the non-ideal "point rotation trace". Also there is a DOS executable showing the problem in action. I'm doing the rotation the standard way, always calculating from the original data, and by now I'm using fixed point. What am I missing? Ehud. [Edited by - sheh on September 1, 2004 8:47:36 AM]

Well, I can only guess because you didn't post the code, so..

• You may be rotating around the wrong axis

...

Can't come up with anything else right now, and I don't think even that applies because you don't seem to be using a 3D API.

So without more info, can't really do much, but..

Quote:the plotted circle is not ideal

Why don't you use some trig to rotate the coordinates (as opposed to precalcing it)? Since you're just rotating a polygon around a single point, 1 vertex will be stationary, and the other 2 will have constant radii:

n| 2|/ \1---3

Where 1 is constant, (what was the special character for theta?)

the x coords are:
sin(angle) * Radius + x-value of 1

the y coords are:
cos(angle) * Radius + y-value of 1

where angle = the angle (in Radians) formed by n-1-2 and n-1-3.
the radius is the preset distance between 1-2 and 1-3, to be used with their respective angles.

and that should rotate your polygon.

I've added to the URL posted above an animated GIF showing it in action. The size fluctuation isn't as obvious, but the "swimming" is visible. In real life usage it's more disturbing than in the animation.

@Mushu:

Quote:use some trig to rotate the coordinates as opposed to precalcing it

What do you mean instead of precalcing it? The only thing precalculated is the sine table. I'm not sure I get what you are suggesting, if it's defining the shape data using polar coordinates instead of cartesian, I tried that to no avail.

And I didn't think such a simple thing deserves code pasting, but since you brought it up... :)

Sine table is built with:


Rotation looks like...


@Thunder_Hawk:

I'm pretty sure I saw 2D rotation working correctly even in low-res. I don't mind the aliasing, just the out-of-place vertexes, and the "size popping".

No obvious mistakes. That looks very normal for a transformation at that screen resolution. It is only due to the granularity of the pixels that any distortion occurs. "bilinear interpolation" is a common software solution for this problem.

Edit: Actually bilinear interpolation is more useful for rotating pixel buffers. If you are rotating vertices, you may just want to look-up aliased line drawing.

Quote:GUI alternative to Mode13h

Nah, I don't use DOS except for quick tests (and some text file processing).

Anyway, maybe I'm mistaken, and that's how 2D rotation is, but I may have found another solution (although I still feel like I'm missing some way to improve things); check out the SVG clock at http://homepage.mac.com/pete.boardman/24hourclock/downloads/clock.svg (right click and uncheck high-quality mode to disable AA).

It moves smoothly without AA too. I think this may be subpixel accuracy -- feeding the fractional part to a Bresenham line drawer, instead of using a fixed fraction at beginning of lines.

This is something I should check later, but it won't help with my current target platform which is low on processing power and does not provide efficient pixel-level drawing.

For now, I think I'll leave things as they are and move on. :)

Thank you all for the help.