-
Notifications
You must be signed in to change notification settings - Fork 105
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
Define a test for simple offset booleans #998
Conversation
This is intended to check for performance regressions - the BRL-CAD logic performing this operation using v2.4.5 ran considerably faster. Note - removing in-loop assertions for triangle count > 0 with the intermediate forms greatly increases the speed, but they are placed there deliberately to simulate what BRL-CAD does to validate the output of the booleans on an incremental basis. In the event of a boolean failure or invalid output being produced for any reason, we want to be able to capture the *exact* inputs responsible - which means we need to check after each boolean operation to validate the results and catch any bad intermediate states at the time they are produced.
@elalish I haven't back-ported to v2.4.5 yet to confirm it runs faster there in this form, but that should be the general idea. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #998 +/- ##
==========================================
- Coverage 91.84% 85.81% -6.03%
==========================================
Files 37 62 +25
Lines 4976 9616 +4640
Branches 0 1049 +1049
==========================================
+ Hits 4570 8252 +3682
- Misses 406 1364 +958 ☔ View full report in Codecov by Sentry. |
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, looks like it takes about 10 seconds to run on the CI currently. We should definitely be able to get that back down.
Uh... that failure is unexpected. A triangulation failure?? Did I break the logic somehow? |
Actually, this is why my Offset PR never got merged. I'm guessing I hit a case where the symbolic perturbation did something unexpected, created some extremely degenerate polygons that compounded enough until the triangulor gave up. However, I never found the time to properly debug it. Interesting that you only saw this error once you adopted my technique - perhaps my technique is flawed. It also means you might just have an algorithm to contribute for an Always fun when one bug leads to another - they're all important, so please follow up on any/all that interest you. But let's try to keep them in separate PRs. |
Hmm, actually I take it back, this didn't start when you switched to |
Um. Again not what I was expecting... |
New data point - the triangulation failure only triggers with tbb enabled. I was wondering why I wasn't seeing it locally - it's because I normally build without tbb. When I do enable it here, I get the failure. |
Thanks for all the debug - we're getting closer. Since this test is passing, I suppose we might as well merge it. That should make it easier to test various ideas for fixes, not to mention we can modify it to repro the other bug you found. |
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 for the perf test!
I don't know if this matters or helps, but I was experimenting with doing a number of iterations on the triangle potion of the unioning before calling Status(). At least on my machine here, if I run 15 iterations before calling Status(), I get intermittent success and failure - things aren't reproducible/deterministic from run to run. If I do more than 15 iterations it seems to reliably fail, and less than 15 I'm not seeing a failure. |
Sorry, I need to correct my terms - it's not iterations, it's number of faces processed. So unioning in 14 triangle-generated solids and then calling Status() seems to work, trying to do 16 fails, and 15 sometimes works and sometimes doesn't. I'm not iterating over all the triangles multiple times trying to union them in again and again (that would just be evil.) |
It's a piece of the FAA's GenericTwin plane model. They model thin volumes with just a surface mesh (hence why we need the offset for boolean ops) and that just happened to be the piece I grabbed for testing - there's lots more like it. The ones that look more like "airplane" are considerably larger, and this one was one of the smaller ones - just picked at random. As far as I can tell, the cutout is intentional. |
Not sure, csg reordering can give different results, and if things were close to triggering an issue, csg reordering can push it to actually trigger the issue I guess. But yeah, some mechanism to dump the offending boolean operation will be nice to catch this kind of error. I actually did that for #970, forgot why I did not make a PR for it. |
This is intended to check for performance regressions - the BRL-CAD logic performing this operation using v2.4.5 ran considerably faster.
Note - removing in-loop assertions for triangle count > 0 with the intermediate forms greatly increases the speed, but they are placed there deliberately to simulate what BRL-CAD does to validate the output of the booleans on an incremental basis. In the event of a boolean failure or invalid output being produced for any reason, we want to be able to capture the exact inputs responsible - which means we need to check after each boolean operation to validate the results and catch any bad intermediate states at the time they are produced.