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

Offset function finds false intersection point on a line and scales it instead of offsetting, producing an output that's not a line. #6

Open
MatthewBlanchard opened this issue Feb 11, 2021 · 2 comments

Comments

@MatthewBlanchard
Copy link

MatthewBlanchard commented Feb 11, 2021

Capture

This seems to be where the problem lies. The rays here should be identical, and yet it's finding an intersection.

Capture

Here's the local variables right after this call in offset. From what I can tell of the inputs this curve SHOULD get moved not offset because it has parallel normals on a line that shouldn't intersect. Instead it gets passed to scaling where it gets turned into what visually looks like a line, but has tiny offsets to it's control points.

Capture

This is the bezier returned by offset. This was pretty hard to debug because visually without zooming in this looks like a line with colocated handles, but it's not and only by a few units.

@MatthewBlanchard MatthewBlanchard changed the title Offset function finds intersection point on a line and scales it instead of offsetting, producing an output that's not a line. Offset function finds false intersection point on a line and scales it instead of offsetting, producing an output that's not a line. Feb 11, 2021
@MatthewBlanchard
Copy link
Author

In some very unscientific testing I've found a value of 2e-12 works here to fix the issue.

@Logicalshift
Copy link
Owner

Hm, yes, I think a value of 2e-12 for the threshold for the divisor value does work in ray_intersects_ray. Not sure if there is a good way to choose this constant as it's a combination of the expected precision of the input values and the required precision of the output. The minimum that will fix this case is roughly 3e-14, so this gives a 100x margin for error.

In this case, we wind up with a double-whammy of loss of precision where the intersection point is calculated as very far out, so the scaling ends up being very small, which results in the control points not lining up very well.

I've checked in a change to adjust this constant.

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