pseudo 3D rotation help

[devon]

So for my first game I'm making an asteroids clone and I'm trying to draw an asteroid with lines that has pseudo 3D "rotation". I'm trying to do this without getting overly complicated and just moving 4 y coords when the "z" coord is increased .2 every frame. It changes to -.2 when a y coord is at the edge of the asteroid (distance from the center is greater than radius).

The problem is I think the functions decrease slower than they increase so every 2nd rotation or so the asteroid looks fatter when all the y coords are passing each other in the center. If that makes sense. Any help would be appreciated. I left out the SFML drawing in my example, but obviously I would create lines with the x and y coords.

Code: [Select]

//init
double x[6] = {90,150,210,150,150,150};

double y[6] = {100,100,100,100,40,160};
double radius = 60;
double centerY = 100;
double spinSpeed = .2;

//in game loop
//Reverse function when halfway to simulate spin
if ((y[1] - centerY) >= radius)

    {  

        count = -spinSpeed;

    }

   

    else if ((y[1] - centerY) <= -radius)

    {

        count = spinSpeed;

    }

   

    if ((y[4] - centerY) >= radius-5)
    {  

        count2 = -spinSpeed;

    }

   

    else if ((y[4] - centerY) <= -radius)
    {  

        count2 = spinSpeed;

    }

double z2 = sqrt(y[1]) + count;
double z6 = sqrt(y[5]) - count2;

y[1] = pow(z2,2.0);
y[3] = centerY-(y[1] - centerY);
y[5] = pow(z6,2.0) ;

y[4] = centerY-(y[5] - centerY);

[Wizzard]

I don't actually understand what your code is doing, but that minus five in the third if statement looks fishy.

[devon]

ah, well that 5 was an old temporary test, but it wasn't the problem.

Basically I was trying to simulate rotating this asteroid shape:



by simply increasing and decreasing the inner and outer diamonds in sync. But I could never get them in sync. If my trig was better I probably would've realized this method that I figured out this evening with a little help from the unit circle and http://www.tutcity.com/view/the-basics-of-3d-rotations.1143.html.

Silly me, thinking algebraic functions would be simpler than trig.  I blame my calc class.

Here's my new code approx that works perfectly and is even simpler:

//init in constructor
double pi = 3.14159;
y2Angle = 0;
y4Angle = pi;
y5Angle = pi/2;
y6Angle = 3 * pi/2;

//update in game loop
y2Angle += spinSpeed;
y4Angle += spinSpeed;
y5Angle += spinSpeed;
y6Angle += spinSpeed;

y[1] = centerY + radius * sin(y2Angle);
y[3] = centerY + radius * sin(y4Angle);
y[5] = centerY + radius * sin(y5Angle);
y[4] = centerY + radius * sin(y6Angle);

[quasius]

You need to track the vertices as internal 3D and transform them to 2D for rendering.

[devon]

since i'm only moving 4 of the y vertices (so I don't need to worry about matrices), I think keeping track of the y coords as an array, modifying the array with trig functions that rotate the ys on a z circle (which would look like an expanding and contracting line in 2d space)  and then recreating the lines after a few game loop cycles works fine.


But doing it in 3D would be good for me to learn.  It's the basic openGl stuff right? or is there something else you mean by 3D? and I would pass the vertex coordinates to the sfml shape line as new shapes every few game cycles? or use openGl lines and rendering draw them separately? It boils down to basically the same thing, but with more overhead if I use openGL to keep track of all the vertices I think.