Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Float precision errors when tessellating strokes with angles close to 180 degrees. #114

Closed
nical opened this issue Jul 8, 2017 · 11 comments

Comments

@nical
Copy link
Owner

nical commented Jul 8, 2017

The code that computes normals (using intersections) in the stroke tessellator does not behave very well when the angle between two consecutive segments is very close to 180 degrees because the lines that we are intersecting are almost parallel. PR #109 fixed the same issue for angles close to zero degrees.

@johalun
Copy link

johalun commented Jul 27, 2017

Hey! How's it going with this, is there a solution in sight?

@nical
Copy link
Owner Author

nical commented Jul 27, 2017

Absolutely. Nobody had complained about it so far so I was looking into other things but I can at least easily improve the numerical stability of strokes in the 180 degree case. I'll look into that shortly.

@johalun
Copy link

johalun commented Jul 27, 2017

Great! It's totally ruining my ggez-based project's rendering so I'm super grateful if it can be fixed soon :) Thanks!!!

@johalun
Copy link

johalun commented Jul 27, 2017

I could solve it temporary by generating points a long the line and draw a dotted line instead.

@nical
Copy link
Owner Author

nical commented Jul 28, 2017

@johalun The issue is hopefully fixed in lyon 0.6.2. Could you cargo update and see if the glitch is gone?

@johalun
Copy link

johalun commented Jul 28, 2017

Seems like ggez was using a rather old version, 0.4.1. Need to update it in some places to work with 0.6.2. Seems like basic_shapes::fill_ellipse is gone.. What can I use instead?

@johalun
Copy link

johalun commented Jul 28, 2017

Ok I ended up removing the ellipse code in ggez (which I don't use) and move fill circle code from fill ellipse to fill circle. I got ggez to work with 0.6.2 and can confirm that problem is solved.

@nical
Copy link
Owner Author

nical commented Jul 28, 2017

I indeed removed fill_ellipse with the idea that using fill_circle and stretching the vertices would do, I can add that boilerplate back if need be, let me know if you miss that feature.

@johalun
Copy link

johalun commented Jul 28, 2017

I will let the ggez developers decide that and comment at ggez repo that this has been solved upstream.

@johalun
Copy link

johalun commented Jul 28, 2017

Thanks for the help!!

@nical
Copy link
Owner Author

nical commented Jul 28, 2017

Happy to help :)

@nical nical closed this as completed Jul 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants