Skip to main content
Some grammar, typo and link fixes, replaced some links
Source Link
Theraot
  • 28.2k
  • 4
  • 55
  • 83
  • Model space (sometimes called "Object space"): The coordinates inside the model.
  • World space: The coordinates in the world.
  • Camera space: The coordinates in respectrelative to the camera.
  • Screen space (sometimes called "Window space" or "Device space"): The coordinates for the screen.
  • Model space (sometimes called "Object space"): The coordinates inside the model.
  • World space: The coordinates in the world.
  • Camera space: The coordinates in respect to the camera.
  • Screen space (sometimes called "Window space" or "Device space"): The coordinates for the screen.
  • Model space (sometimes called "Object space"): The coordinates inside the model.
  • World space: The coordinates in the world.
  • Camera space: The coordinates relative to the camera.
  • Screen space (sometimes called "Window space" or "Device space"): The coordinates for the screen.
Some grammar, typo and link fixes, replace possible warez link
Source Link
  • Model space (Sometimessometimes called "Object space"): The coordinates inside the model.
  • World space: The coordinates in the world.
  • Camera space: The coordinates in respect to the camera.
  • Screen space (Sometimessometimes called "Window space" or "Device space"): The coordinates for the screen.
  • Model matrix (Sometimessometimes called “Object matrix”): from Model space to World space. You use this matrix to place objects in the world.
  • View matrix (Sometimessometimes called “Camera Transformation matrix”): from World space to Camera space.
  • Projection Matrix (Sometimes called “Camera Projection matrix”): from Camera space to Clip space.

See also Homogeneous Coordinates and Transformation MatricesHomogeneous Coordinates and Transformation Matrices.

Finally, the conversion from Normalized Device space to Screen space is controlled by the view portviewport (and depth range). Finally leaving us with a 2D space in pixels.

We also want to model a virtual camera. The simplest perspective virtual cameras have a position in the world, an orientation, and a field of view (will get to this one later).

  • Position:

    We are going to represent the position of the camera is by using a vector in World space.

  • Rotation:

    Using director (Euler) angles is going to be easier to control for first person games. In particular for those games where where there is a clear up and down. Which are most of them.

    If we need to compose rotations, interpolate rotations, or we want controls for open space (with no clear up and down), we want quaternions. And yes, you can have the input be director angles and then create a quaternion from those angles. Note: Similar to matrices, you also compose quaternions by multiplication. And similar to matrices, the order matters.

    If you want a camera that looks at something (for example a third person camera), you can use a Look-at matrix. You may want to convert it to quaternions for interpolation if needneeded to animate the camera rotating to look at something.

    You build your Look-at matrix with a forward vector which points in the direction towards where the camera is looking at, and an up vector. If you only had the forward vector, the camera rotation still havehas one degree of freedom (rotating around the forward vector)... The up vector fixes that. Thus, remember that the up vector and forward vector should not be in the same direction. Ideally they are perpendicular.

If you write your Vertex shader…shader, you could decide to not have a Model matrix, View matrix and Projection matrix. You can do thingthings differently. For example, for Ray tracing.

If you want to do skeleton animation, you would use transformation to moves parts in respect to others. That is also done with matrices, quaternions, etc. Perhaps a Look-at matrix can resultbe useful to make a character point its arm in a particular direction. You may also be interested in inverse kinematics.

I learned the old fashion way, with the red bookred book. It should serve you well as reference and to clear up concepts.

For learning to code shaders, aside from the above, I found useful Shadertoy and Shaderific useful.

By the way, you are going to want a library that handles setting up the view portviewport (window or full-screen) and handling input... many (old) tutorials use glut. If you see glut (and you are going to) go use freeglut, it is a drop-in replacement... why?

Other alternatives include glfw or sdl. See GLUT-like Windowing, GUI, and Media Control toolkits. I'm currently onin the glfw camp.

Note: OpenGL code is relatively easy to translate from a language to another. In particular if you are using a portable library to handle the setup of the view portviewport. Do not be afraid of reading a tutorial for a different programming language than the one you are using. In fact, I would argue that learning WebGL is a good idea. Despite it being a different API, it is very close. I recommend the MDN WebGl tutorial.

  • Model space (Sometimes called "Object space"): The coordinates inside the model.
  • World space: The coordinates in the world.
  • Camera space: The coordinates respect to the camera.
  • Screen space (Sometimes called "Window space" or "Device space"): The coordinates for the screen.
  • Model matrix (Sometimes called “Object matrix”): from Model space to World space. You use this matrix to place objects in the world.
  • View matrix (Sometimes called “Camera Transformation matrix”): from World space to Camera space.
  • Projection Matrix (Sometimes called “Camera Projection matrix”): from Camera space to Clip space.

See also Homogeneous Coordinates and Transformation Matrices.

Finally the conversion from Normalized Device space to Screen space is controlled by the view port (and depth range). Finally leaving us with a 2D space in pixels.

We also want to model a virtual camera. The simplest perspective virtual cameras have a position in the world, an orientation, a field of view (will get to this one later).

  • Position:

    We are going to represent the position of the camera is by using a vector in World space.

  • Rotation:

    Using director (Euler) angles is going to be easier to control for first person games. In particular for those games where where there is a clear up and down. Which are most of them.

    If we need to compose rotations, interpolate rotations, or we want controls for open space (with no clear up and down), we want quaternions. And yes, you can have the input be director angles and then create a quaternion from those angles. Note: Similar to matrices, you also compose quaternions by multiplication. And similar to matrices, the order matters.

    If you want a camera that looks at something (for example a third person camera), you can use a Look-at matrix. You may want to convert it to quaternions for interpolation if need to animate the camera rotating to look at something.

    You build your Look-at matrix with a forward vector which points in the direction towards where the camera is looking at, and an up vector. If you only had the forward vector, the camera rotation still have one degree of freedom (rotating around the forward vector)... The up vector fixes that. Thus, remember that the up vector and forward vector should not be in the same direction. Ideally they are perpendicular.

