v3.0

[elalish]

This is a huge release! We've packed in all the requested breaking changes to put us on a solid path of API stability going forward. We have removed all of our required dependencies (no more Thrust or GLM!) and dramatically simplified our directory structure and CMake. We have upgraded internally to double precision and added MeshGL64 for those who need to access it. And we have simplified and improved the API in many ways and added a few powerful new features. Please check out our new and improved C++ and TypeScript docs pages!

Breaking Changes

• Use size_t instead of int across our API, @pca006132 in chores #833
• Made CrossSection (and Clipper2 dependency) optional, @elalish in removed cross_section dependency from manifold #850
• Removed Thrust dependency, use optional TBB instead, @elalish, @pca006132 in Remove fancy iterators #852, Bye-bye thrust #856, custom parallel algorithms based on tbb #857
• Moved LevelSet() in as a static member of Manifold, @elalish in SDF Refactor #876, SDF collapse #894
• Upgraded from single to double precision, @pca006132 in Double precision #895
• Simplify directory structure, @pca006132, @starseeker in change directory structure #918, Attempt at simplifying the file structure and CMake build #961
• Remove property tolerance, @elalish in Make create faces optional #935
• Remove Mesh, @elalish in Remove mesh #950
• Overhaul our CMake, @starseeker in Attempt at simplifying the file structure and CMake build #961, Whoops - looks like Doxyfile needs to be top level #965, Try to restore C bindings as a separate library build. #967, Always check in the code for explicit parallel/serial choice #980, Make sure _MSC_VER is defined before checking #990, Need to fix compilation flag lost in CMake refactor #1005
• Replace GLM with linalg - down another dependency, @elalish in Replace GLM with linalg #984
• Separate coplanarity from faceID, @elalish in Separate coplanarity from faceID #991
• Split Precision into Epsilon and Tolerance, @pca006132, @elalish in Add tolerance value #997, Precision renaming #1008, update tolerance defaults #1007
• Switched property indexing from vector to scalar, @elalish in switched property indexing from vector to scalar #1016
• Replace GetProperties() with Volume() and SurfaceArea(), @elalish in Remove GetProperties() #1022
• SDF boundary cleanup, @elalish in SDF boundary cleanup #1037
• Disable exceptions by default, @elalish in Disable exceptions by default #1044

New Features

• SDF interpolation, @elalish in SDF interpolation #866
• Add MeshGL64, @pca006132 in add MeshGL64 #927, always use 64-bit integer for MeshGL64 #1038
• Add RefineToTolerance(), @elalish in Add RefineToPrecision #938
• Add SetTolerance(), @pca006132 in Add tolerance value #997

Bindings

• Fix missing 'this' for property access in wasm bindings, @dsafa in Fix missing 'this' for property access in wasm bindings #914
• wasm: fix CrossSection slice and project bindings, @neilpa in wasm: fix CrossSection slice and project bindings #930
• Expose Quality::ResetToDefaults() via C bindings, @NickUfer in feat: exposes Quality::ResetToDefaults() via C bindings #964
• Wasm: update CrossSection.toPolygons() return value to match type, @dsafa in Wasm: update CrossSection.toPolygons() return value to match type #963
• Expose allocation functions via C bindings, @NickUfer in feat: exposes allocation functions via C bindings #968
• Fix python binding, @pca006132 in fix python binding #987
• Fixed memory leak in C bindings, @pca006132 in bindings update #1018
• Added some missing C and JS bindings, @elalish in Update bindings #1023
• Added C bindings for Triangulate(), @james-bern in Add C bindings for Triangulate() #1034

Bug Fixes

• Triangulation fix, @elalish in removed cross_section dependency from manifold #850
• Propagate errors, @pca006132 in Misc. changes #940
• Removed RotateUp and uint, @elalish in removed RotateUp and uint #1000
• Fix data races, @pca006132 in fix data races #1019
• Fix properties regression, @elalish in fixed properties #1051

Performance Improvements

• Normal calculation optimization, @pca006132 in Normal calculation optimization #934
• Removed face from halfedge, @pca006132 in removed face from halfedge #939
• Collider optimization, @pca006132 in Collider optimization #978
• Removed deterministic param, @elalish in remove deterministic flag #1033
• Free temporary vectors earlier, @pca006132 in free temporary vectors earlier #1047

Build/CI Updates

