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.

[stewartoallen]

I've converted all KM tools over to the npm module, which is great. Mesh:Tool is also part of the GridApps package. It's a mesh editor / repair tool that I've recently started adding 2D sketch / extrusion to.

[elalish]

Awesome, thanks! What are KM tools? As an npm user, I'd also love feedback on whether we should release more of our JS-related code to npm, e.g. gltf-io, or our function for running a whole manifold script.

[stewartoallen]

KM tools are the internal Kiri:Moto libraries and the companion app Mesh:Tool (which uses them), which is also integrated into the electron / desktop builds. I am very happy with the current npm offering as long as it tracks releases.

[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.

[OLDMAN75914091]

I hope this forum is still alive.
Can anyone share their experience in using this library against some of those terrible face coplanarity corner cases?

[elalish]

That's the whole point! Check out our tests - e.g. the Menger Sponge is designed to test an enormous number of coplanarity issues at once.

[starseeker]

In BRL-CAD's case, it does quite well producing output even when faced with such inputs. Be aware that the results may be a bit surprising - see, for example #614 - but it does succeed in producing output.

[OLDMAN75914091]

Folks, this is a bit off-topic, but still.....
I've noticed that practically all users of this library are building web applications rather than standalone desktop applications. Is this because their applications are meant to real-time collaborate with other users out there on the Internet? Or are there other reasons too?

[elalish]

Where do you get that impression? We made our own ManifoldCAD.org page, but I would actually say we have more users of our Python and C bindings. OpenSCAD is using our C++ directly, as are many others.

[starseeker]

BRL-CAD is a desktop application (or more precisely a set of desktop applications.) You may be seeing a lot of discussion around web projects because there are many active projects in that space, but we're working directly with the C++ libraries as a desktop application.

[a-day-old-bagel]

I have exactly zero interest in web applications or web development in general (it's the boring end of CS where all the business people go, in my presumptuous and unnecessarily inflammatory opinion), so rest assured plenty of us are here for desktop applications.

[elalish]

Ha! For me, when the C++ compiler starts to get me down, I jump over to JS and enjoy complete hacking freedom. :P

[a-day-old-bagel]

Lol yeah if I had ever done a fun personal project in the web sphere (instead of just boring work) I'd probably not have such a silly opinion about it.

[a-day-old-bagel]

I'm using manifold as part of a game I'm writing in Zig.

Incidentally, if anyone wants Zig bindings to be added to the bindings directory, I could toss them in there.

[elalish]

Thanks for the offer! I've never even heard of zig, but java bindings already live in someone else's repo. That's probably best for zig too, but we'd be happy to link to it in our readme.

[a-day-old-bagel]

Sure, I'll let you know if I get it separated out into a clean self-contained thing to link to.

[a-day-old-bagel]

Ok, I'm developing a zig wrapper here, but don't link to it yet, as I've only just started and it's untested. Also, I might be moving it into the zig-gamedev collection if the other contributors of that collection approve of it, so for now, I'm just letting you know that I'm working on it.

[OLDMAN75914091]

i've developed quite a bit of some fairly serious CAD stuff using three.js. however, i now no longer think a web platform is appropriate for my needs - as well as needing to include Manifold. i have to make it all happen on a standard-alone Windows computer - C/C++, MS-VisualStudio, openGL, some appropriate GUI. would like to know your experience with this C++ port of three.js. seems like the initiative of one nice person - is it robust and logical/intuitive to use?

…

On Thu, Oct 17, 2024 at 2:07 AM Glenn Butcher ***@***.***> wrote: I'm messing with building a simple CAD program on the order of Microsoft 3D Builder for non-CAD types to assemble downloaded parts into assemblies to make scale models. I wrote a description of the workflow here: https://forum.mrhmag.com/post/simplified-cad-workflow-13500334 I'm currently using wxWidgets for my UI (been using it for 20 years now, too old to switch :D ) and threepp, the C++ port of three.js. I'm demonstrating this workflow to model railroaders using 3D Builder, but 1) doesn't look like Microsoft is giving it much love, and 2) want to be able to compile Linux and Mac versions. And I've looked, but can't find another free or open-source program that does simple .stl assembly like 3D Builder. BTW, Manifold in OpenSCAD was well-timed for me. I built a HO scale steam locomotive model in OpenSCAD, almost gave it up because of the CGAL rendering, Manifold saved it: https://github.com/butcherg/DRG_168 — Reply to this email directly, view it on GitHub <#340 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKMOUX64HN5KYPUJX7LG52LZ33FB3AVCNFSM6AAAAAAVI7QAFWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOJWGQZDENY> . You are receiving this because you commented.Message ID: ***@***.***>

[butcherg]

A few years ago I messed around with three.js, wrote a little walkabout scene with an animated character to stroll about the terrain, so I have a bit of basis for comparison. threepp is as easy to use as three.js, ignoring the js->c++ translation differences. I ran doxygen against the threepp code to have easy-to-reference declarations, and I spend a lot of time in the rich set of examples to make sure I fully understand the particular usage of stuff. Dependencies are few, well really just assimp. I'm a long-time wxWidgets user (not reticent about qt, just haven't overcome the inertia to learn it) and @markaren has a threepp_wxwidgets example in another repo, so that kick-started my work. Currently fighting cmake to glom all this together into a coherent build system. Just early-days with it, so FWIW.

