Wobbly rotation

Member
Posts: 117
Joined: 2010.09
Post: #1
Hi all,

Because I batch my sprites I rotate them not using glrotate etc.
Instead a more conventional:

new_x = cos(rotate)*(x_width - t.x) - sin(rotate)*(y_height - t.y) + t.x;
new_y = sin(rotate)*(x_width - t.x) + cos(rotate)*(y_height - t.y) + t.y;

The problem is as my quad is actually 2 tri's it 'wobbles' especially on the edge (i.e. where the 2 tri's meet).
Is there anyway to get opengl to perhaps ignore the rounding errors (which I presume are causing the problem)?
After-all using glrotate on a supposed quad does produce a 'smooth' (i.e. wobble free) rotation.

thanks in advance

Mark
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #2
(Nov 19, 2010 05:58 AM)markhula Wrote:  Is there anyway to get opengl to perhaps ignore the rounding errors (which I presume are causing the problem)?

If your coords are off because of rounding error on your side, I don't see how the GL is going to know how to "fix" them for you.
Quote this message in a reply
Member
Posts: 117
Joined: 2010.09
Post: #3
Hi,

I guess my coords are not 'off' and it's how GL render's the 2 tri's i.e. their coordinates on 2 points should be identical.
Perhaps there is some GL render state I need to set that I am unaware of.

Mark
Quote this message in a reply
Member
Posts: 129
Joined: 2009.03
Post: #4
I'm using fixed point math to compute vertex positions for rotated quads (two triangles), and never had this problem.

Are you definitely passing the same vertex positions, for the 2 matching vertexes on each triangle? I'd be tempted to double-check that first. Other than that, is there anything in OpenGL relating to the blending mode on edges of triangles?
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #5
(Nov 19, 2010 08:05 AM)markhula Wrote:  Hi,

I guess my coords are not 'off' and it's how GL render's the 2 tri's i.e. their coordinates on 2 points should be identical.
Perhaps there is some GL render state I need to set that I am unaware of.

Mark

Are you using GLfloat's? If so, the GL will draw them where you say to draw them. If not, well then there's your problem. Wink
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #6
The easiest way to ensure that your vertices are really coincident is to repeat indices in drawelements.

Only calculating each vertex once and then reusing it should work though...
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #7
There has to be something else going on here. Are you assigning a float to an int somewhere maybe? That would produce some pretty gross looking "wobble" as the corners snap to different integer values at different times.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 117
Joined: 2010.09
Post: #8
Hi all,

Thanks for the replies.
The coordinates are definitely the same; because I only compute 4 and 'copy' the shared 2; making the required 6 in total.
My glVertexpointer is GL_SHORT so no floats for the render.
The wobble is especially noticeable at slow speeds i.e. the 2 halves of the image just 'wobble' at the point they meet.

cheers
OK!,
Fixed it.
It was my fault (obviously!); I had GL_SHORT's instead of GL_FLOAT's for my vertexpointer. Rotation now smooth.
I guess therefore this is obviously slower; so should I use GL_SHORT for non-rotated sprites and GL_FLOAT for rotated sprites???; of
course this now messes up my sprite batching.
Is the speed penalty really that bad?!?!???

Cheers
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #9
The correct answer was yes. Wink Again the problem is that you are performing a nice precise correct rotation using floating point math, then storing the result into an int and throwing all the subpixel accuracy of the calculation away. As the corners of your quad snap to different grid points at different times, it's going to give you really really nasty wobbly looking rotations. Even if things aren't being drawn anti-aliased, the extra sub-pixel accuracy of floats does make a difference to how the line is drawn.

You could fix it by using fixed point (bad bad idea), or just use GL_FLOAT for your vertex arrays.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 117
Joined: 2010.09
Post: #10
Thanks!

I guess my question now is whats the speed penalty for using GL_SHORT over GL_FLOAT?
i.e. is it worth my having a separate draw list for rotation (i.e. GL_FLOAT); but that means texture changes.

Is the penalty really that bad?!?

Cheers
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #11
I've never heard of such a penalty myself, but the only way to be sure is to observe it for yourself. The recommendation you'll probably hear around here is not to try to optimize something until you've implemented a working solution, empirically measured it, and found a bottleneck that's causing your game's performance to suffer unacceptably. Increasing your code's complexity without hard data or prior direct experience telling you it's necessary for performance is usually wasted effort.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #12
Floats are twice the amount of data to send to the GPU as shorts, so yeah, there will be a performance penalty. How much of a penalty? Probably not much.

Practically speaking, I use floats everywhere. If I happen to notice I can use shorts somewhere instead, without causing me a hassle, I will use shorts. Otherwise I've learned that it's not worth losing sleep over those details until/unless it becomes necessary.

Batching can be particularly helpful, but I don't even design for that ahead of time anymore. Just draw the stuff, and if it's too slow, then consider things like batching, or change the game design to Draw Less Stuff™.
Quote this message in a reply
Member
Posts: 117
Joined: 2010.09
Post: #13
Thanks-all!
Will keep with FLOATS for now.
And as pointed out; when it does all start slowing down there are probably a million other things to optimise before resorting to meddling with floats to shorts :-)

Cheers!
Quote this message in a reply
Post Reply