Users of Manifold

[elalish]

The whole point of this library being open-source is for others to make use of it, but it can be hard to know who our users are. I'm starting this discussion as a nice central place to post if you have integrated Manifold with other code. The idea is to give recognition to interesting projects (both closed and open), as well as to show Manifold's reach.

So far we have:

• OpenSCAD has integrated manifold as an alternative to CGAL (thanks @ochafik!)
• IFCjs has integrated Manifold (thanks @makc!)
• Godot engine is investigating Manifold (thanks @fire!)

And of course our own front-end, https://manifoldcad.org/.

[jirihon]

Thanks @elalish for starting the discussion. It's a great idea.

We are using Manifold to build a specialised web-based parametric modelling studio (closed-source for now, it does not have a name yet). For us, the most important feature of Manifold is the MeshRelation which greatly helps to implement stable references to faces (and consequently to edges and vertices too) throughout all operations. The manifoldness of the output also simplifies algorithms for the analysis of the mesh. And its speed is amazing so far. These are great advantages in comparison to JSCAD, which we used in earlier, much less capable, prototypes.

Just in case @stewartoallen isn't watching this discussion, in November 2022, he integrated Manifold in his great Grid.Space apps, starting from release 3.7 (changelog).

[stewartoallen]

Yes, I did! I'm closing in on a 3.9 release in the coming weeks where I hope to transition to the official npm package. tl;dr The KM CAM animation engine for 4 axis uses (and stresses) Manifold.

[elalish]

Our ES6 module version is now out on npm, if that helps.

[frading]

Hello @elalish,

Great thread idea, I'm curious to see who else might be using manifold.

While I'm not yet using this library, I'm trying to assess when would be the right time to integrate it with Polygonjs. Polygonjs is a procedural and node-based webgl editor. It has nodes to generate threejs objects as well as jscad and I'd love to extend its modeling capabilities with SDFs. Even though SDFs are already possible inside shaders, they remain render only and cannot be combined with other modeling tools or the physics system.

In order to integrate it, I was waiting for the ES6 module conversion, which appears completed, so now I believe there may soon be a new release on npm? Feel free to correct me if I'm wrong on this.

[elalish]

Excellent! Indeed, I just put out v2.1 last week: https://github.com/elalish/manifold/releases/tag/v2.1.0, and the corresponding ES6 release is out on npm as well. I'd love to see what you do with SDFs!

[hrgdavor]

I am working on my own project to enable using multiple CAD libraries that are runnable in JS (pure or WASM)
https://github.com/hrgdavor/jscadui . By enabling I mean creating few different projects and producing a set of useful reusable components like https://github.com/hrgdavor/jscadui/tree/main/packages/html-gizmo .

I am also a contributor to https://github.com/jscad/OpenJSCAD.org and am planning to promote integrating manifold as alternative boolean engine.

For now all thins in plans, not yet implemented. I will 100% report here when I make something usable, and that can be shown/shared.

[rafern]

Hello,
I work for Playko Studios and we're creating an open-source procedural mesh generation library called Gypsum. The goal is to bring procedural meshes to WebGL games, specifically games using Wonderland Engine, and allow CSG operations to be done on those meshes by using Manifold.

Other libraries were previously used for the CSG, such as csg.js, JSCAD and an engine-agnostic port of OctreeCSG, but there were limitations with those libraries, such as poor performance, floating triangles or lack of features. Manifold addresses all of these issues, so we switched to it.

For now the library hasn't seen much use and is still experimental, but we are expecting to use it in the future.

[elalish]

Thanks for sharing! I'd love to see what you're doing with procedural mesh generation. I'm curious if you find Warp and LevelSet to be useful for that in addition to our CSG?

[rafern]

They look pretty useful (especially SDF), but I haven't added support so far because there's 2 problems:

• Warp doesn't transform normals, so it would have to be used only for unlit meshes. Not sure how this could be fixed (maybe have a different callback that rotates normals/tangents?)
• SDF is nice for unlit meshes, but I want to have general support for texturing/normals. I'm thinking I might either assign some vertex attributes like colour by interpolating a 3D array/texture, or have a callback that decides these given a position. No idea how to apply texturing though, especially because Wonderland Engine doesn't support 3D textures

Both of these can be solved on my end by post-processing the output, but I just haven't gotten to doing it yet.

[elalish]

We calculate new normals internally for each Manifold, so it probably wouldn't take much to export those. Maybe as simple as manifold.GenerateNormals(). UV-generation for textures is quite complex, but I wouldn't mind integrating a library for it if we can find one that does it well. Vertex colors are vastly easier for SDFs (see some of our tests), but of course isn't as bandwidth-efficient.

[pca006132]

Maybe we can showcase the list of users in our README?

[elalish]

Yeah, not a bad idea.

[axel-angel]

