Operations Fail

[swill]

I have been working with this library a lot the last couple weeks. I am working on an application that draws SVG files based on dynamic input. I have been having a lot of issues with this library, but I have been having a hard time isolating the problem.

I have written a small test application to allow me to enter different configuration details to try to isolate why the library is failing. Hopefully you guys can help me figure out what is going on. If we can figure out why things are failing I am up for working on a pull request.

Alright, lets get down to business...

I wrote a test application called polycliptest and I have made everything available here: https://objects-east.cloud.ca/v1/5ef827605f884961b94881e928e7a250/polycliptest/polycliptest.zip
This includes the application cross compiled for all OS's as well as the src and a few sample SVG files.

The core of the test is based around a function I wrote which allows you to create a dynamic polygon circle. The function takes coordinates, a radius and the number of line segments for each 90º of the circle. So if segments=1, a diamond will be drawn. If segments=3, then a 12 sided 'circle' will be created. This allows me to easily create different polygons to test the polyclip library. The test basically creates a rectangle and a circle with one edge of the rectangle centered in the circle. I then run each of the polyclip operations on the two polygons. Then via the command line, I can change the number of segments which make up the circle to find cases where everything fails.

The default configuration is a simple working example to show how the test works. This is just to give a foundation for how the test works. The output for this test is polycliptest_default_ok.svg. Here are a bunch of examples for how the test application works...

All of the details of the contours and polygons being drawn are also output to the terminal for inspection.

Test Examples:

$ ./polycliptest -h
Usage of ./polycliptest:
  -add_right_circle=false: add an additional circle on the right side of the rectangle
  -radius=8: the radius of the circles at the ends of the slot
  -segments=1: the number of segments per 1/4 circle at the ends of the slot

$ ./polycliptest
=> polycliptest_default_ok.svg
=> this example works correctly

$ ./polycliptest -segments=3
=> polycliptest_seg-3_ok.svg
=> this example works correctly

$ ./polycliptest -segments=15
=> polycliptest_seg-15_fails.svg
=> this example fails on all operations

$ ./polycliptest -add_right_circle
=> polycliptest_default_add_ok.svg
=> in this example, we add an additional circle to the right of the rectangle.
=> this is working (even though it may be a bit confusing what is polygon and what is empty space)

As I said before, I am willing to put in some time to try to solve these problems and providing a pull request, but I need some help understanding why things are failing. I thought it might have to do with the points being too close together, but I proved that incorrect with the following:

$ ./polycliptest -radius=3 -segments=17  ==> OK
$ ./polycliptest -radius=3 -segments=18  ==> FAILS
$ ./polycliptest -radius=3 -segments=19  ==> OK

I am looking forward to some fresh eyes on this problem. :)

Let me know if you have any issues running my test application or if you need help compiling it (it depends on my fork of the svgo library which adds floating point support).

Cheers...

[akavel]

Please make the files available unzipped somewhere, e.g. at http://gist.github.com, for ease of browsing by me and potentially others interested in the issue. At the moment I don't know what "FAILS" means without that, so I can't say much.

[swill]

I have made everything available in a git repo here: https://github.com/swill/polycliptest

I have added more details of a failing case in the README.md file. You can also see a visual of this failing case example in this file: results/polycliptest_seg-15_fails.svg

Let me know if you have more questions. You can also grab the compiled program from the cross_compiled_bin directory for your OS if you would like to do additional tests on your own.

[swill]

I just pushed an updated version of everything which adds a grey background to the operation output polygons so it is easier to understand what the resulting polygons actually looks like.

[akavel]

I tried building polycliptest, but it fails for me with:

# github.com/swill/polycliptest
c:\prog\gopath\src\github.com\swill\polycliptest\polycliptest.go:98: canvas.FloatDecimals undefined (type *svg.SVG has no field or method FloatDecimals)
c:\prog\gopath\src\github.com\swill\polycliptest\polycliptest.go:99: canvas.StartviewUnitF undefined (type *svg.SVG has no field or method StartviewUnitF)
c:\prog\gopath\src\github.com\swill\polycliptest\polycliptest.go:111: canvas.PolygonF undefined (type *svg.SVG has no field or method PolygonF)
c:\prog\gopath\src\github.com\swill\polycliptest\polycliptest.go:112: canvas.PolygonF undefined (type *svg.SVG has no field or method PolygonF)
c:\prog\gopath\src\github.com\swill\polycliptest\polycliptest.go:114: canvas.PolygonF undefined (type *svg.SVG has no field or method PolygonF)
c:\prog\gopath\src\github.com\swill\polycliptest\polycliptest.go:148: canvas.TranslateF undefined (type *svg.SVG has no field or method TranslateF)
c:\prog\gopath\src\github.com\swill\polycliptest\polycliptest.go:149: canvas.PolygonF undefined (type *svg.SVG has no field or method PolygonF)

[swill]

Yes, this is expected. This is because my additions to the svgo library to add floating point precision are in the float branch and not master, so go get will not grab the correct code. This test depends on the float support I am adding to the svgo library, but I am developing it in its own branch so I can easily do a pull request when it is finished.

If you want to build this program, you will need to get the source of my https://github.com/swill/svgo fork and checkout the float branch.

However, you should not need to build this application from source to use it and reproduce the issue because I have cross compiled it already for you with all of the dependencies included in the ./cross_compiled_bin directory.

Let me know if you have any issues with the compiled code.

I included the source only for reference to show what I am doing. I was expecting you to use the precompiled version of the program.

[akavel]

Ok, reproduces for me, thanks. _Big thanks_ for that, it definitely proves that my attempt at fixing #3 unfortunately totally breaks stuff. I'm reverting the bad commit.

[swill]

This is a HUGE difference. Thanks so much for this. For two polygons things seem to just work. Once you start moving to 3 polygons, things start to have some issues, but I think this is related to the #3 issue you have open. I have noticed that the XOR operation probably is affected by this same problem.

So here is a working case (using the latest polyclip-go commit).

$ ./polycliptest -add_right_circle -segments=3

And then one that is not perfect (but MUCH better than before).

$ ./polycliptest -add_right_circle -segments=4

I will see if I can figure out a way to work around these issues. I will also see if I can find a way to do a work around for the #3 issue.

Thank you so much for looking into this. I am sure I can find a way to work around these smaller issues...

[swill]

BTW, I can stop posting in this issue now that it is closed if you want. I can move my troubleshooting elsewhere. I will see what I can figure out for this/these issues.

Also, these are two cases. For other segment numbers, I am seeing both success and failures and the problem is consistently only a single segment being missing (and thus changing the outcome). This is a much easier problem to try to troubleshoot, so I will see what I can come up with.

[swill]

I have just posted a workaround for #3. It is midnight here, so I am going to head to bed, but I will see if I can use the same concept used in that workaround to adapt my polycliptest code to try to mitigate the problem I am still seeing.

My workaround for the problem would basically work as follows:
Check if the polygon that the operation is being done on has multiple contours. If it does, wrap each contour in its own polygon and then do the operation on each successive polygon where the result of the previous operation is the source for the next operation.

I will do some testing of this idea tomorrow and see if this resolves my issue.