If you write your Vertex shader… you could decide to not have Model matrix, View matrix and Projection matrix. You can do thing differently. For example, for Ray tracing.

If you want to do skeleton animation, you would use transformation to moves parts respect to others. That is also done with matrices, quaternions, etc. Perhaps a Look-at matrix can result useful to make a character point its arm in a particular direction. You may also be interested in inverse kinematics.

I learned the old fashion way, with the red book. It should serve you well as reference and to clear up concepts.

For learning to code shaders, aside from the above, I found useful Shadertoy and Shaderific.

By the way, you are going to want a library that handles setting up the view port (window or full-screen) and handling input... many (old) tutorials use glut. If you see glut (and you are going to) go use freeglut, it is a drop-in replacement... why?

Other alternatives include glfw or sdl. See GLUT-like Windowing, GUI, and Media Control toolkits. I'm currently on glfw camp.

Note: OpenGL code is relatively easy to translate from a language to another. In particular if you are using a portable library to handle the setup of the view port. Do not be afraid of reading a tutorial for a different programming language than the one you are using. In fact, I would argue that learning WebGL is a good idea. Despite it being a different API, it is very close. I recommend the MDN WebGl tutorial.

  • Model space (sometimes called "Object space"): The coordinates inside the model.
  • World space: The coordinates in the world.
  • Camera space: The coordinates in respect to the camera.
  • Screen space (sometimes called "Window space" or "Device space"): The coordinates for the screen.
  • Model matrix (sometimes called “Object matrix”): from Model space to World space. You use this matrix to place objects in the world.
  • View matrix (sometimes called “Camera Transformation matrix”): from World space to Camera space.
  • Projection Matrix (Sometimes called “Camera Projection matrix”): from Camera space to Clip space.

See also Homogeneous Coordinates and Transformation Matrices.

Finally, the conversion from Normalized Device space to Screen space is controlled by the viewport (and depth range). Finally leaving us with a 2D space in pixels.

We also want to model a virtual camera. The simplest perspective virtual cameras have a position in the world, an orientation, and a field of view (will get to this one later).

  • Position:

    We are going to represent the position of the camera by using a vector in World space.

  • Rotation:

    Using director (Euler) angles is going to be easier to control for first person games. In particular for those games where there is a clear up and down. Which are most of them.

    If we need to compose rotations, interpolate rotations, or we want controls for open space (with no clear up and down), we want quaternions. And yes, you can have the input be director angles and then create a quaternion from those angles. Note: Similar to matrices, you also compose quaternions by multiplication. And similar to matrices, the order matters.

    If you want a camera that looks at something (for example a third person camera), you can use a Look-at matrix. You may want to convert it to quaternions for interpolation if needed to animate the camera rotating to look at something.

    You build your Look-at matrix with a forward vector which points in the direction towards where the camera is looking at, and an up vector. If you only had the forward vector, the camera rotation still has one degree of freedom (rotating around the forward vector)... The up vector fixes that. Thus, remember that the up vector and forward vector should not be in the same direction. Ideally they are perpendicular.

If you write your Vertex shader, you could decide to not have a Model matrix, View matrix and Projection matrix. You can do things differently. For example, for Ray tracing.

If you want to do skeleton animation, you would use transformation to moves parts in respect to others. That is also done with matrices, quaternions, etc. Perhaps a Look-at matrix can be useful to make a character point its arm in a particular direction. You may also be interested in inverse kinematics.

I learned the old fashion way, with the red book. It should serve you well as reference and to clear up concepts.

For learning to code shaders, aside from the above, I found Shadertoy and Shaderific useful.

By the way, you are going to want a library that handles setting up the viewport (window or full-screen) and handling input... many (old) tutorials use glut. If you see glut (and you are going to) go use freeglut, it is a drop-in replacement... why?

Other alternatives include glfw or sdl. See GLUT-like Windowing, GUI, and Media Control toolkits. I'm currently in the glfw camp.

Note: OpenGL code is relatively easy to translate from a language to another. In particular if you are using a portable library to handle the setup of the viewport. Do not be afraid of reading a tutorial for a different programming language than the one you are using. In fact, I would argue that learning WebGL is a good idea. Despite it being a different API, it is very close. I recommend the MDN WebGl tutorial.

added 2 characters in body
Source Link
Theraot
  • 28.2k
  • 4
  • 55
  • 83

The View matrix converts from World space to ClipCamera space. The Look-at matrix is usually used for the Camera Rotation matrix. And the Camera Transformation matrix is the Camera Position matrix composed with the Camera Rotation matrix.

The View matrix converts from World space to Clip space. The Look-at matrix is usually used for the Camera Rotation matrix. And the Camera Transformation matrix is the Camera Position matrix composed with the Camera Rotation matrix.

The View matrix converts from World space to Camera space. The Look-at matrix is usually used for the Camera Rotation matrix. And the Camera Transformation matrix is the Camera Position matrix composed with the Camera Rotation matrix.

edited body
Source Link
Theraot
  • 28.2k
  • 4
  • 55
  • 83
Loading
added 8 characters in body
Source Link
Theraot
  • 28.2k
  • 4
  • 55
  • 83
Loading
Source Link
Theraot
  • 28.2k
  • 4
  • 55
  • 83
Loading