Thank you @elalish and all collaborators for this great library! I'm a 3d printer hobbyist/maker and I decided to make my own Python CAD library/toolkit to make functional parts: I would like to combine OpenSCAD strength (code-oriented, WYMIWYG, automation/cli and modular operations) and other UI-based strength like FreeCAD / Fusion (lots of practical and easy to use features). I was using OpenSCAD so far and found too many repetitive patterns, from which I thought it would more fun to try building something more suitable with all those patterns.

So far I implemented most OpenSCAD major operators + goodies like part orientation/auto centering. That is already enough to made me switch to my prototype, and making parts is much easier! The fact it's pure Python make it expandable / open ended too! Here is a little preview of how it looks like to make a heart:

from dsl import *

Solid.fn = 6
c = Cylinder(orient='+z')
half = hull(c + c.translate(xy=0.5))
heart = union(half, half.mirror(x=1))
to_stl('heart.stl', heart)

There are a lot to be done and once I have a bit more (sketch, relative positioning/orient to vertex, edge, etc) then I'll want to release a first version. Thanks to this Manifold, it gives me this great opportunity.

[elalish]

Excellent, thanks for sharing! I look forward to seeing your release. Beware, STL is not a reliable format to transmit manifold geometry, since it's not indexed. I'd recommend 3MF for 3D printing.

[rianadon]

Hey @elalish. Thank you for Manifold and for starting this thread. There's lots of cool uses of the library here!

I've been building a keyboard configurator for dactyl keyboards and recently switched from JSCAD + wasmified-OpenSCAD to Manifold. Manifold has proven to be faster than both of these (about 20% faster than JSCAD and 100x faster than OpenSCAD), so I've been really impressed with the library.

To make the transition easier I wrote a wrapper for Manifold to make it compatible with the JSCAD API. It's very much tailored to my use case (I only implemented the JSCAD methods I use), but I hope it's still useful as a starting point for anyone else thinking of moving from JSCAD to Manifold. I also have an implementation of hulling and projection :)

Finally, one tidbit which may be interesting to you: About 1/3 of the time generating the keyboard geometry is spent on Manifold's getMesh/getProperties (It looks like mesh data gets cached between the calls which is very nice, so the first call gets hit with the performance penalty and the second call takes almost no time). I wonder if there's anything that could be done to speed up the meshing, because in comparison the boolean operations are instantaneous.

[axel-angel]

Excellent! Yes, I'd be especially excited to see PRs for hulling and projection

Hello there. I've implemented hull in python with scipy.spatial.ConvexHull + fixing face normals myself, does that count? Probably not as it's a C++ library but maybe we can take example on their code? Just a thought.

The info about laziness was news to me. Thanks for sharing.

[elalish]

Yes, converting the algorithm to C++ would be useful, and probably significantly faster. The critical thing is we'll want an algorithm that is robust to edge cases - if it gives manifold output even for complex input that's not in general position (lots of coplanar/colinear/coincident points) then it's a good candidate for Manifold.

[pca006132]

I think scipy is using https://github.com/qhull/qhull, which already has a C++ implementation.

[pca006132]

Also, it seems to me that a lot of users don't know we are doing lazy evaluation under the hood, maybe we can state it clearly in our README? This can let them understand the performance better, and avoid doing things that work against the lazy evaluation mechanism.

[elalish]

Agreed, good call.

[stephomi]

Integrating Manifold into Nomad Sculpt, an iPad sculpting app.

Before I was only offering boolean through a voxel remesher, thus loosing topology and details.
I added a quadric to keep sharp edges but success rate was so-so and it was constrained to uniform detail/quad size.

Having a clean way to trim stuffs or doing clean merge/subtraction is nice, artists regularly requesting to "not destroy" edges after voxel boolean. Now it's possible!

My longer term goal is to have something similar to zbrush "live boolean", basically a real-time live-preview of the boolean operation so that you can handle the scene in a non-destructive manner. And then commit the boolean (with Manifold) when you are done.

Edit: Integration example https://twitter.com/nomadsculpt/status/1678401764729536512

[elalish]

That's beautiful! Thanks for sharing.

[vasco3]

Hi, I am building a product configurator for Window and Doors. I'm using Three.js with react-three-fiber. I import DXF and I extrude them into profiles. The problem is with boolean operations. Would I be able to use ManifoldCAD for this?
I need to cut the ends of the profiles in 45 degree angle. Then I need to subtract some holes and shapes for CNC operations like drilling.
I see that ManifoldCAD outputs GLTF but I'm not sure how to work with a DXF in ManifoldCAD

[elalish]

It sounds like you may have 2D DXFs that you need to convert to our CrossSections. We don't support curves, so you'll need to sample at your desired resolution. This library might help: https://github.com/prolincur/three-dxf-loader

The good news is polygons are very simple data structures, so conversion isn't generally hard.

[vasco3]

I got the DXF to load in Three (react-three-fiber)

But when I use the react-three-csgto apply a subtract the object disappears.

