dima634
Integration in Blender
I've recently played around with Rust bindings for Python and Blender ( https://github.com/thelazyone/py3o_blender_blueprint , it's kind of an obvious thing to do but all the .dll dependencies in window proved to be a bit of a pain) and I think that implementing many of the features of this library in a Blender plugin would be great.
Currently Blender's Voxel Remesh is working fine and fast (I'd argue it still has slightly better outcomes than baby_shark's, but there's margin to improve!), but Blender's decimation step is slow and with little control.
I'd love to try and set that up myself but i'd like to hear from the author first.
That is a great idea!
Unfortunately, I do not have experience in add-on development for Blender and Rust-Python bindings. So I can't say much. Inter-language interop is a complicated thing and usually, it all comes to C FFI. Regarding DLL (or SO), I think it should be straightforward to compile baby_shark into a shared library. There are no dependencies on any other shared libraries (except system ones), so you should end up with a single self-contained DLL.
Let's see what I can manage to do, then! <3 Can't promise on the timeline, but at least it seems like it's a project that is not blocking anything else.
I noticed you’re interested in integrating baby_shark so it can be used directly inside Blender. In my project hallr, I’m working on exactly that. As a first step, I’ve added the decimate and isotropic remesh functions.
Currently, my "up-stream" crates are being prepared for release, so for now, they’re accessible through Git links. This should only take about a day to complete.
To run the Blender add-on, you’ll need to generate your own hallr.zip file containing the Python script and the .so/.dll/.dylib file. Once you have the zip file, you can simply drag and drop it into Blender.
The operations can be found in 3D View, under Edit mode—just right-click, and the menu should pop up.
Disclaimer: I haven’t tested this on Windows yet—only on Linux and Mac.
I’d really appreciate any feedback!
I really appreciate the work that’s gone into this crate—thanks to everyone involved!
I know this is a big ask, but for blender integration to work there should preferably not be any unreachable!() that takes down the entire process.
I'm just putting that out there, for future consideration.
thread '<unnamed>' panicked at /Users/auser/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/baby_shark-0.3.3/src/mesh/corner_table/traversal.rs:215:9:
internal error: entered unreachable code: Input must be invalid or non-manifold
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5
zsh: abort /Applications/Blender.app/Contents/MacOS/Blender --debug
I should definitely refactor that code. I would appreciate it if you could share the code and 3d model to reproduce this. This is likely a bug in one of the algorithms.
Here is the code i'm using: decimate isotropic remesh and for good measure, even though it does not relate to the issue: mesh offset
And regarding the model, it was probably just a non-manifold one. I will create test-cases for that in my repo later today.
I've not yet reproduced that unreachable!, but i found these :
Here are two tests with a non-manifold mesh that causes an "attempt to add with overflow" crash. One vertex is pinched between both sides of the surface. decimate isotropic mesh
Here is an example of decimate() running into the unreachable!(). And it does so with "error threshold" = 0.05000000074505806, faces count = 10000, it's a kind of contrived non-manifold mesh example. I suspect it contains a near zero area triangle, since some other of my code complains it can't build a normal from it.
Please note that I don't expect decimate() or remesh() to make anything meaningful with meshes like this, i'd just prefer if they didn't panic or crash.