![]() OpenGL by itself is not familiar with the concept of a camera, but we can try to simulate one by moving all objects in the scene in the reverse direction, giving the illusion that we are moving. Often, you just have to click “invert normals” in your 3D modeler (which will, in fact, invert vertices, and thus normals) and everything is just fine.In the previous chapter we discussed the view matrix and how we can use the view matrix to move around the scene (we moved backwards a little). But it’s generally worth the little additional work. This means that is you invert two vertices in your buffer, you’ll probably end up with a hole. This comes at a cost, unfortunately : the orientation of the triangle is implicit. The GPU computes the normal of the triangle (using the cross product, remember ?) and checks whether this normal is oriented towards the camera or not. The best thing is that it’s very easy to check this. If it’s in front, display the triangle if it’s behind, and the mesh is closed, and we’re not inside the mesh, then there will be another triangle in front of it, and nobody will notice anything, except that everything will be faster : 2 times less triangles on average ! The idea is to let the GPU check if the camera is behind, or in front of, the triangle. As a matter of fact, in a usual application, you are never inside a cube. This can seem obvious, but this remark actually opens an opportunity for optimisation. ![]() Now that you can freely move around, you’ll notice that if you go inside the cube, polygons are still displayed. Up // Head is up (set to 0,-1,0 to look upside-down) Position + direction, // and looks here : at the same position, plus "direction" ViewMatrix = glm :: lookAt ( position, // Camera is here ProjectionMatrix = glm :: perspective ( glm :: radians ( FoV ), 4.0 f / 3.0 f, 0.1 f, 100.0 f ) // Camera matrix Projection matrix : 45° Field of View, 4:3 ratio, display range : 0.1 unit 100 units If you have a slow computer, and you run at 20 fps, you’d move of 1/20 * speed units in 1 second, so 1*speed in 1 second.If you have a fast computer, and you run at 60 fps, you’d move of 1/60 * speed units in 1 frame, so 1*speed in 1 second.Since having a better computer is not an excuse for going faster, you have to scale the distance by the “time since the last frame”, or “deltaTime”. If you have a slow computer, and you run at 20 fps, you’d move of 20*speed units in 1 second.If you have a fast computer, and you run at 60 fps, you’d move of 60*speed units in 1 second.You don’t want to move from 1 unit each frame for a simple reason : The only special thing here is the deltaTime. If ( glfwGetKey ( GLFW_KEY_UP ) = GLFW_PRESS ) So let’s define the “right” vector : its Y coordinate is 0 since it’s horizontal, and its X and Z coordinates are just like in the figure above, but with the angles rotated by 90°, or Pi/2 radians. You can check this by putting your arm horizontal, and looking up, down, in any direction. In our case, the only constant is that the vector goes to the right of the camera is always horizontal. Here is an example of to cameras with the same position, the same target, but a different up: Notice that “up” isn’t always towards +Y : if you look down, for instance, the “up” vector will be in fact horizontal. Now we want to compute the “up” vector reliably. The formula above is just the generalisation to 3D. This is a standard computation, but if you don’t know about cosine and sinus, here’s a short explanation : Glm :: vec3 direction ( cos ( verticalAngle ) * sin ( horizontalAngle ), sin ( verticalAngle ), cos ( verticalAngle ) * cos ( horizontalAngle ) ) Direction : Spherical coordinates to Cartesian coordinates conversion
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |