将多条抗锯齿线连接在一起
我从维基百科和其他地方的伪代码实现/复制了 wu 线算法。
当绘制正弦波时,它会在线条从 y 主导变为 x 主导(反之亦然)的点处崩溃。 (我没有复制端点代码,因为它看起来很糟糕,而且我不需要它们来实现我的目的。)
有谁知道这个问题的解决方案问题?如果没有,我会自己修改算法以使其正常工作。我只是好奇是否有人遇到过这个问题并且确切地知道如何解决它。是否可以在线路全局不相互了解的情况下实施?或者这就是绘图API实现moveto和lineto函数的原因?
I implemented/copied the wu line algorithm from pseudo-code on wiki-pedia and other places.
When drawing a sine wave it breaks down at the point where the line changes from y dominant to x dominant (or vice versa). (I did not copy the endpoint code because it looks terrible and I do not need them for my purposes. )
Does anyone know a solution for this issue? If not I will modify the algorithm myself to get it to work. I am just curious if someone else has run into this and knows exactly how to fix it. Is it possible to implement without the lines being globally aware of each other? Or is this why drawing API's implement moveto and lineto functions?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果性能不是一个大问题,您可以采取更简单的方法来绘制抗锯齿线,例如:
根据您正在开发的语言或操作系统,可能有内置的功能来简化这一点。
或者,您可以计算线条覆盖每个像素的哪一部分(通过将像素正方形与线条相交)来计算像素值,使像素强度相对于线条覆盖的像素区域部分。
If performance is not a big issue you can take a more naive approach to drawing anti-aliased lines, e.g.:
Depending on what language or OS you're developing with there may be built in functionality to simplying this.
Alternatively you can calculate what portion of each pixel is covered by your line (by intersecting the pixel square with the line) to calculate the pixels value, make the pixel intensity relative to the portion of the pixel area covered by the line.
我只是想跟进此事并结束它。我以为我已经从网站上发布的算法中删除了端点代码。然而,我犯了一个错误,没有将其全部删除,所以这就是线路断裂的原因。这是最终结果:
如果您仔细观察,您可以看到当线条从 y 主导变为 x 主导时,强度会略有跳跃占主导地位,反之亦然。这也是因为该线的长度小于一像素。我想以更高分辨率画一条线,然后向下采样会产生更高质量的结果,就像 Guy Sirton 所建议的那样。但这对于我的目的来说已经足够了。
I just wanted to follow up with this and close it out. I thought I had removed the endpoint code from the posted algorithm on the website. However, I made a mistake and did not remove all of it so that is why the lines were breaking. Here is the final result:
If you look closely enough you can see the intensity jump a bit when the lines change from being y-dominant to x dominant and vice versa. It is also because the line is less than one pixel long. I suppose drawing a line at a higher resolution and then down sampling would produce a higher quality result like Guy Sirton suggested. But this is good enough for my purposes.