In this case we are dealing with the visibility of 2 primitives(lines). Simple mathematics does the trick. But in the case of a complex mesh, I imagine we are not going to compare every pair of edges.
motoole2
You're absolutely right! We will talk about handling occlusions later (in 2 weeks) but the basic idea is relatively simple.
The process of rendering out triangles and other primitives (with our favorite graphics API) involves writing pixel values to a 2D memory buffer, known as the framebuffer. The framebuffer keeps track of the (R,G,B) or red/green/blue values associated with each pixel. In fact, it also keeps track of a hidden alpha channel, corresponding to the transparency of a primitive being rendered to the framebuffer. The (R,G,B) components of the framebuffer is what gets displayed by a computer monitor.
There is also another hidden memory buffer used during the rasterization process, known as the depth buffer. The depth buffer has the same spatial dimensions as a framebuffer, but keeps track of the z-values (i.e., depth values) associated with our samples. We use this depth buffer to help handle visibility.
When writing color values of a triangle/primitive to the framebuffer, your graphics API will also update the depth values in the depth buffer. Whenever we render a triangle/primitive to the framebuffer, there's a check to see whether the sample associated with that primitive has a smaller depth value than the value currently stored in the depth buffer. If it is smaller, then we can update our framebuffer, since the sample is in front of all previously rendered samples. Otherwise, we do not update the framebuffer, since that sample corresponds to a part of the triangle/primitive hidden behind some other previously-rendered primitive. This process is known as z-buffering or depth buffering.
In this case we are dealing with the visibility of 2 primitives(lines). Simple mathematics does the trick. But in the case of a complex mesh, I imagine we are not going to compare every pair of edges.
You're absolutely right! We will talk about handling occlusions later (in 2 weeks) but the basic idea is relatively simple.
The process of rendering out triangles and other primitives (with our favorite graphics API) involves writing pixel values to a 2D memory buffer, known as the framebuffer. The framebuffer keeps track of the (R,G,B) or red/green/blue values associated with each pixel. In fact, it also keeps track of a hidden alpha channel, corresponding to the transparency of a primitive being rendered to the framebuffer. The (R,G,B) components of the framebuffer is what gets displayed by a computer monitor.
There is also another hidden memory buffer used during the rasterization process, known as the depth buffer. The depth buffer has the same spatial dimensions as a framebuffer, but keeps track of the z-values (i.e., depth values) associated with our samples. We use this depth buffer to help handle visibility.
When writing color values of a triangle/primitive to the framebuffer, your graphics API will also update the depth values in the depth buffer. Whenever we render a triangle/primitive to the framebuffer, there's a check to see whether the sample associated with that primitive has a smaller depth value than the value currently stored in the depth buffer. If it is smaller, then we can update our framebuffer, since the sample is in front of all previously rendered samples. Otherwise, we do not update the framebuffer, since that sample corresponds to a part of the triangle/primitive hidden behind some other previously-rendered primitive. This process is known as z-buffering or depth buffering.