-
Notifications
You must be signed in to change notification settings - Fork 96
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
Add tolerance value #997
Add tolerance value #997
Conversation
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.
Good start; I think we need to be pretty careful about where we use tolerance vs uncertainty. I think uncertainty is the epsilon in epsilon-valid, while tolerance is our simplication parameter.
@@ -37,27 +37,26 @@ TEST(Properties, GetProperties) { | |||
|
|||
TEST(Properties, Precision) { |
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.
Update test names
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.
Thinking about this, I guess I should just go for the stricter one and use epsilon whenever I am not sure.
src/impl.cpp
Outdated
|
||
const double volume = std::abs(la::dot(normal, pairVec)); | ||
// Only operate on coplanar triangles | ||
if (volume > std::max(area, areaPair) * precision) return; | ||
if (volume > std::max(area, areaPair) * epsilon) return; |
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.
I think tolerance is probably natural for coplanarity.
src/impl.cpp
Outdated
@@ -171,7 +170,7 @@ struct CheckCoplanarity { | |||
// If any component vertex is not coplanar with the component's reference | |||
// triangle, unmark the entire component so that none of its triangles are | |||
// marked coplanar. | |||
if (std::abs(la::dot(normal, vert - origin)) > precision) { | |||
if (std::abs(la::dot(normal, vert - origin)) > epsilon) { |
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.
tolerance again.
auto impl = std::make_shared<Impl>(*GetCsgLeafNode().GetImpl()); | ||
auto oldTolerance = impl->tolerance_; | ||
impl->SetEpsilon(epsilon); | ||
if (impl->tolerance_ > oldTolerance) impl->SimplifyTopology(); |
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.
If we moved this logic into the Impl functions could we reduce duplication by having SetEpsilon call SetTolerance?
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.
yes
|
||
float epsilon = std::max(static_cast<float>(out.GetEpsilon()), | ||
std::numeric_limits<float>::epsilon() * | ||
static_cast<float>(out.BoundingBox().Scale())); |
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.
Why is this necessary?
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 is getting MeshGL, which uses single precision. The epsilon value we track is for double precision, which is too small here.
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.
Hmm, that sounds like a bug we should fix at the MeshGL level. Also, I thought I already had?
Tolerance value is set before the mesh is created, when SimplfiyTopology cannot be called.
For the test naming, I think I will leave it here as we should fix a bunch of other documentations and naming as well. Should we change |
@starseeker can you check if this helps? |
@pca006132 Trying various settings in this context doesn't seem to change the timing: BRL-CAD/brlcad@9a82ed3 |
(I know I need to clean up the code to not do the intermediate checks for performance, but for the moment I'm leaving it as it was for testing.) |
@starseeker How certain are you that it was faster before? Manifold can be tricky to time properly - based on the operations you're doing, I'd be a bit surprised if it was really finishing orders of magnitude faster than now. Can you check out a particular commit, add your test and show the timing difference, for instance? |
It's possible I'm not doing something right, but If I go back to the stand-alone test that got boiled down into the boolean_complex case, I did have that working in both v2.4.5 and current:
Putting the same offsetTest into the tolerance branch, pulling in the RotateUp fix and setting the tolerance in the input mesh:
then running the same input file:
|
The v2.4.5 version: master...starseeker:manifold:perf_test_v245 |
Ah, sorry, that sha1 for the tolerance is one behind - this is the file that compiles: https://github.com/starseeker/manifold/blob/tolerance/extras/offset_test.cpp |
A quick backport of the new boolean_complex test also shows similar timing differences: master...starseeker:manifold:test_backport
tolerance branch in starseeker/manifold:
|
tolerance branch in starseeker/manifold with tolerance settings per 74f2fe4:
|
Correction - per the test_backport branch, I'm seeing 3004 triangles exported in the final output mesh. |
Okay, thanks - that definitely doesn't seem like enough to be responsible for most the slowdown. Anyway, this is all a long tangent from the question @pca006132 was asking regarding this PR. I believe this testing shows that indeed, this PR's change is good and working as intended, even though the problem it's fixing is not the whole regression identified by the SimpleOffset test. |
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 looks great, thanks!
In combination with #989, increasing the number of faces may cause a significant slowdown. But should do a detailed profiling to see the reason. Will finish the remaining of this PR later when I have time, hopefully this week. |
@starseeker and you can try to use BatchBoolean instead of doing += repeatedly. It should help a bit, even though the older version should also have this performance issue regarding +=... |
I don't know if this is helpful, but here are Linux perf recordings of the test_backport and current master running the simple offset test case: https://brlcad.org/~starseeker/perf_test_backport.txt |
Interestingly, SimplifyTopology in master wound up below the 0.40% cutoff: 0.12% manifold_test libmanifold.so.2.5.1 [.] manifold::Manifold::Impl::SimplifyTopology() |
Actually, the call graph version of master might be more helpful:
|
Urk. Wait a minute. If I explicitly specify CMAKE_BUILD_TYPE=Release for configure, I'm getting an execution time in master of 5143 ms. Maybe it's as simple as the v2.4.5 build getting some build flags by default without having to specify the CMake build type. |
Hmm, interesting. But we do have default build type as configured in Lines 115 to 125 in e647093
Also, I guess with this PR, the problem is essentially solved now? If you use the correct build type. |
Bingo. Old build has "-O3" in the compile lines even when I don't specify a build type, and the master build does not. Looks like I somehow managed to drop those in the CMake refactor. Good grief. Pull request imminent. |
To be fair, I think it is fine to drop the |
Well... Hmm. That's a point - the perf reports do actually illustrate why you might not always want the O3 flag on. @elalish any thoughts on that one? |
And I think it is normal for |
Ah, and another issue is that because you are calling |
@pca006132 Eventually I'd like to fully stomp on the gas - enable tbb, remove all the Status() and exports mid-execution, etc. - but that triangulation failure that only seems to manifest with tbb enabled in particular has me a little gun-shy. Slower and reliable wins over faster and occasionally failing (well, within reason) in my particular use case. |
I see. I would suggest you to try the fast way and fallback to the slower way in case something failed, because the timing difference is huge. I managed to cut the time down from 5450ms to 220ms just by changing these. We will add some debug info in csg tree to report back the offending boolean pair when something bad happens, so it should be easier to debug later. |
Anyway, probably too much discussion about things tangential to this PR. We should continue the discussion in #993 if needed. Wish github can just allow me to select and move some of the discussions to another issue... |
Good teamwork on the debugging - I'm glad this is solved! @pca006132 should we just go ahead and merge this and do the docs & tests in a follow-on PR? |
sounds good to me |
@elalish so what do you think about the naming? |
Yeah, I agree. I'm working on PRs now to update these names and to remove the need for that epsilon setting in |
Just to check - three of the original checkboxes in the initial PR ended up unchecked - are they still needed? |
Yes, we will do it later |
Implements #994.