How are the border-line cases dealt with in case of rasterization (if the line just seems to be touching the corner of the diamond)? It seems like the thickness of the line will play a role, but I am not sure how it would be determined.
I am confused why the second pixel from the left in the last row is not shaded, while the fourth pixel from the left in the second last row is.
As for the picture above, it may simply have to do with the fact that the line itself has no width, but for illustrative purposes we draw it as a thick red rectangle. In other words, if you imagine the line were a hairline, then perhaps things would be consistent. (Also: it's a slide, and not all slides are 100% pixel-accurate. :-))
stutiRastogi
Yes, got it!
Thank you professor, this was very useful!
pchatrat
How do we know if the line passes through the associated diamond? How do we get diamonds?
Even if we consider the raster grid as a coordinate system, have equation of line, how does the mathematics work? How do we get a diamond for each pixel and check if it intersects with the line? How do we discretize the line inside a pixel
Or is this whole topic a big complex mathematics process and the slide is only meant for illustrating the idea of rasterization?
Thanks!
keenan
How do we know if the line passes through the associated diamond? How do we get diamonds? ... Or is this whole topic a big complex mathematics process and the slide is only meant for illustrating the idea of rasterization?
These really are the rules defined and used for rasterization of lines in modern graphics hardware (GPUs)---see the link to Microsoft's rasterization spec given above. The point is not necessarily to make it easy to draw lines, but rather to first come up with a definition of what a "good" line should look like, and then figure out how to implement this scheme in hardware. In other words, a common approach to designing systems is:
First define the terms of success. In a perfect world, what properties should the output exhibit? At this point, you are not worried about how easy or difficult or efficient it might be to actually achieve this goal---you focus only on what's "right" and "wrong," i.e., defining what "correctness" means for your particular problem.
Once you have a precise description of the problem, then you go ahead and try to implement a solution. Perhaps you discover that the problem is way too hard, and revisit (1), but still the goal is to (i) define a specification, and then (ii) implement that specification. Here, the specification is the one provided by Microsoft (and NVIDIA, Intel, and others) on what a correct line looks like. The individual vendors may then come up with several implementations that all look quite different---but that should all produce identical output.
At least, that's how it works in a perfect world! In reality, APIs like OpenGL and Direct3D are not pixel-exact specs, i.e., two images rasterized on different hardware might differ slightly. But, they will still satisfy certain invariants (as outlined in the link).
Hope that helps.
pchatrat
Ok. Thank you for the explanation.
Passive_Bot
Would the diamond rule still be applied when drawing curves that follow specific function (for example, a circle of radius 5)? Or, does the diamond rule apply to lines only?
keenan
Modern graphics APIs (GL/D3D) do not support circles or other curved primitives; just points, lines, and triangles. Curved primitives are typically drawn either via tessellation (i.e., breaking the circle into a large number of short segments), or by a fragment program that evaluates an implicit function (i.e., how far is the sample location $(x,y)$ from satisfying the implicit circle equation $x^2 + y^2 + z^2 = r^2$?). Still, it would be interesting to see whether, say, the diamond rule yields "nice" circles.
nmrrs
So just to be clear, it's not like modern GPUs are literally doing the diamond check, they're matching the results of the diamond check as closely as possible while still efficiently rendering the lines?
keenan
@nmrrs: Modern GPUs are responsible for implementing some algorithm whose output passes the diamond test. That does not mean this algorithm has to proceed by walking through the image pixel-by-pixel checking the diamond geometry explicitly.
The reality of the situation is that there is still a little flexibility in what vendors are forced to implement. Roughly speaking, anything that's not spelled out in black-and-white in the OpenGL spec (somewhat like our own Scotty3D User Guide) is up to the developer to decide (much like your last assignment!).
How are the border-line cases dealt with in case of rasterization (if the line just seems to be touching the corner of the diamond)? It seems like the thickness of the line will play a role, but I am not sure how it would be determined. I am confused why the second pixel from the left in the last row is not shaded, while the fourth pixel from the left in the second last row is.
Great questions. You can get a detailed look at the rasterization rules (courtesy Microsoft) here: https://msdn.microsoft.com/en-us/library/windows/desktop/cc627092(v=vs.85).aspx
As for the picture above, it may simply have to do with the fact that the line itself has no width, but for illustrative purposes we draw it as a thick red rectangle. In other words, if you imagine the line were a hairline, then perhaps things would be consistent. (Also: it's a slide, and not all slides are 100% pixel-accurate. :-))
Yes, got it! Thank you professor, this was very useful!
How do we know if the line passes through the associated diamond? How do we get diamonds? Even if we consider the raster grid as a coordinate system, have equation of line, how does the mathematics work? How do we get a diamond for each pixel and check if it intersects with the line? How do we discretize the line inside a pixel
Or is this whole topic a big complex mathematics process and the slide is only meant for illustrating the idea of rasterization?
Thanks!
These really are the rules defined and used for rasterization of lines in modern graphics hardware (GPUs)---see the link to Microsoft's rasterization spec given above. The point is not necessarily to make it easy to draw lines, but rather to first come up with a definition of what a "good" line should look like, and then figure out how to implement this scheme in hardware. In other words, a common approach to designing systems is:
First define the terms of success. In a perfect world, what properties should the output exhibit? At this point, you are not worried about how easy or difficult or efficient it might be to actually achieve this goal---you focus only on what's "right" and "wrong," i.e., defining what "correctness" means for your particular problem.
Once you have a precise description of the problem, then you go ahead and try to implement a solution. Perhaps you discover that the problem is way too hard, and revisit (1), but still the goal is to (i) define a specification, and then (ii) implement that specification. Here, the specification is the one provided by Microsoft (and NVIDIA, Intel, and others) on what a correct line looks like. The individual vendors may then come up with several implementations that all look quite different---but that should all produce identical output.
At least, that's how it works in a perfect world! In reality, APIs like OpenGL and Direct3D are not pixel-exact specs, i.e., two images rasterized on different hardware might differ slightly. But, they will still satisfy certain invariants (as outlined in the link).
Hope that helps.
Ok. Thank you for the explanation.
Would the diamond rule still be applied when drawing curves that follow specific function (for example, a circle of radius 5)? Or, does the diamond rule apply to lines only?
Modern graphics APIs (GL/D3D) do not support circles or other curved primitives; just points, lines, and triangles. Curved primitives are typically drawn either via tessellation (i.e., breaking the circle into a large number of short segments), or by a fragment program that evaluates an implicit function (i.e., how far is the sample location $(x,y)$ from satisfying the implicit circle equation $x^2 + y^2 + z^2 = r^2$?). Still, it would be interesting to see whether, say, the diamond rule yields "nice" circles.
So just to be clear, it's not like modern GPUs are literally doing the diamond check, they're matching the results of the diamond check as closely as possible while still efficiently rendering the lines?
@nmrrs: Modern GPUs are responsible for implementing some algorithm whose output passes the diamond test. That does not mean this algorithm has to proceed by walking through the image pixel-by-pixel checking the diamond geometry explicitly.
The reality of the situation is that there is still a little flexibility in what vendors are forced to implement. Roughly speaking, anything that's not spelled out in black-and-white in the OpenGL spec (somewhat like our own Scotty3D User Guide) is up to the developer to decide (much like your last assignment!).