• Avoid Wundef trigger, @starseeker in Avoid Wundef trigger #861
• Update to emscripten 3.1.61, @elalish in update to emscripten 3.1.61 #860
• Fix debug mode msvc build error, @pca006132 in Fix debug mode msvc build error #863
• Fix shadowing warning, @elalish in fix shadowing warning #867
• Rename operator""_z to _uz, @BenFrantzDale in Rename operator""_z to _uz per P0330R8, and move into namespace manifold #869
• Make collider header-only, @pca006132 in make collider header-only #871
• Improve our CMake, @cjmayo in Use system nanobind if installed #880, Add a cmake option for CrossSection #888, CI: Cancel definition of NDEBUG in TBB build jobs #899, Install manifold.pc under CMAKE_INSTALL_LIBDIR #946, Use CMAKE_INSTALL_LIBDIR when setting installed rpath #948, Support googletest with the CMake package name GTest #1002, Fix target include directory when building as a submodule #1029
• C bindings are required to build Python package, @jonathanhogg in C bindings are required to build Python package #883
• Remove QuickHull dependency, @Kushal-Shah-03 (through GSoC) in Removing QuickHull dependency #881, Testing Framework for Hull #875, Using Inbuilt Datastructures #893, Cleaning Hull Algorithm Code #904, Added DisabledFaceTest #908
• Add *.pc file for easier use in non-cmake environments, @hzeller in Add *.pc file for easier use in non-cmake environments. #901
• Enable MeshIO/MANIFOLD_EXPORT in flake, @reinux in Enable MeshIO/MANIFOLD_EXPORT in flake #912
• Make cross_section an installable library, @hzeller in Make cross_section an installable library. #915
• Fix test-{cmake,pkgconfig}.sh to create, not append, to test files, @hzeller in Fix test-{cmake,pkgconfig}.sh to create, not append, to test files. #919
• Use mxe to cross compile to windows, @pca006132 in use mxe to cross compile to windows #924
• Fix deployment, @elalish in fix deployment #937
• Cleanup, @wtholliday in Fix comment #954, remove face index on HalfEdge #955, use std::swap #956, Fix comment #985
• Use nanobind builtin stubgen, @pca006132 in use nanobind builtin stubgen #949
• Format cmake files, @pca006132 in format cmake files #975
• Remove CGAL comparisons, @elalish in remove CGAL comparisons #1009
• Fix atomic exchange template deduction, @pca006132 in fix atomic exchange template deduction #1035
• Remove OneDPL, @pca006132 in remove oneDPL #1042
• Manifold CMake alias, @pca006132 in manifold alias #1049
• Provide a numeric version number to compare against, @hzeller, @pca006132 in Provide a numeric version number to compare against. #1054, generate version.h for emscripten build #1055

Tests

• Fixed test flake, @cjmayo in [test] Smooth.SineSurface fails - the difference between prop3.volume and 8.43 exceeds 0.01 #848
• Fix hull_test isMeshConvex() vertices check, @cjmayo in Fix hull_test isMeshConvex() vertices check #898
• Use custom file format for polygon tests, @pca006132 in use custom file format for polygon tests #913
• Define a test for simple offset booleans, @starseeker in Define a test for simple offset booleans #998

Documentation

• Update README, @cjmayo, @elalish in Remove quickhull from README #892, update README links #920, Update README #1015, Update Readme #1025
• Implemented typedoc documentation for WASM bindings, @msantic in implemented typedoc documentation #907
• Doxygen updates, @elalish in Doxygen updates #1014, updated linalg docs #1020, added linalg docs #1043

New Contributors

• @BenFrantzDale made their first contribution in Rename operator""_z to _uz per P0330R8, and move into namespace manifold #869
• @jonathanhogg made their first contribution in C bindings are required to build Python package #883
• @Kushal-Shah-03 made their first contribution in Testing Framework for Hull #875
• @hzeller made their first contribution in Add *.pc file for easier use in non-cmake environments. #901
• @reinux made their first contribution in Enable MeshIO/MANIFOLD_EXPORT in flake #912
• @dsafa made their first contribution in Fix missing 'this' for property access in wasm bindings #914
• @msantic made their first contribution in implemented typedoc documentation #907
• @neilpa made their first contribution in wasm: fix CrossSection slice and project bindings #930
• @wtholliday made their first contribution in Fix comment #954
• @NickUfer made their first contribution in feat: exposes Quality::ResetToDefaults() via C bindings #964
• @james-bern made their first contribution in Add C bindings for Triangulate() #1034

Full Changelog: v2.5.1...v3.0.0

[elalish]

I think we should probably update the README some more here, but I need to think about it a bit more. Suggestions welcome.

@pca006132 WDYT, are we ready for v3.0 release? Anything we should hold for?

[pca006132]

I think the only potential blocker is the C binding stuff, as that is a breaking change. I think we can just go ahead with the changes if no one opposes to it.