For the simple 3D Builder-class of program I want to write I think it's a bit of overkill, but a more comprehensive CAD program could use most of it. It seems to be fully implemented, I've run a lot of the examples and the three.js functionality appears to be fully captured.

Edit: Just re-read your post, you're also wondering about Manifold - it or its ilk seem to be an essential part of a CAD application. threepp doesn't do that stuff. My current thought is to subclass Manifold and include a threepp object as a member to be added to the scene graph.

[OLDMAN75914091]

thanks for those answers. some more come to mind now: (1) is this a function-for-function conversion from the two languages? (2) it must address the scene graph related functionality, correct? - creation, manipulation, traversing..... - operations on scene graphs, such as ray casting through a scene tree (3) what about graphics.....what needs to happen to - any pure webGL calls? - the graphics related calls that are part of threejs? (4) threejs has produced some rather good and useful usage documentation. is there anything along these lines for the c++ code? if i can get all this working i will need to manually integrate my useage of Manifold into it. i am prepared to try doing that, the benefit is significant. thanks

…

On Sun, Oct 20, 2024 at 8:03 PM Glenn Butcher ***@***.***> wrote: A few years ago I messed around with three.js, wrote a little walkabout scene with an animated character to stroll about the terrain, so I have a bit of basis for comparison. threepp is as easy to use as three.js, ignoring the js->c++ translation differences. I ran doxygen against the threepp code to have easy-to-reference declarations, and I spend a lot of time in the rich set of examples to make sure I fully understand the particular usage of stuff. Dependencies are few, well really just assimp. I'm a long-time wxWidgets user (not reticent about qt, just haven't overcome the inertia to learn it) and @markaren <https://github.com/markaren> has a threepp_wxwidgets example in another repo, so that kick-started my work. Currently fighting cmake to glom all this together into a coherent build system. Just early-days with it, so FWIW. For the simple 3D Builder-class of program I want to write I think it's a bit of overkill, but a more comprehensive CAD program could use most of it. It seems to be fully implemented, I've run a lot of the examples and the three.js functionality appears to be fully captured. — Reply to this email directly, view it on GitHub <#340 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKMOUX32LMZPKB72TMICZMLZ4O5MLAVCNFSM6AAAAAAVI7QAFWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAOJZGY2TGOI> . You are receiving this because you commented.Message ID: ***@***.***>

[markaren]

Hi, threepp author here.
(1, 2) yes, but the API is kinda stuck on r129 compatibility (with some extras)
(3) WebGL calls are translated to regular openGL. WebGL and regular OpenGL is nearly identical.
(4) three.js documentation can still be used, threepp only offers example code

