10-09-2020, 08:55 PM
(10-09-2020, 08:09 PM)Ofnuts Wrote:(10-09-2020, 11:31 AM)Ottia Tuota Wrote: A word of warning: The running time grows fast with the number of slicing lines (or guides). That is why I prevented the usage of more than 8 lines. Another advantage of this is that the number of created new paths also grows fast, and it is good to have some limit. If you want to change that number 8, find and edit in the code the line
MAX_SLICE_LINES = 8 # Maximum number of slicing lines allowed
But please, do not go over 10.
If you find some case where the plugins act strangely, please report. The code is a little messy, I admit, and I may have missed something.
I'm surprised. All that would be required is solving 3rd degree equations which is pretty fast. Your warning seems to indicate that the computing time is somehow quadratic or worse?
I don't even try to pretend that I understand this problem. But I believe the difficulty comes from the number of the generated new paths, the slices.
Imagine a path. Imagine its bounding box. Then imagine that we put there a large number of slicing lines, criss-crossing the bounding box. They slice the bounding box into a large number of small regions, and the path becomes sliced accordingly into small slices. The number of the slices grows fast with the number of the slicing lines. I don't know how fast it grows, but it could be quadratic(??). I seem to remember vaguely that I have seen a theorem about this years ago, but I don't remember the exact result.
And it is not only the solving equations. It is also Gimp drawing the generated paths, and their number also grows fast. I have not done any systematic testing, only some experiments, but in one case there were 43 new paths. (I don't remember how many slicing lines there were.)
So, I think the problem comes from the nature of the task, the number of the generated slices.