-
Notifications
You must be signed in to change notification settings - Fork 114
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 MeshGL64 #927
add MeshGL64 #927
Conversation
And it seems that we miss a vertex normal calculation function that write normals to property channels? If I understand it correctly, |
and I am thinking maybe we should add some simple iterators to MeshGL so we can easily iterate over vertex positions and tri verts as triples, without changing the memory representation. |
Yeah, good idea. That fits with the helper functions we put in the WASM bindings too. |
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 looking great!
scallop.triVerts.push_back({0, 2 + i, 2 + j}); | ||
scallop.triVerts.insert( | ||
scallop.triVerts.end(), | ||
{0, static_cast<uint32_t>(2 + i), static_cast<uint32_t>(2 + j)}); |
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.
Can we skip the casting if we just define i
and j
as uint32_t
?
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.
It depends if we need signed results for other things that depend on i and j, iirc there are results that can be negative before this line?
|
||
if (meshGL.runOriginalID.empty()) { | ||
// FIXME: should we do this? | ||
meshRelation_.originalID = Impl::ReserveIDs(1); |
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.
Huh, it does seem to conflict with the statement at the end of the function. Does anything break if you remove it? I should probably think through the cases here...
src/manifold/src/impl.h
Outdated
} | ||
tri[j] = prop2vert[vert]; | ||
// FIXME: do we need this check? | ||
if (tri[j] < 0 || tri[j] >= static_cast<int>(numVert)) { |
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.
Agreed, looks like that's already checked above.
src/manifold/src/impl.h
Outdated
ivec3 tri; | ||
for (const size_t j : {0, 1, 2}) { | ||
const int vert = meshGL.triVerts[3 * i + j]; | ||
if (vert < 0 || vert >= static_cast<int>(numVert)) { |
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.
Can we avoid the cast by declaring vert
as size_t
?
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.
probably yes
Btw, MeshGLP is just a random naming, feel free to suggest another if you think of something better. |
@elalish btw what about this? Am I overlooking some API or we should add this? |
For diff --git a/test/smooth_test.cpp b/test/smooth_test.cpp
index 8d11dd89..88efcba1 100644
--- a/test/smooth_test.cpp
+++ b/test/smooth_test.cpp
@@ -109,7 +109,7 @@ TEST(Smooth, ToLength) {
CrossSection::Circle(10, 10).Translate({10, 0}).ToPolygons(), 2, 0, 0,
{0, 0});
cone += cone.Scale({1, 1, -5});
- Manifold smooth = Manifold::Smooth(cone.GetMeshGL64());
+ Manifold smooth = Manifold::Smooth(cone.GetMesh());
smooth = smooth.RefineToLength(0.1);
ExpectMeshes(smooth, {{85250, 170496}});
auto prop = smooth.GetProperties(); So maybe the mesh is not being simplified due to not being original, and it is somehow giving a different volume?
|
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.
As for CalculateNormals
, I realize now it's a bit confusing since we have both a Manifold
and an Impl
method with that name that don't do the same thing. We should rename the Impl one - it calculates both face and vertex normals, but just the simple internal versions. The public method does much more complicated vertex normal calculations that are put into the public property channels.
So, I don't think we're missing anything. Certainly some tests should fail if we are.
I'm pretty certain the issue with Should we mark the test as broken for now? I think this issue is not related to |
Oh, I don't mean we miss some calculation, I just mean there is no simple way to get vertex normal with |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #927 +/- ##
==========================================
- Coverage 91.84% 88.33% -3.51%
==========================================
Files 37 62 +25
Lines 4976 8670 +3694
Branches 0 1049 +1049
==========================================
+ Hits 4570 7659 +3089
- Misses 406 1011 +605 ☔ 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.
I just mean there is no simple way to get vertex normal with MeshGL and it makes it hard to get rid of Mesh in our tests.
Interesting - which tests is this making difficult? I can take a look at refactoring them.
src/manifold/src/impl.h
Outdated
|
||
#define IGNORE_DEPRECATED_BEGIN \ | ||
_Pragma("GCC diagnostic push") \ | ||
_Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"") |
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 cool, but should we just go ahead and remove Mesh
for v3.0? It would be a lot less maintenance burden.
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.
true
In general, And I also reverted the deprecated commit, that is a bit hard to get right on all platforms (e.g. clang 18 has a bug that breaks |
edaaece
to
fb7a6ae
Compare
@elalish so should I just disable the failed test xase and merge this? |
@@ -111,8 +109,7 @@ TEST(Smooth, ToLength) { | |||
CrossSection::Circle(10, 10).Translate({10, 0}).ToPolygons(), 2, 0, 0, | |||
{0, 0}); | |||
cone += cone.Scale({1, 1, -5}); | |||
Manifold smooth = Manifold::Smooth(cone.GetMesh()); | |||
smooth = smooth.RefineToLength(0.1); | |||
Manifold smooth = cone.AsOriginal().SmoothOut(180).RefineToLength(0.1); |
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.
Okay, I fixed it with AsOriginal
and I think I understand why - our old Mesh didn't keep track of IDs, which allowed those faces to become quads, but MeshGL keeps more info. I think this is fine.
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.
Looks great, thanks!
Hmm, I should have asked - did you add any tests of |
Yeah, we should definitely add some tests for |
Added
MeshGL64
and removed usages ofMesh
inside our library.Mesh
is not yet removed because we use it extensively in tests, we should soon remove it soon though.@elalish we have two failures related to refine and smooth though, they are
Smooth.ToLength
andSamples.Scallop
. The stats are different significantly, so perhaps I did something wrong in my refactoring.Note that we haven't yet exposed
MeshGL64
to C and python bindings, I think that can be done later. I did removeMesh
from the C binding.