If you want to test it, just clone and buil with CMake. All depedencies are included. There is a link to a wxwidgets example in the README. For hobby / educational use the library works great. Perhaps also for more serious work.

[butcherg]

So, early-days writing a simple CAD program, finally have some end-to-end success.

I took @markaren's threepp wxWidgets example and munged it into a basic scene display with a menu and a TRS tool. Worked file import, scene-drag translate, and file export to a basic functionality, program looks like this:

The two windows were produced with my OpenSCAD script-based website, https://glenn.pulpitrock.net/customizable_models/, opened two instances and slid them together to make a double-double-hung window. Combined them with Manifold union, and saved to stl. Opened the result in Microsoft 3D Builder, got this:

Yep, glomming together two .stl files makes errors, 3D Builder fixes them easily, but they print fine even without fixing.

The general internal approach is to open a .stl file with the Manifold ImportMesh, convert to threepp geometry for display, and store a Manifold of the file in a std::map with a key made from the threepp Object3D UUID. Move the model around the scene with the RGB arrows and mouse drags; as that is done I accumulate the movements in a Manifold vec3, then apply them with a Manifold Translate when the mouse button is released. File export is simply iterating over the map and building a unioned Manifold.

The only real challenge so far was coming up with an axis-restricted drag, more a challenge of my mental faculties. Still needs work, dragging stops when the drag arrow is left, but it's a start...

[elalish]

Awesome! For reliability and so you don't get that repair dialog, I'd recommend using 3MF instead of STL. STL is lossy, so you can't in general recover the manifold. 3MF is also a lot more compact and efficient.

[butcherg]

3MF is one of the near-term things. Haven't poked at the import/export code, does Manifold handle it already? I want it to be able to save part placement work but be able to re-open it for further placement work. Didn't realize STL is lossy.

With 3MF I'm going to have to include a Group operator, so folk can export a single entity for printing. I tried bringing an un-grouped 3MF to Chitubox; it wanted to populate the build plate with separate parts...

[starseeker]

@butcherg At the C++ level meshIO isn't reading/writing the manifold info (yet). I'm just starting to look into using tinygltf to read/write glb files to eliminate the need for assimp as a dependency, but I've not gotten too far yet and I've got some learning to do on gltf and how its concepts work (https://github.com/starseeker/manifold/tree/gltfio).

[elalish]

MeshIO is just a wrapper for Assimp, which I believe handles 3MF and lots of other formats. A custom exporter would do a much better job though - for instance we have a nice 3MF exporter we use for ManifoldCAD.org that's a small npm package we depend on. Friends don't let friends use STL - it's a truly awful format that has only survived because of its simplicity and some accidents of history.

[james-bern]

Hi! We are writing a new fast, tiny, and fun CAD program called Conversation!

Video and alpha signup: https://james-bern.github.io/conversation.html

Thanks so much for making Manifold! 🙂🙏

[elalish]

Thanks for sharing, that looks super cool! Would you like to throw up a PR adding it to our README's user section?

[james-bern]

Thanks! :) Done!

[howardt]

The alpha build for the next release of Blender now includes Manifold as an option for the solver in the Boolean geometry node and the Boolean modifier. Thanks, Manifold team!
https://builder.blender.org/download/daily/

[howardt]

Blender 4.5, released today, is the first official release of Blender to have Manifold as a boolean solver option. It is the very first thing mentioned on the release recap video!
Thanks to Emmett, John, et al. for your great support in helping this happen.

[elalish]

That's fantastic, Howard! Thanks for sharing, and for pushing this all the way through.

[gene-ressler]

Hi. We are now using Manifold (js/ts binding) to support 3d printing in the new Bridge Designer, Cloud Edition. Formerly it's been a native app known - depending on current sponsorship - as Bridge Designer, Engineering Encounters Bridge Designer and West Point Bridge Designer.

