<p>I am trying to make a particular kind of raytracer, but there is some strange bug occurring when I attempt to <a href="https://youtu.be/YqJKh0ntMr4" rel="nofollow noreferrer">rotate the camera</a>.</p>

<p>As you can see, there is some important distortion ocurring when the voxels are closed to the camera and I am not sure what may be cuasing it.</p>

<p>This is how I am calculating my ray:</p>

<pre><code>vec3 r = (vec3(f_coord.xy,1.f/tan(radians(40)))) //initialize the ray for a field of view of 40, f_coord is the pizel coordinate in OpenGL (-1 to 1);
r.y /= aspect_ratio // crunch the y direction to fit the aspect ratio;
vec3 dir = vec3(view_m*vec4(normalize(r),1)); //rotate the ray by the camera's rotation
r+= camera_pos; //Set the ray at the camera's position
</code></pre>

CC BY-SA 4.0
2018-06-22T05:43:45.230Z
From you video it looks like the ray direction, not ray-origin is being skewed by changes to the position. Does view_m have a translation component ? You should be multiplying normalised r with W=0 also when multiplying direction vectors by a matrix.
PaulHK
CC BY-SA 4.0
2018-06-22T05:47:49.040Z
I construct the rotation matrix using glm:rotate(mat4, float, vec3). I don't think that creates a translation component. But I agree with your diagnosis
Makogan
CC BY-SA 4.0
2018-06-22T05:48:46.900Z
I've just editted my comment, try view_m*vec4(normalize(r), 0));
PaulHK
CC BY-SA 4.0
2018-06-22T06:55:41.523Z
@PaulHK I did the suggested change however the outcome is the same
Makogan
CC BY-SA 4.0
2018-06-22T08:23:17.757Z
Presumably you start from 'r' in the direction of 'dir' ? What is the purpose of r+= camera_pos; ? Should you be starting from 'camera_pos' ?
PaulHK
CC BY-SA 4.0
2018-06-25T03:32:13.230Z
Vectors representing directions have their `w` or fourth component set to `0`. This is because directions can't be translated. If you multiply a matrix with a direction having `w = 1` it's `x,y,z` will change depending on the translation component which you obviously don't want.
gallickgunner
CC BY-SA 4.0
2018-06-25T03:38:04.640Z
That was not the issue however
Makogan
<opengl><raytracing><glsl><voxelization><debugging>
How to properly modify a ray in a raytracer to achieve camera rotation
Makogan
# How to properly modify a ray in a raytracer to achieve camera rotation

(Asked by: username_0 on 2018-06-22)

I am trying to make a particular kind of raytracer, but there is some strange bug occurring when I attempt to [rotate the camera](https://youtu.be/YqJKh0ntMr4).

As you can see, there is some important distortion ocurring when the voxels are closed to the camera and I am not sure what may be cuasing it.

This is how I am calculating my ray:

```
vec3 r = (vec3(f_coord.xy,1.f/tan(radians(40)))) //initialize the ray for a field of view of 40, f_coord is the pizel coordinate in OpenGL (-1 to 1);
r.y /= aspect_ratio // crunch the y direction to fit the aspect ratio;
vec3 dir = vec3(view_m*vec4(normalize(r),1)); //rotate the ray by the camera's rotation
r+= camera_pos; //Set the ray at the camera's position

```

**Tags:** opengl, raytracing, glsl, voxelization, debugging

> **Comments:**
> **username_1**: From you video it looks like the ray direction, not ray-origin is being skewed by changes to the position. Does view_m have a translation component ? You should be multiplying normalised r with W=0 also when multiplying direction vectors by a matrix.  
> **username_0**: I construct the rotation matrix using glm:rotate(mat4, float, vec3). I don't think that creates a translation component. But I agree with your diagnosis  
> **username_1**: I've just editted my comment, try view_m*vec4(normalize(r), 0));  
> **username_0**: @username_1 I did the suggested change however the outcome is the same  
> **username_1**: Presumably you start from 'r' in the direction of 'dir' ? What is the purpose of r+= camera_pos; ? Should you be starting from 'camera_pos' ?  
> **username_2**: Vectors representing directions have their `w` or fourth component set to `0`. This is because directions can't be translated. If you multiply a matrix with a direction having `w = 1` it's `x,y,z` will change depending on the translation component which you obviously don't want.  
> **username_0**: That was not the issue however  

---

## 0 answers

