3
\$\begingroup\$

UPDATE - Code updated below but still need help adjusting my math.

I have a cube rendered on the screen which represents a car (or similar).

cube

Using Projection/Model matrices and Glm I am able to move it back and fourth along the axes and rotate it left or right.

I'm having trouble with the vector mathematics to make the cube move forwards no matter which direction it's current orientation is. (ie. if I would like, if it's rotated right 30degrees, when it's move forwards, it travels along the 30degree angle on a new axes).

I hope I've explained that correctly.

This is what I've managed to do so far in terms of using glm to move the cube:

glm::vec3 vel; //velocity vector

void renderMovingCube(){

    glUseProgram(movingCubeShader.handle());
    GLuint matrixLoc4MovingCube = glGetUniformLocation(movingCubeShader.handle(), "ProjectionMatrix");  
    glUniformMatrix4fv(matrixLoc4MovingCube, 1, GL_FALSE, &ProjectionMatrix[0][0]);

        glm::mat4 viewMatrixMovingCube;
        viewMatrixMovingCube = glm::lookAt(camOrigin, camLookingAt, camNormalXYZ);

        vel.x = cos(rotX); vel.y=sin(rotX);
        vel*=moveCube;

        //move cube 
        ModelViewMatrix = glm::translate(viewMatrixMovingCube,globalPos*vel);

        //bring ground and cube to bottom of screen
        ModelViewMatrix = glm::translate(ModelViewMatrix,  glm::vec3(0,-48,0));
        ModelViewMatrix = glm::rotate(ModelViewMatrix, rotX, glm::vec3(0,1,0));     //manually turn

        glUniformMatrix4fv(glGetUniformLocation(movingCubeShader.handle(), "ModelViewMatrix"), 1, GL_FALSE, &ModelViewMatrix[0][0]); //pass matrix to shader
    movingCube.render();        //draw
    glUseProgram(0);
}

keyboard input:

void keyboard()
{
    char BACKWARD  = keys['S']; char FORWARD   = keys['W'];
    char ROT_LEFT  = keys['A']; char ROT_RIGHT = keys['D'];

    if (FORWARD) //W - move forwards
    {
        globalPos += vel;
        //globalPos.z -= moveCube;
        BACKWARD = false;  
    }
    if (BACKWARD)//S - move backwards
    {
        globalPos.z += moveCube;
        FORWARD = false;  
    }
    if (ROT_LEFT)//A - turn left
    {
        rotX +=0.01f;
        ROT_LEFT = false;  
    }
    if (ROT_RIGHT)//D - turn right
    {
        rotX -=0.01f;
        ROT_RIGHT = false; 
    }

Where am I going wrong with my vectors? I would like change the direction of the cube (which it does) but then move forwards in that direction.

\$\endgroup\$
  • \$\begingroup\$ Possible duplicate: gamedev.stackexchange.com/questions/26845/… \$\endgroup\$ – MichaelHouse Nov 10 '13 at 16:42
  • \$\begingroup\$ Lots of steering questions on the site. Have you looked through them? \$\endgroup\$ – MichaelHouse Nov 10 '13 at 16:43
  • \$\begingroup\$ I've looked through many, yes, but that majority are unanswered and the rest aren't applicable. Also, I've already seen that post, it's not a duplication, the post is using only C++ and an engine of some description. I'm using OpenGL/SL and Vectors. I'm yet to find a basic tutorial or simple example of the maths with vectors so they can be applied using GLM. Thanks for the comment. \$\endgroup\$ – Reanimation Nov 10 '13 at 16:50
3
\$\begingroup\$

To make the cube move forward, you need to find the cubes's velocity vector. The direction of the velocity vector is simply the angle of rotation. Then simply add it to the position;

//pseudocode
vector velocity(cos(rotX),sin(rotX); //assume rotX converted to radians
velocity*=SPEED_PER_FRAME;//SPEED_PER_FRAME is a scalar (might be moveCube)

if (FORWARD)        //W - move cube along zAxis positive
{
    globalPos += velocity;
    BACKWARD = false;  
}
if (BACKWARD)       //S- move cube along zAxis negative
{
    globalPos.z -= velocity;
    FORWARD = false;  
}
\$\endgroup\$
  • \$\begingroup\$ Thanks for the post and psuedecode. I will look into this and try to implement it as all I wish to achieve at the moment is moving forward and turning somewhat realistically away from set axes which hopefully you code will help implement. Thanks. \$\endgroup\$ – Reanimation Nov 10 '13 at 19:37
  • \$\begingroup\$ I've tried to implement your psuedo code but I'm getting strange responses on-screen. \$\endgroup\$ – Reanimation Nov 12 '13 at 22:12
  • \$\begingroup\$ So to clarify, when this: velocity(cos(rotX),sin(rotX); is calculated, then added to an origin, say (0,0), it will equal a vector where the car will end up? \$\endgroup\$ – Reanimation Nov 19 '13 at 2:44
  • \$\begingroup\$ Yes, adding a velocity vector to a position results in a new position. (This is greatly simplifying the laws of motion, but it'll get you going) \$\endgroup\$ – Ken Nov 19 '13 at 9:59
  • 1
    \$\begingroup\$ Just wanted to let you know, I've finally implemented car controls and I used your answer. Thanks again for posting. I'm extremely happy right now :) \$\endgroup\$ – Reanimation Dec 5 '13 at 23:46
1
\$\begingroup\$

You need to apply some level of physics. At the very least you need to be familiar with basic Newtonian motion and Euler integrations of the base 'p2=p1+v*t' and 'v2=v1+a*t' equations. You can then apply some approximations of forces using algorithms like those on red3d's site (which is not about vehicle steering but is applicable with some thought) . The goal is that you don't move the car left but instead you apply a force (or just change the acceleration if you don't care about mass or other forces like surface friction) that turns the car left over time resulting in a more natural curve to the motion.

Note that you'll end up having to tweak and experiment with values a lot to get something that feels good. Having the ability to edit parameters to the algorithms at runtime as you experiment like with AntTweakBar will be invaluable.

Actual car physics are incredibly complicated. Even with an expensive middleware like Havok you're going to need a lot of time and someone(s) with a very deep understanding of physics simulation to simulate wheels, suspension, engine-driven acceleration, breaking, friction, etc. to get a game with car physics like you see in AAA driving games (or most other games with vehicles like Battlefield or Halo or whatnot). The basics above are not even close to physically accurate and there simply isn't any "basic math" version that is, unfortunately.

\$\endgroup\$
  • \$\begingroup\$ Thanks for your comment and links. I will be looking through them thoroughly. Yes, I appreciate the complexity of simulating accurate physics. I'm in the process of reading a Mathematics and Physics for Programmers book by Flynt and Kodicek (which I highly recommend for anyone reading this thread). At the moment, I'm merely trying to simulate very very basic physics such as moving diagonally/across axes. I'm now where near considering suspension or complex forces just yet. \$\endgroup\$ – Reanimation Nov 10 '13 at 19:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.