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

Regression: resolveCrossing() moves intersections #1191

Closed
iconexperience opened this issue Oct 27, 2016 · 7 comments
Closed

Regression: resolveCrossing() moves intersections #1191

iconexperience opened this issue Oct 27, 2016 · 7 comments

Comments

@iconexperience
Copy link
Contributor

iconexperience commented Oct 27, 2016

In the following example the intersections are moved during resolveCrossing() and produces a wrong result.

var path = new paper.Path({segments:[
        [100, 200],
        [300, 200],
        [300, 250],
        [150, 150],
        [150, 200],
        [350, 200],
        [350, 300],
        [100, 300]
    ], closed:true});
var res = path.resolveCrossings();
res.fullySelected = true;

Expected result:
image

Acutal result:
image

This behavior was introducded in fbb0c59 , which was introduced to fix a similar issue.

This certainly has something to do with the overlaps, but I do not fully understand what is going on.

@iconexperience
Copy link
Contributor Author

iconexperience commented Oct 27, 2016

I do not think that fbb0c59 caused this issue, it merely brought it to light.

Some testing showed that after the first call to divideLocations() in resolveCrossings() the _time values of the crossings in the middle are not correct. Before first call to divideLocations() the _time values at the intersections are as follows (crossings in the middle are at index 1 and 6):

0: 0.32635182233306964
1: 0.5841272008905138
2: 0
3: 0.5
4: 0.5
5: 0
6: 0.4158727991094863
7: 0.6736481776669302

After first call to divideLocations():

0: 0
1: 0.5841272008905138
2: 0
3: 0.5
4: 0.5
5: 0
6: 0.4158727991094863
7: 0

The correct values at index 1 and 6 would be 0.5.

A simple fix would be to run through all intersections after the first call to divideLocations() and simply call getTime() or getCurve() on each intersection. This will update the _time property to the correct value.

@iconexperience
Copy link
Contributor Author

Created pull request #1204 as a fix for this issue.

@lehni
Copy link
Member

lehni commented Nov 28, 2016

I think there should be a better solution to this... I want to think about it a bit.

@lehni
Copy link
Member

lehni commented Jan 1, 2017

@iconexperience this was a tough one to crack! But with this new code, no recalculation of curve-time should ever be required, and rescaling is correctly handled if dividing happens before and after a given location. I hope it was worth the effort for performance...

@iconexperience
Copy link
Contributor Author

@lehni
There are some problems with the new code. Here is an example (which is quite and awful path):

var p = new paper.Path({segments:[
        [256.22272245372784, 322.2911416479855, 1.3846994306732086e-7, -1.0032863428932615e-10, -0.07145907403264573, 0.000051770563516129187],
        [256.28274925468855, 322.29109816063755, 33.69934566220388, -0.024413795440409558, -0.020001069211389222, 0.000014489955333374382],
        [256.222722318658, 322.29114164808345, 0.020004442897743502, -0.000014492788977804594, -1.3846999991073972e-7, 1.0032863428932615e-10]
    ], closed:true});
p.resolveCrossings();

The variable rescaleLocs in divideLocations() is not initialized. This may be easy to fix.

@lehni
Copy link
Member

lehni commented Jan 19, 2017

Did you try the latest state of the develop branch? I already fixed this, I think.

@iconexperience
Copy link
Contributor Author

@lehni Sorry, your are correct. I tested agains an old version. This has already been fixed.

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