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

Define a test for simple offset booleans #998

Merged
merged 20 commits into from
Oct 19, 2024
Merged

Conversation

starseeker
Copy link
Contributor

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.

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.
@starseeker
Copy link
Contributor Author

@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.

Copy link

codecov bot commented Oct 18, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.81%. Comparing base (d437097) to head (e08cb1c).
Report is 125 commits behind head on master.

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.
📢 Have feedback on the report? Share it here.

Copy link
Owner

@elalish elalish left a 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.

test/boolean_complex_test.cpp Outdated Show resolved Hide resolved
test/boolean_complex_test.cpp Show resolved Hide resolved
test/boolean_complex_test.cpp Outdated Show resolved Hide resolved
test/boolean_complex_test.cpp Outdated Show resolved Hide resolved
@starseeker
Copy link
Contributor Author

Uh... that failure is unexpected. A triangulation failure?? Did I break the logic somehow?

@elalish
Copy link
Owner

elalish commented Oct 18, 2024

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 Offset method, which would be awesome!

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.

@elalish
Copy link
Owner

elalish commented Oct 18, 2024

Hmm, actually I take it back, this didn't start when you switched to Cylinder, it started when you allowed our CSG tree to reorder. That's very interesting. @pca006132 could this be a bug in the CSG optimization somehow? It would be amazing if we could cut this down to find exactly the Boolean op that's failing, but for that I think we'll have to put some debug code into the CSG tree itself.

@starseeker
Copy link
Contributor Author

starseeker commented Oct 18, 2024

Um. Again not what I was expecting...

@starseeker
Copy link
Contributor Author

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.

@elalish
Copy link
Owner

elalish commented Oct 19, 2024

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.

Copy link
Owner

@elalish elalish left a 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!

@starseeker
Copy link
Contributor Author

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.

@elalish elalish merged commit 0a51ae2 into elalish:master Oct 19, 2024
21 checks passed
@starseeker
Copy link
Contributor Author

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.)

@starseeker starseeker deleted the perf_check branch October 19, 2024 04:22
@elalish
Copy link
Owner

elalish commented Oct 19, 2024

Can you give me any background on what this model is supposed to be? I'm curious why it's 3,000 meters tall and offset by 1 meter? And is this cutout in the top intentional?
image

@starseeker
Copy link
Contributor Author

starseeker commented Oct 19, 2024

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.

@pca006132
Copy link
Collaborator

Hmm, actually I take it back, this didn't start when you switched to Cylinder, it started when you allowed our CSG tree to reorder. That's very interesting. @pca006132 could this be a bug in the CSG optimization somehow? It would be amazing if we could cut this down to find exactly the Boolean op that's failing, but for that I think we'll have to put some debug code into the CSG tree itself.

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.

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

Successfully merging this pull request may close these issues.

3 participants