1

When camera is moved around, why are my starting rays are still stuck at origin 0, 0, 0 even though the camera position has been updated?

It works fine if I start the program and my camera position is at default 0, 0, 0. But once I move my camera for instance pan to the right and click some more, the lines are still coming from 0 0 0 when it should be starting from wherever the camera is. Am I doing something terribly wrong? I've checked to make sure they're being updated in the main loop. I've used this code snippit below referenced from:
picking in 3D with ray-tracing using NinevehGL or OpenGL i-phone

// 1. Get mouse coordinates then normalize
float x = (2.0f * lastX) / width - 1.0f;
float y = 1.0f - (2.0f * lastY) / height;

// 2. Move from clip space to world space
glm::mat4 inverseWorldMatrix = glm::inverse(proj * view);
glm::vec4 near_vec = glm::vec4(x, y, -1.0f, 1.0f);
glm::vec4 far_vec = glm::vec4(x, y, 1.0f, 1.0f);
glm::vec4 startRay = inverseWorldMatrix * near_vec;
glm::vec4 endRay = inverseWorldMatrix * far_vec;

// perspective divide
startR /= startR.w;
endR /= endR.w;

glm::vec3 direction = glm::vec3(endR - startR);

// start the ray points from the camera position
glm::vec3 startPos = glm::vec3(camera.GetPosition());
glm::vec3 endPos = glm::vec3(startPos + direction * someLength);

The first screenshot I click some rays, the 2nd I move my camera to the right and click some more but the initial starting rays are still at 0, 0, 0. What I'm looking for is for the rays to come out wherever the camera position is in the 3rd image, ie the red rays sorry for the confusion, the red lines are supposed to shoot out and into the distance not up.

3d ray casting mouse clicks

// and these are my matrices
// projection
glm::mat4 proj = glm::perspective(glm::radians(camera.GetFov()), (float)width / height, 0.1f, 100.0f);
// view
glm::mat4 view = camera.GetViewMatrix(); // This returns glm::lookAt(this->Position, this->Position + this->Front, this->Up);
// model
glm::mat4 model = glm::translate(glm::mat4(1.0f), glm::vec3(0.0f, 0.0f, 0.0f));

1 Answers1

2

Its hard to tell where in the code the problem lies. But, I use this function for ray casting that is adapted from code from scratch-a-pixel and learnopengl:

vec3 rayCast(double xpos, double ypos, mat4 projection, mat4 view) {
    // converts a position from the 2d xpos, ypos to a normalized 3d direction
    float x = (2.0f * xpos) / WIDTH - 1.0f;
    float y = 1.0f - (2.0f * ypos) / HEIGHT;
    float z = 1.0f;
    vec3 ray_nds = vec3(x, y, z);
    vec4 ray_clip = vec4(ray_nds.x, ray_nds.y, -1.0f, 1.0f);
    // eye space to clip we would multiply by projection so
    // clip space to eye space is the inverse projection
    vec4 ray_eye = inverse(projection) * ray_clip;
    // convert point to forwards
    ray_eye = vec4(ray_eye.x, ray_eye.y, -1.0f, 0.0f);
    // world space to eye space is usually multiply by view so
    // eye space to world space is inverse view
    vec4 inv_ray_wor = (inverse(view) * ray_eye);
    vec3 ray_wor = vec3(inv_ray_wor.x, inv_ray_wor.y, inv_ray_wor.z);
    ray_wor = normalize(ray_wor);
    return ray_wor;
}

where you can draw your line with startPos = camera.Position and endPos = camera.Position + rayCast(...) * scalar_amount.

jackw11111
  • 1,457
  • 1
  • 17
  • 34
  • Yeah this is so bizarre. I've used this as well and it's doing the same thing. I'm moving my camera all over the place, yet the starting rays are all coming from the same point at origin. It's like now I have a spikey ball.. – Fullstack_Developer Dec 06 '21 at 17:18
  • 1
    Ugh... I'm such a $#@! idiot. Turns out both methods work fine. My problem came from updating the buffer data for ``glBufferSubData(...)``. I was using ``glBufferSubData(GL_ARRAY_BUFFER, coordinates.size() * sizeof(glm::vec3), sizeof(glm::vec3),&endRay);`` which explains why I kept starting all my rays at the same position. Fixing to ``glBufferSubData(GL_ARRAY_BUFFER, sizeof(startRay), coordinates.size() * sizeof(startRay), (const void*)(coordinates.data()));`` now shoots rays wherever my camera is. I can't believe I spent two weeks on this I need to lay down now... – Fullstack_Developer Dec 06 '21 at 19:53
  • I am constantly making that mistake when using `glBuffer...` calls. I have come to expect it whenever something isn't drawing properly, although I didn't first suspect it was the problem here for some reason... Ah well, at least it is sorted now! :) – jackw11111 Dec 06 '21 at 23:45