For that "Assume integer coordinates are at pixel centers", I assume that if they are not at centers, we should find the first and last point that is on the middle line of that grid and do the algorithm right?
And I am interested if R, G, B difference will matter in this case.
Thanks for the intro today and thanks for the coming answers.
motoole2
A rasterization rule or line drawing algorithm does not necessarily require the end points of the line to be at the pixel centers. The ends could certainly be represented with floating-point coordinates. However, one of the disadvantages is that this requires performing floating-point arithmetic during the rasterization procedure. This becomes computationally expensive, especially if you need to draw many lines!
If we constrain lines to start and end at the center of pixels (represented by integer coordinates), it is possible to implement the rasterization algorithm without any floating-point arithmetic. Now, the pseudocode above assumes u is an integer but v is a float. But this pseudocode can be optimized to only use integer arithmetic instead (much better)! The optimized version is Bresenham's algorithm.
The line could also have R, G, B value associated with it. In this case, one could simply change the draw command to include an R, G, B value to write to the corresponding pixel, i.e., draw(u, round(v), r, g, b).
SlimShady
What should we do if there is more change in y than x? Thanks :)
tplatina
I think you can find the answer from the link above that is about Bresenham's line algorithm. There is a section for all cases. If I understand that correct, it should be iterating from v1 to v2 instead of u1 to u2, and the step will be 1/s.
motoole2
Good answer! tplatina's answer is correct. If the slope is too large, then the code should iterate from v1 to v2.
Also the pseudocode in this slide assumes that u2 > u1. If u2 < u1, then the code needs to be changed somewhat as well, by adjusting the parameters to the for loop:
for (u = u1; u>=u2; u--) {...}.
elenagong
I was confused about the code in class. Now get clear because the round(v) is very important for the pixels we want.
motoole2
Yup! We brushed through this rather quickly. That's why it is a good idea to review the slides on your own time as well, and ask questions here. :-) And you're right; round(v) is important, as the draw(u,v) function only accepts integer arguments.
For that "Assume integer coordinates are at pixel centers", I assume that if they are not at centers, we should find the first and last point that is on the middle line of that grid and do the algorithm right? And I am interested if R, G, B difference will matter in this case. Thanks for the intro today and thanks for the coming answers.
A rasterization rule or line drawing algorithm does not necessarily require the end points of the line to be at the pixel centers. The ends could certainly be represented with floating-point coordinates. However, one of the disadvantages is that this requires performing floating-point arithmetic during the rasterization procedure. This becomes computationally expensive, especially if you need to draw many lines!
If we constrain lines to start and end at the center of pixels (represented by integer coordinates), it is possible to implement the rasterization algorithm without any floating-point arithmetic. Now, the pseudocode above assumes u is an integer but v is a float. But this pseudocode can be optimized to only use integer arithmetic instead (much better)! The optimized version is Bresenham's algorithm.
The line could also have R, G, B value associated with it. In this case, one could simply change the draw command to include an R, G, B value to write to the corresponding pixel, i.e., draw(u, round(v), r, g, b).
What should we do if there is more change in y than x? Thanks :)
I think you can find the answer from the link above that is about Bresenham's line algorithm. There is a section for all cases. If I understand that correct, it should be iterating from v1 to v2 instead of u1 to u2, and the step will be 1/s.
Good answer! tplatina's answer is correct. If the slope is too large, then the code should iterate from
v1tov2.Also the pseudocode in this slide assumes that
u2 > u1. Ifu2 < u1, then the code needs to be changed somewhat as well, by adjusting the parameters to theforloop:for (u = u1; u>=u2; u--) {...}.I was confused about the code in class. Now get clear because the round(v) is very important for the pixels we want.
Yup! We brushed through this rather quickly. That's why it is a good idea to review the slides on your own time as well, and ask questions here. :-) And you're right;
round(v)is important, as thedraw(u,v)function only accepts integer arguments.