Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[FIX] Coplanarity test - uncertainty issue - see https://github.com/g… #203
base: main
Are you sure you want to change the base?
[FIX] Coplanarity test - uncertainty issue - see https://github.com/g… #203
Changes from all commits
29b81f5
2a5b549
1863162
7371d72
dd9350b
40332a3
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mind explaining the rationale behind these calculations? Including the thinking behind "planeCenter"? It seems as though the distance to an arbitrarily chosen point on the plane will have a significant impact.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't want to use an epsilon larger than COPLANAR_EPSILON, that's why we use the
Math.max
Please look at the picture posted with #199 (comment) for the annotations:
We scale epsilon (
e
) to get epsilon scaled (E
) by IP / AB.IM
like in my draft we useIE
orIF
, withE
andF
start and end points of the edge_edge
This computation is from the Thales theorem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks I've taken a look at the diagrams and I understand the intent. Basically a very small edge leads to more uncertainty in the true plane position so you want to use a large epsilon when checking distances to such a plane. And you're effectively scaling the amount that we scale the epsilon by the distance to the point used to generate the plane since we know that point is exactly correct.
This may be a bit difficult to describe effectively but it would nice to have some comments in the code to describe what's happening here and why. Even if it includes a link to this comment thread for context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @gkjohnson I have added some comments and a link to the Github issue in the last commit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This bit makes me uncomfortable still, I think. It's something that could fix your case and break others. Likely what's happening is that it's shifting vertices which helps change the subsequent calculations just enough such that it produces a different result and isn't culled. But this isn't stable in the sense the order in which triangles are clipped would change the result. And you'd get a similar effect by just randomly jittering the vertices by a small amount, I believe.
Instead of modifying the original triangle vertices such that it impacts subsequent clipping calculations have you tried just project the edge points in the local scope for this calculation to see if that solves the issue? Ie do something like this:
Then we're ensuring that at least the edge we're using is on the other triangle plane.