1. Some of the dependency description is not formatted correctly in the README (' vs `):

   

2. We are using nanobind instead of pybind11.

3. Should probably mention the dependency name instead of its name in Ubuntu ppa (e.g. not libtbb-dev but tbb).

4. Offline building: Missing FETCHCONTENT_SOURCE_DIR_CLIPPER2.

5. Can remove the remarks about Emscripten version. We are already using 3.1.61 in our CI.

6. Should probably remove the part about fuzzing support, as it is not working for now.

7. Can add a shell command about using of the formatting script, and maybe git precommit hook for it (we should probably use it ourselves...).

8. Windows shenanigans: Not sure if this is important now, considering we only have one main dll. Probably need someone more familiar with windows to decide. We can keep it for now.

9. I can probably find some time and write instructions for developing on nix.

[pca006132]

@SovereignShop btw is it possible for you to make the Clojure binding depends on the C binding alone? Also @geoffder. i.e. without the need for a fork. We can try to integrate the changes needed before we release v3.0.

[elalish]

Okay, SG - we'll hold this release for the C bindings update if you have time to take care of it. I'm not very comfortable with C myself. Meanwhile I'll update the README - thanks for the comments.

[geoffder]

@SovereignShop btw is it possible for you to make the Clojure binding depends on the C binding alone? Also @geoffder. i.e. without the need for a fork. We can try to integrate the changes needed before we release v3.0.

Unfortunately my hiatus has meant I haven't found time to update my OCaml Manifold library in some time, but I already wasn't depending on a fork, just an unadulterated git submodule. If I'm understanding your question correctly.

[pca006132]

@geoffder yeah if you can use the C binding directly already, it is good.

@elalish I will try to find some time to do it, I am stretched really thin recently.

[elalish]

@pca006132 Thanks, but don't burn yourself out over these C bindings. We can put out v3.0 without it too if it's unreasonable in the near term. I don't have a good sense of how much work it will be.

[elalish]

One more question: should I remove the deterministic option for v3.0? I'm concerned it makes the library harder to test, and is it really deterministic even when true? If we remove it, which branch should we keep?

[pca006132]

1. Yeah, we can remove it. I think we can just keep the deterministic version, iirc it is fast enough. Not sure if it is fully deterministic, but ideally it should be.
2. I don't think C binding requires too much work. But it is still some work that I need to find time to do :)

[starseeker]

@elalish so does releasing 3.0 warrant another blog post? ;-)

[elalish]

@elalish so does releasing 3.0 warrant another blog post? ;-)

Yeah - I should write some on the smoothing and SDF work I've done too. All in my copious spare time...

[elalish]

Okay, I've added some README cleanup and bumped the version to 3.0. I also went through our release checklist and though I'm not sure what change(s) was responsible, our WASM is now about twice as fast for me (running examples on ManifoldCAD.org), so that's a good sign.

The only question now is whether we should wait for #1048 (or some subset of it) before cutting v3.0. @kintel - you have the strongest opinions here, so let me know. I'd like to get this out the door, but not at the cost of usability.

[hzeller]

I think it would be good if it was possible to query the manifold version in software, e.g. some macros to define MANIFOLD_MAJOR, MANIFOLD_MINOR or other schemes to query the version, probably defined some header like manifold/version.h or similar. It should be macros so that it is possible in downstream applications to keep things compatible with #ifdefs.

Would probably good to have something like this starting with v3.0.

(context: I was just looking how easy it would be to get the version from Manifold to implement openscad/openscad#5432 ... but it is not in any Manifold-provided header, and trying to get things from the build system such as cmake is sketchy at best - right now I only see the version number in CMake. It needs to be in a proper *.h header).

[kintel]

+1: Compile-time version checking would be nice. It doesn't matter much as long as everyone is using manifold from git HEAD, but as we start seeing multiple deployed versions in the wild, we eventually have to make compile-time feature/version checks.

[kintel]

I'd say wait for #1048 - but thinking about it , it really doesn't matter too much - that doesn't change the API, so it could easily be made part of 3.0.1. Just beat the package managers to the punch by rolling out build system fixes fast :)

[pca006132]

I'd say wait for #1048 - but thinking about it , it really doesn't matter too much - that doesn't change the API, so it could easily be made part of 3.0.1. Just beat the package managers to the punch by rolling out build system fixes fast :)

Not sure if that is a good idea. This will render our 3.0 release as something weird that distros should avoid...

[elalish]

Okay, now's the moment - are we ready to push v3.0? Speak now, or suffer the fate of a point release.

[pca006132]

I think it is ready.

[jonathanhogg]

Just wanted to note that there don't seem to be wheels being built for Python 3.13

[pca006132]

@jonathanhogg This seems to be an issue related to cibuildwheel version. I guess we can update it and run it again, see if pypi is happy with publishing the same version twice with added wheels?

Btw, I think we are targeting stable ABI for cpython, wondering if there is a way to tell python it can reuse the same wheel after 3.12...

[jonathanhogg]

@pca006132: Yeah, I think cibuildwheel picks up the supported versions from the tags in the pyproject.toml file and then builds a wheel for each one.

PyPI will let you add wheels to a release, but not change any of the original files. So it depends on your CI script as to whether it will barf on the existing ones or silently ignore the upload failures it gets.

I don't know if there's a way of marking a binary wheel as being compatible with more than one version…

Luckily the source build works now ;-)

[pca006132]

https://github.com/elalish/manifold/actions/runs/11906944291

It builds python 3.13 wheels, but the upload action is having issues. Maybe we should manually upload the missing binaries? Will have a look at how to do that.

[pca006132]

OK, I downloaded the artifacts and uploaded them manually.