It's a simplified CAD-like tool allowing kids of all ages to get the feel of real bridge engineering by letting them design, build, and test bridges to meet realistic specifications at minimum cost. It's been around since 2001, has won several awards for educational value, was the basis of national contests for several years, and has been downloaded in nearly 10,000,000 copies. This is the third major re-implementation (this time as an Angular app) because technologies keep aging out beneath us! The project budget is currently $0. Development and backing infrastructure are donated.

We're using Manifold to compute unions of overlapping component meshes (used for WebGL visualizations of designs) into single, consistent manifolds suitable as 3d print slicer input.

We're in beta testing with several teachers and their classes. The new repo and test service are not quite publicly releasable. I'll furnish links when they are.

Cheers!

[elalish]

Thanks for sharing! I look forward to the link - I bet my kids would like to try it.

[tonious]

My better half is a potter. I've been making dies for use with a clay extruder.

[butcherg]

I have a rather targeted use of manifold...

I do 3D printed scale models of railroad subjects, current project is the depot at Antonito, Colorado, USA. It has stone walls, and I've been messing with coherent noise patterns generated with libnoise to make stone textures. I wrote some command-line tools to make and shape heightmaps for feeding to OpenSCAD, glommed together with a batch script, got this:

This is the fit-test print:

Well and good, but I tired of the batch script. I needed to validate some of my measurements before final printing, had some time to address the script, and came up with a horrid mess of a program that uses OpenCV, libnoise, and Manifold to take pictures like this:

extract the stone contours, apply libnoise-generated stone heightmaps, and bevel the edges, save them as individual .3mf files. Loaded into OpenSCAD, they look like this:

This screenshot is a bit of a lie, I generated .stl files for it because I'm struggling with applying color to .3mf meshes in OpenSCAD, and it automatically colors .stl

Using Manifold for extruding the contour polygon, intersecting it with the heightmap mesh, and various translate and scale operations to line things up. That was easy; the hard part was the heightmap, as the code I found for that to leave me wanting. So, I set out to write heightmap-to-mesh code, and in doing that learned the basics of manifold-ness. It's a naive algorithm, no optimization, but it maps heightmap tables just like OpenSCAD. I'm going to measure the station this weekend; with that and my new program (stonewall, but it may be better-named 'franken-stone' :D) I'll model and print the walls for my final rendition.

Gotta admit, I struggled a bit getting a manifold heightmap mesh. I flunked trig in high school, and find myself re-learning all that for these structure models. I periodically entertained using a less-strict mesh library so I didn't have to pick at manifold-ness, but I'm glad now I stuck with Manifold to get tight meshes.

Anyhoo, FWIW...

[butcherg]

I created a github repo for my stonewall project:

https://github.com/butcherg/stonewall

The release is a .zip file with the stonewall.exe file, wall.png like in the previous post, a libnoise network definition for the stone texture, and a test.sh (or, test.bat for windows shell) to demonstrate usage. All the libraries are statically linked, so the .exe can be moved anywhere.

Compiling the program is rather involved, libnoise isn't in any of the distro packages repositories I've inspected, OpenCV on win32 wants to create object files with the version number in the filename (horrors!), oh, and manifold doesn't install libClipper2.a along with the mainifold objects. And, don't laugh too hard at my code... :)

[napter]

Hello Users of Manifold!

We are exploring up a monthly zoom call to chat about Manifold, the future of 3d code, the 3d coding ecosystem and to share what we're working on. We'd love to meet everyone and put some faces to the github handles!

Discussion thread is here.

[butcherg]

For a non-technical audience, I wrote a short missive on "why-STL-bad":

https://glenn.pulpitrock.net/blog/posts/2025-12-21-whats-so-bad-about-stl-files/

If I missed anything, or stated an in-correctness, let me know...

[elalish]

Thanks, that's a decent explanation. A few things:

1. 3MF is smaller than STL due to a combo of zip and by not encoding each vertex 6 times.
2. CCW winding, an oriented mesh, is important to more than rendering. It makes it easy to guarantee the mesh represents a solid. Otherwise you might have a Klein bottle.
3. Manifoldness isn't about keeping holes in the mesh small, but ensuring it represents an unambiguous solid. Otherwise the computer has to guess, which might work most of the time, but will not be reliable.

