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

algorithm comparison #123

Open
daef opened this issue Mar 19, 2020 · 14 comments
Open

algorithm comparison #123

daef opened this issue Mar 19, 2020 · 14 comments

Comments

@daef
Copy link

daef commented Mar 19, 2020

not really an issue, but I wanted to dump a reference here too:

I made a small comparison between some boolean operation algorithms and
wanted to share the results: https://daef.github.io/poly-bool-comparison/

preview

@w8r
Copy link
Owner

w8r commented Mar 19, 2020

Great thing! can you please explain the metrics? I didn't understand the abbrevations

@daef
Copy link
Author

daef commented Mar 19, 2020

I'd like to forward you to the graphicsmagick documentation but it's not very helpful.

Wikipedia got it partially covered thou: MAE, RMSE, PSNR

@w8r
Copy link
Owner

w8r commented Mar 19, 2020

Thanks a lot!

@Llorx
Copy link

Llorx commented Jun 17, 2020

Really really good tool. Thank you.

@daef
Copy link
Author

daef commented Jun 18, 2020

have you found a new use case for this hack @Llorx ? i thought it doesn't do much on its own so there's no real benefit to make it more reusable.

@Llorx
Copy link

Llorx commented Jun 18, 2020

@daef Just to see the problems some libraries have with certain polygons. The red/green error deviation thingy was really useful. I was looking for a library with good rectangle handling.

@daef
Copy link
Author

daef commented Jun 19, 2020

i guess when there are 'just' axis aligned rects one could do much better than with a generic polygon lib, is performance your main concern or are you looking for something correct/robust? :)

EDIT: reopened, i accidentaly closed the issue

@daef daef closed this as completed Jun 19, 2020
@daef daef reopened this Jun 19, 2020
@Llorx
Copy link

Llorx commented Jun 19, 2020

Both, correctness and performant. I need to merge about 200 hundred rectangles into a single polygon in less than 16ms (for drawing to a canvas at 60 fps) but I also need for it to be drawn correctly. I thought that this new algorithm will help, but nope. I lose a lot of frames, so forgot about this solution and now I'm looking for webgl.

@w8r
Copy link
Owner

w8r commented Jun 19, 2020

Was it too slow or incorrect?

@w8r
Copy link
Owner

w8r commented Jun 19, 2020

Seems like rasterizing is a more convenient approach in your case.

@Llorx
Copy link

Llorx commented Jun 19, 2020

Yeah, maybe I could draw to a canvas and extract the result image as a mask. That's the next step if webgl gets too complicated haha.

In this case it was slow and incorrect, but the slowness I think is because I'm asking too much, and worse if looking for a JavaScript script instead of native code. About the correctness, I was getting some weird edges. This is the black mask image where you can see all the rectangles/squares, some of them overlap:
image

When the algo was passed with union, I was getting something like this (drawn with paint, but you get the point):
image

By the way, I noticed that is impossible for a normal computer in the browser to have a decent union performance with that amount of rectangles, so I forgot about it.

@w8r
Copy link
Owner

w8r commented Jun 19, 2020

Yes, with "cascading" approach it's very heavy. I have faced that problem before in https://github.com/w8r/ploygon-offset

But if you are dealing with rectangles and they are axis-aligned as I see on the picture, it only makes sense to go for raster approach.

@daef
Copy link
Author

daef commented Jun 24, 2020

I guess loading the rects into the GPU encoded as texture and writing a simple shader should do the trick, 200 rects doesnt sound too bad. Maybe give this or that a shot :)

@Llorx
Copy link

Llorx commented Jun 24, 2020

I guess loading the rects into the GPU encoded as texture and writing a simple shader should do the trick, 200 rects doesnt sound too bad. Maybe give this or that a shot :)

Pretty nice, thank you!

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

3 participants