[elalish]

Do you get better results with Manifold?

[vasco3]

@elalish I would like to try Manifold but don't know how to upload a dxf into manifoldCAD

[elalish]

I would start by looking at whatever polygon data structure react-three-fiber is generating for you, and then doing the conversion from that to a Manifold Polygon yourself. Shouldn't be too hard.

[starseeker]

Hi! The BRL-CAD (https://github.com/BRL-CAD/brlcad) open source computer aided design software has integrated Manifold into our facetization workflow as one of the options for doing boolean evaluations on meshes when evaluating a CSG tree hierarchy. So far it appears to be a significant improvement compared to our previous evaluator:

High level assemblies in BRL-CAD's example geometry files:

% success, previous solution: 88.9% (249 of 280) Time elapsed: 7256 seconds
% success, with Manifold added: 98.9% (277 of 280) Time elapsed: 1044 seconds

Because of the modeling approaches often used with CSG implicit solids, we tend to get a lot of nasty cases like tangent surfaces. However, we can often provide properly manifold meshes for inputs - when the starting point is CSG solids, we should be able to generate a proper input mesh. (Imported cruddy triangle meshes are another story, unfortunately, but that's a separate problem.)

Some of our trees (and the nested booleans that form them) can be complex, so we often represent a pretty severe stress test for boolean evaluations. We normally need to do this conversion for export to formats such as OBJ and STL (we use ray interrogation for most of our production applications) so our weaknesses when performing this kind of export have been a historical problem. We're quite excited to find an option that improves our outcomes, although it's early days yet and we've still got a lot of stress testing ahead.

[pca006132]

yeah we are definitely interested in these failure cases, this helps a lot in fixing the library

[starseeker]

Some of our weaknesses in conversion are turning out not to be the boolean evaluation, by the way - I'm currently in the process of re-engineering our facetize pipeline to help zero in on and deal with those other issues (although automated mesh repair of "almost valid" input meshes is going to be a doozie, if it can even be done at all...)

I should probably explain that the infinite loop case I submitted was actually produced as a consequence of an attempt to deal with another of our weaknesses - we have "implicit" solid meshs that we call plate mode where the mesh itself is just a surface, and we use an implicit offset in raytracing to "fake" a volume. For boolean evaluation we need to turn that implicit volume into an explicit volume, which is fairly hard - I'm attempting to brute force it by representing individual mesh elements with CSG primitives, facetizing those individually, and unioning the whole mess together. "Stress test" is probably an understatement as far as what this is asking of the boolean evaluation routines, but perhaps it will also help shake out issues that might be encountered rarely in other, more normal cases...

[starseeker]

By the way, in the vein of producing test cases - in #564 there was mention of a "minimize test case function" - is that some sort of automated tool to take a failing boolean case and simplify the meshes down to smaller ones that still triggers the failure?

[pca006132]

No, we only have that tool for the 2D case. We can probably do something similar for 3D, but it is quite hard and not sure if it would be useful.

[elalish]

However, 95% of the time we have some problem with a Boolean op, it's actually a problem with triangulating a polygon. If you build with MANIFOLD_DEBUG and ExecutionParams.processOverlaps = false it'll run a lot slower, but automatically spit out problem polygon test cases, which can then be reduced by minimize_testcase.

[wrongbad]

I made some simple glue code to enable playing with manifold in jupyter notebooks, with pythreejs for rendering
https://github.com/wrongbad/badcad

[elalish]

Nice, I was just thinking of sharing a colab using trimesh, so similar idea. Have you tried colab?

[wrongbad]

Yeah I've used google colab for ML before. I just tried it and I get a lot of errors and warnings from pythreejs. Not sure I feel like debugging that right now when local jupyter / vscode is working well.

trimesh seems interesting, looks like a lot of features, some redundant with manifold. I like the numpy-focus though. It makes sense for consistency and common-format for python ecosystem. I was thinking some of the manifold python APIs could be rewritten or overloaded to replace lists and tuples with numpy.ndarry.

[wrongbad]

@elalish How important is python API stability at this point? I wouldn't mind taking on the numpy refactoring. In many cases it could be significantly faster.

Another thought I had was adding a WarpBatch() cpp api, and then using that for python, so you don't hit the cross-lang function overhead for every single point. Instead just pass the verts in a Nx3 or Nx2 ndarray to a single function call.

[pca006132]

I think there are some regular users for the python API, so it is better to be stable. Overloading should be enough for numpy refactoring.

Yes, WarpBatch is a nice idea. I think we thought about this previously but somehow did not implement it.

[elalish]

Agreed, we're certainly open to Python improvements, @wrongbad. Let's discuss the particulars in PRs. You're welcome to open one with just the API shape first so you can get feedback before writing a bunch of implementation if you want.

[howardt]

Just recording here that I am integrating manifold into Blender, as an option for the Boolean solver in Geometry Nodes.