[butcherg]

I added some words to hopefully better-shape the perspective on STL, and a footnote about 3MF size.

I don't think it'd be helpful to talk Klein bottles to model railroaders... :)

The whole business of 3D printing is a "good enough for government work" sort of thing. Folk printing STL are getting the result they want, not interested in mathy stuff that isn't impacting their successfulness. At least, until something doesn't work; even then, the math behind the root cause is not going to sooth their souls...

Thanks for reading. Of note, I didn't even get it until I started coding to make heightmap meshes for stone wall textures. THAT put it in my face.

[hrgdavor]

yes, it is fine while it works... but then you create a tool that needs those details STL hides, and users yelling: why does it not work on my STL, it looks fine in 3d !
:D

[butcherg]

Been intermittently messing with making a simple CAD program that uses Manifold as its mesh munger. Started with threepp for the scene graph, lost interest. Picked it up again using CoPilot to guide me through writing a basic VAO/VBO OpenGL renderer, using a homebrew scene graph rooted in wxWidgets' wxTreeCtrl. Got it to where it'll import mesh files, create cubes and cylinders, and do differences on all the above:

Ironically, spent the most amount of time figuring out mesh IO; got tired of beating on assimp and wrote my own. It currently does only 3MFs, but I have the code to do OBJ and STL, just needs to be copy-pasted into my meshIO.h/cpp.

It's not fancy, doesn't do mouse transforms, and I need to figure out a segfault on close, but I think it would work well enough to do the import-openscad-component workflow I'm trying to make viable for model railroaders.

[tonious]

It's not fancy

Oh yes it is. Doing any of this in C++ should not be downplayed. Well done!

[butcherg]

Thanks! One thing I found out worth noting to users of Manifold is that, when you invoke CalculateNormals() on a Manifold, you've inserted interleaved normals in to the vertex data. I get that, they're all properties, but it pollutes the mesh for exporting if you don't want to send normals. At least I was not able to ferret out a way to select only the vertices for export and still have the triangle indexes align. I ended up deferring CalculateNormals() to the routine that loads the data into the OpenGL VBO, uses a copy of the Manifold, now all is well.

[elalish]

You should be able to remove any added properties with SetProperties(0, [](){}).

[mathieucivel]

Hey, I just submitted a PR mentioning Otterplans and then came across this thread. I’m not sure if this is redundant, but here is a bit more detail.

We can view woodworking as a series of geometric operations. Cutting a mortise is a geometric subtraction, joints are addition, and sawing is division. In both 3D modeling and the real world, we can start with basic shapes, apply a list of operations, and produce an object like a workbench.

Manifold-3D allowed me to represent a wooden object at each stage of its construction and generate build instructions.

I tried several other CSG libraries before finding Manifold-3D, but I couldn't get as far as I wanted with them. Thanks again for your work!

[elalish]

Very cool! My dad was a carpenter, so it's cool to see this CAD workflow come full circle from 3D printing back to woodworking.

[butcherg]

Working on my graphical CAD program, needed simple access to Manifold to figure things out. So, I wrote a command-line CAD program that exposes most of the Manifold API. It works like G'MIC or Imagemagick for photos, a string of command-line parameters does the work:

https://github.com/butcherg/cadsh

The Windows .exe in the release is a static build, should run anywhere on your Windows machine.

[butcherg]

I did some more stuff to cadsh, particularly added a icosahedron and heightmap. Of note, the code for these is in src/manifold_tidbits.h, along with two routines to add vertices and triangles to a MeshGL and return the index, useful in writing object-creation codes.

[elalish]

ManifoldCAD made it onto Jeff Dean's Gemini 3.1 highlights reel! 🎉 🎉

Congrats team, it seems the word is getting out. And special thanks to @tonious who's been overhauling ManifoldCAD so effectively.