Rust bindings based on C bindings

[alpinebuster]

Rust bindings based on C bindings which should be simpler than JS. In scenarios where more popular and user-friendly UIs are needed to interact with MeshLib, using MeshLib as an npm package or a Rust crate would be much more convenient. Compared to these options, writing UIs in C++ remains relatively complex.

[adalisk-emikhaylov]

We eventually plan to support more languages, but each new language takes a few man-months of work, so we have to be really careful with what we choose. The plan is to support JS next, because we want to allow using MeshLib in web applications, on the client side.

Rust would be nice to have, but it's not a priority for us right now. I'm also a bit worried about how the bindings would interact with the borrow checker.

Re UI, is the situation in Rust significantly better than in C++? We use ImGui for MeshInspector, and there are some other mature frameworks to choose from (Qt, Gtkmm...).

[alpinebuster]

Thank you for your patient and detailed response.

While C++ remains the undisputed sovereign of heavy-duty industrial software, such as 3D rendering engines, mesh processing suites like MeshInspector, and legacy GUI frameworks like Qt, Rust’s ecosystem offers a compelling alternative for modern development. Cargo’s streamlined package management provides a far superior developer experience compared to the convoluted CMake, vcpkg, and Conan pipeline, which significantly accelerates development velocity. Furthermore, Rust’s Borrow Checker effectively eliminates memory leaks and data races at compile-time. For rapid prototyping, 3D experimentation, and small-scale academic research, leveraging MeshLib in tandem with egui proves to be a vastly more efficient and ergonomic workflow.

[Fedr]

MeshLib now has Rust bindings, and the crate is on crates.io: https://crates.io/crates/meshlib

cargo add meshlib

fn main()
{
    let mesh = meshlib::make_uv_sphere(Some(1.0), Some(64), Some(64));
    println!("sphere: {} triangles", mesh.topology().get_valid_faces().count());
}

cargo run is all it takes. No MeshLib installation and no CMake/vcpkg are needed: on the first build, the crate's build script downloads the prebuilt MeshLib libraries for your platform (20-35 MB, checked by SHA256) and caches them. Windows, Linux and macOS are supported, on both x86_64 and aarch64. Starting with the next MeshLib release, the releases page will also have an archive of the crate with the libraries of all platforms bundled, for offline use.

As you suggested, the bindings are generated from our C bindings, the same way as the C# ones. So they cover the whole C API, about 38k functions, and stay in sync with every release. The safe layer is idiomatic where it can be:

• C++ objects are owned handles that free the object on Drop.
• Parameters are &T / &mut T / Option<&T> / &str, and default arguments are Option.
• Callbacks take closures, e.g. a progress callback for decimation.
• Methods returning references into an object carry lifetimes, so the borrow checker won't let them outlive it.

The few signatures that can't be expressed safely yet are unsafe fns with raw C types.

The crate version follows MeshLib: 3.1.4-542 is MeshLib v3.1.4.542. New versions are published with every release.

Setup guide: https://github.com/MeshInspector/MeshLib/blob/master/doxygen/general_pages/RustSetupGuide.md

Examples (boolean, decimation, load/save): https://github.com/MeshInspector/MeshLib/tree/master/examples/rust-examples

The bindings are new, so feedback is very welcome. We'd especially like to hear how it works for you with egui.

[alpinebuster]

Tight, tight, tight, yeah!