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

Large meshes result in SparseIndicie too large error - Python #720

Closed
drlukeparry opened this issue Jan 26, 2024 · 5 comments · Fixed by #742
Closed

Large meshes result in SparseIndicie too large error - Python #720

drlukeparry opened this issue Jan 26, 2024 · 5 comments · Fixed by #742

Comments

@drlukeparry
Copy link

Using the Python bindings of the manifold library in-conjunction with the trimesh Python library, there is the following error when working with extremely large meshes (+200mb)

IndexError: SparseIndices too large

This is encountered after conversion to mesh following the boolean operation.

@pca006132
Copy link
Collaborator

Yeah this is because we use 32 bit integers for indices, which will cause issues when meshes are large. I thought about converting these indices to 64 bit integers, but it is hard to push for that when no users really need that.

Maybe you can tell us more about your use case to see what we can do about it.

@drlukeparry
Copy link
Author

Thank your for responding to my query.

Generally in the field of work in 3D Printing/Additive Manufacturing, we often deal with merging large complex meshes (e.g. TPMS / lattice structures) and merging these with other geometries. These can have mesh sizes into the Gb in some extreme instances that cannot be solved through mesh decimation. Otherwise, we have to go to implicit signed distance fields which for mechanical engineering applications are unsatisfactory due to their smoothening effect, that do not match the original BRep in CAD.

If we can solve this, I am confident that it will have a very positive impact in the area of 3D printing community.

Thank you for your consideration,
Luke

@elalish
Copy link
Owner

elalish commented Jan 29, 2024

Thanks! Would you mind sharing an image or maybe zoom video so we can see what kind of mesh you're talking about?

@trlsmax
Copy link

trlsmax commented Feb 1, 2024

I got the same error when I do some crazy thing in OpenSCAD with manifold enabled.

$fn = 20;
translate([0, 0, 5000])
difference() {
    translate([0, 0, -5000])
        cylinder(h = 10, d = 512, center = true);
    for (y = [0:1.6:400]) {
        for (x = [0:0.8:400]) {
            rotate([atan(y / 5000) * 180 / 3.1415926, atan(x / 5000) * 180 / 3.1415926, 0])
                cylinder(h = 12200, d = 0.8, center = true);
            rotate([atan(y / 5000) * 180 / 3.1415926, atan(-x / 5000) * 180 / 3.1415926, 0])
                cylinder(h = 12200, d = 0.8, center = true);
            rotate([atan(-y / 5000) * 180 / 3.1415926, atan(x / 5000) * 180 / 3.1415926, 0])
                cylinder(h = 12200, d = 0.8, center = true);
            rotate([atan(-y / 5000) * 180 / 3.1415926, atan(-x / 5000) * 180 / 3.1415926, 0])
                cylinder(h = 12200, d = 0.8, center = true);
        }
    }
}

@elalish
Copy link
Owner

elalish commented Feb 1, 2024

Oh, I see now - the sparse indices can be much larger than the actual number of verts, since these faces are big enough to totally defeat the BVH, so we're really getting an O(n^2) pairs list, because it's not really sparse. So we probably don't need to update all our internal indices from 32 to 64 bit, but we do need to update the SparseIndices specifically to 64 bit. That seems like a more reasonable change.

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 a pull request may close this issue.

4 participants