Pregunta

I'm currently experiencing a problem where GLM is providing choppy transformation and rotations. By this, I mean that they're not smooth. I'm using GLFW 3, GLM and OpenGL 3.2. I'm trying to transform a simple quad using joystick input. At first, I thought the problem was caused by the joystick. To disprove this, I change the code to rotate the quad independently from user-input, but dependent on deltaTime. Here are some code segments. I'm assuming it's with how I'm rotating the matrix?

CPP file:

float speed = 3.0f;
float deadZone = 0.10f;
glm::vec2 direction(0.0f);

while (!glfwWindowShouldClose(window))
{
    currentTime = glfwGetTime();
    deltaTime = (currentTime - lastUpdate) * 1000.0f;

    //Update logic
    inputHandler->tick(deltaTime);

    float inputX, inputY;
    inputX = inputHandler->getGamepad(0)->getAxes(AXIS::HORIZONTAL);
    inputY = inputHandler->getGamepad(0)->getAxes(AXIS::VERTICAL);

    float magnitude = sqrtf((inputX * inputX) + (inputY * inputY));
    if (magnitude > deadZone) //Radial dead zone detection
    {
        //Could the stutter be caused by type casting?
        direction.x += inputX * float((speed * deltaTime) / 1000.0f);
        direction.y += inputY * float((speed * deltaTime) / 1000.0f);
    }

    ... //Set vertex values and UV coord

    //Set the matrix values according to the joystick input
    glm::mat4 MVP(1.0f);
    MVP = glm::translate(MVP, glm::vec3(direction, 0.0f));
    glUniformMatrix4fv(mvpID, 1, GL_FALSE, glm::value_ptr(MVP));

    glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, 0);

    ...
}

Vertex Shader:

#version 150

in vec2 vertexPosition_modelspace;
in vec2 UV;

uniform mat4 MVP;

out vec2 vUV;

void main() {
    vUV = UV;
    gl_Position = MVP * vec4(vertexPosition_modelspace, 0, 1);
}
¿Fue útil?

Solución 2

This is extremely frustrating, but I restarted Windows and all of the problems vanished. Even the one where a call to std::cout caused Visual Studio to insert a breakpoint.

Otros consejos

Here's some debugging help so as not to stay buried in the comments:

  • Record the time step of each frame

  • When the timestep is over some given threshold that you determine is enough to cause a "jump", pause the program.

  • If the bug is coming from big time steps, track which functions take what amount of time and see if any take an unusual amount of time.

    i. If you have a profiler, use it here.

    ii. If not, record the time before and after each function and calculate the duration. Sum up these timesteps at the end of each frame so you can still find that total delta time that would indicate a jump.

  • If you trace back your bug to some library/system/other call that you have no control over, make sure you're passing those functions (and really all functions) good data.

    i. Are you getting away with using corrupt memory somewhere?

    ii. Does bug only apply only to rotations? What about translations / scales?

    iii. Does this bug happen if you just run your program with trying OpenGL things? It could be an error with, say, your windowing, where you're missing some update call or something trivial like that.

It looks like glfwGetTime uses QueryPerformanceCounter. This is not the correct API to use for timing, as it measures "CPU time" not "Wall time". It should be used to measure code performance, but not much else. You should write your own timer class using timeGetTime(), timeBeginPeriod() and timeEndPeriod() from the Windows Multimedia Timers API: http://msdn.microsoft.com/en-us/library/windows/desktop/dd743609(v=vs.85).aspx

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top