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.

[jonathanhogg]

Hello!

Just came across this thread and thought that perhaps I should stick my head in and say how I'm using Manifold.

I have it integrated into Flitter, my own bespoke declarative language for describing 2D and 3D visuals, which I use for interactive artworks and live performances. I use Manifold both directly and through Trimesh.

If anyone is interested, Flitter is mostly documented.

I am also trying to keep a repo of interesting examples. In particular, there's a pretty comprehensive example of using Flitter to declaratively describe CSG operations in that repo (actually the first example I did when I was implementing CSG support in the first place).

I also tend to post work-in-progress videos on my Mastodon account.

[PaddiM]

Hi,

I use manifold in my 3MF IO toolkit (own implementation, not the official one). Helps me to generate meshes for the files containing
3MF Beam Lattice Extension and Boolean Operations Extension elements.

[elalish]

Great to hear it's helpful for 3MF - to some degree that was a genesis of this project a decade ago or so. When I wrote the manifoldness definition into the 3MF spec we found a bunch of CAD kernels couldn't reliably adhere to it, which was when I thought a guaranteed-manifold Boolean library would be useful.

[PaddiM]

It's also a huge difference on the binaries size comparing manifold with a complete CAD kernel like ACIS or Open CASCADE ;-)

[rob-rb]

I am using manifold in a web service, for www.spherene.ch , calculating hyperbolic geometry (usable in rhino and soon in other cads). I just use manifold for the mesh booleans through python right now. It's been the best mesh boolean compatible with closed source dev so far. Thanks a lot.

[elalish]

That's super cool, thanks for sharing! Is that an SDF of some kind? I'd love to know more about it if there's any non-proprietary description of the math involved.

[butcherg]

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

[butcherg]

If you had anything to do with 3D Builder, you should be proud. Easy-to-use, intuitive. I'm about to instruct model railroaders in using it to assemble parts into walls to build scale model structures, and I think it's the only hope for some of them to take on CAD for 3d printing.

Oh, timely, right now I'm writing a C++ mesh2geometry() using the threepp.ts program from the wasm examples, the loop uses numRun from MeshGL but its not visible in the C++ struct. Switching to using Decompose to just deal with a vector iterator, but I think the .ts loop would be a heck of a lot more efficient...

[elalish]

Thanks! I was a PM back then, managing our vendor team who built 3D Builder. I did a fair bit of UX and feature design for it. Glad you like it after all these years!

I don't quite follow the back-and-forth you're doing between C++ and JS, but numRun isn't exposed in C++ because it's just runOriginalID.size(). Still, I suppose we could.

[butcherg]

.size(); I;m incredibly stupid... Never mind.

I set out to make a parts website, where one could make windows, doors, siding slabs by specifying parameters and having batch OpenSCAD generate the appropriately configured part, downloading all the .stls from that and using a CAD program to assemble walls and such by just glomming the parts together, and cutting window and door holes with subtract. 3D builder is almost tailor-made to do that, right down to the intelligent snap to encountered objects when you move stuff around. Even scene navigation is intuitive, although that's a low bar compared to most of the other CAD products.

Parts website: https://glenn.pulpitrock.net/customizable_models/

[hrgdavor]

I set out to make a parts website,

Ofc, you would want to use language u are used to, for parts website you could use manifold wasm directly in js, or even OpenScad wasm https://github.com/openscad/openscad-wasm

[butcherg]

I'll take a look at a wasm solution. I have one wall pattern that's computationally intensive, brick pattern. With current release OpenSCAD, too-large a wall crashes my web server. Haven't had success on that server compiling a recent commit with Manifold, put it aside to do other related things. Would be interesting to see if a client-hosted wasm instance mitigates that.

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