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

Subtracting shape from a bigger shape which entirely overlaps it doesn't seem to work #22

Open
andrewvarga opened this issue Mar 20, 2023 · 2 comments

Comments

@andrewvarga
Copy link

I have an example where a larger ellipse entirely overlaps a smaller one. This is how it should look like:

Screenshot 2023-03-20 at 17 34 50

Running that through flo_curves seems to produce this. Note that Subtract doesn't seem to subtract anything from the larger circle (Union and Intersect works well):
Screenshot 2023-03-20 at 17 35 45

I'm getting similar results when using rectangles instead of ellipses.

Do you have a tip as to what could be a problem? I can send some SVG / path data if that helps.

Thanks!

@Logicalshift
Copy link
Owner

Ah, sorry for the delay in responding.

There's actually a circle subtraction test in the test suite (create_doughnut() and friends) so I think the algorithm should work. The output should contain both the inner and the outer path, so a will be a Vec of two paths (this is essentially what these tests look for). See

fn create_doughnut() {
for this test - just checking that two paths are returned should be enough to verify that the subtraction worked correctly.

Could the problem you're having be to do with the winding rule? flo_curves generates output intended for use with the even-odd winding rule, and since v0.7 always produces paths going in the same direction. I think it's quite common these days for graphics libraries to default to the non-zero winding rule, which will generate a filled circle in these circumstances.

@andrewvarga
Copy link
Author

lo_curves generates output intended for use with the even-odd winding rule

Just wanted to get back to this, rendering the result with even-odd winding rule did resolve the problem indeed.
I'm going to assume that flo_curves will always return data with the even-odd winding rule in the future for all of its operations, so I'll hardcode in our renderer (let me know if it should be queried instead, I missed any references to winding rule in the documentation).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants