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

removed RotateUp and uint #1000

Merged
merged 8 commits into from
Oct 21, 2024
Merged

removed RotateUp and uint #1000

merged 8 commits into from
Oct 21, 2024

Conversation

elalish
Copy link
Owner

@elalish elalish commented Oct 19, 2024

Fixes #999
Fixes #996

@starseeker I don't have exactly your repro, but I believe this should fix the problem you reported. Would you mind verifying that?

@elalish elalish self-assigned this Oct 19, 2024
manifold::Manifold rotated_cyl =
origin_cyl.Transform(manifold::RotateUp(evec));
manifold::Manifold right = rotated_cyl.Translate(ev1);
quat q = rotation_quat(normalize(evec), vec3(0, 0, 1));
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pca006132 I was a little suprised I didn't need la::rotation_quat or manifold::la::rotation_quat. I recall you made a comment about my namespacing - did I do it wrong?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a weird thing called Argument-dependent lookup for functions, which basically adds the argument type namespaces into the lookup search path. I don't think we have anything wrong with our namespacing.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, that's cool! Thanks for the explanation.

@elalish elalish requested a review from pca006132 October 19, 2024 04:39
@elalish
Copy link
Owner Author

elalish commented Oct 19, 2024

On second thought, considering the very non-obvious behavior from #996, perhaps we should add assertions on all our transform inputs that they are finite.

@starseeker
Copy link
Contributor

I'll try it out when I get a chance, but the first thing to do is remove the "if (len < 0.03) continue;" test with the TODO comment from the offset test, if that's not already removed - that was hitting the issue for me.

@starseeker
Copy link
Contributor

Confirmed - removing the len < 0.03 filter still results in successful running of the offset test.

@starseeker
Copy link
Contributor

@elalish did you want to remove that workaround as part of this PR, or as a separate one?

@elalish
Copy link
Owner Author

elalish commented Oct 20, 2024

Yeah, I'll deal with it here.

if (inQ_.status_ != Manifold::Error::NoError) {
auto impl = Manifold::Impl();
impl.status_ = inQ_.status_;
return impl;
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed this to pass through the input error instead of changing it, which I think makes it a be easier to deduce what went wrong first.

case Manifold::Error::FaceIDWrongLength:
return stream << "Face ID Wrong Length";
case Manifold::Error::InvalidConstruction:
return stream << "Invalid Construction";
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got tired of not being able to see what the error was. I really wish C++ had a way to turn enums into strings automatically, but apparently we need this lovely boiler plate instead.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that a more general approach would be to implement this as a toString function.

@@ -513,6 +513,10 @@ Manifold::Impl Manifold::Impl::Transform(const mat3x4& transform_) const {
result.status_ = status_;
return result;
}
if (!all(isfinite(transform_))) {
result.MarkFailure(Error::NonFiniteVertex);
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added this to catch any kind of bad transform.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently we need to make it explicit, i.e. all(la::isfinite(transform_)) to make msvc happy.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fwiw, in BRL-CAD when we use C++ we generally are explicit with the namespaces to avoid lookup surprises. It's definitely a readability tradeoff though.


bool operator()(size_t edge) const {
const Halfedge halfedge = halfedges[edge];
if (halfedge.startVert == -1 || halfedge.endVert == -1) return true;
if (halfedge.pairedHalfedge == -1) return false;

if (!std::isfinite(vertPos[halfedge.startVert][0])) return false;
if (!std::isfinite(vertPos[halfedge.endVert][0])) return false;
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure when this showed up, but we have a dedicated IsFinite method which was being elided by this throwing a NonManifold error, which was pretty unclear.

@elalish elalish requested a review from pca006132 October 20, 2024 04:39
@elalish
Copy link
Owner Author

elalish commented Oct 20, 2024

@pca006132 I think this one is ready to merge, but I have no idea why the Windows compiler is suddenly pissed - doesn't look like the spew has anything to do with these changes. Thoughts?

@pca006132
Copy link
Collaborator

From the error message:

D:\a\manifold\manifold\src\impl.cpp(516,6): error C2668: 'linalg::isfinite': ambiguous call to overloaded function [D:\a\manifold\manifold\build\src\manifold.vcxproj]
D:\a\manifold\manifold\include\manifold/linalg.h(1298,44): message : could be 'linalg::mat<bool,3,4> linalg::isfinite<manifold::mat3x4>(const A &)' [found using argument-dependent lookup] [D:\a\manifold\manifold\build\src\manifold.vcxproj]
          with
          [
              A=manifold::mat3x4
          ]
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt\corecrt_math.h(401,32): message : or       'bool isfinite<manifold::mat3x4>(_Ty) noexcept' [D:\a\manifold\manifold\build\src\manifold.vcxproj]
          with
          [
              _Ty=manifold::mat3x4
          ]

Apparently it is some weird header in MSVC (TM) that tries to match for every isfinite(T) and causes lookup issue...

@elalish elalish merged commit e647093 into master Oct 21, 2024
19 checks passed
@elalish elalish deleted the miscfix branch October 21, 2024 04:48
starseeker pushed a commit to starseeker/manifold that referenced this pull request Oct 21, 2024
* removed RotateUp and uint

* avoid new API

* simplify

* change error reporting

* fixed error reporting

* fix compile

* addressing feedback
@elalish elalish mentioned this pull request Nov 5, 2024
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.

meshIO.cpp: uint not standard C++ Odd failure creating and unioning multiple cylinders
3 participants