Lars | Algebraic

Desert Space Ship Scene

Sun, 15 Mar 2026 00:00:00 +0000

Squishy Volumes is a Blender add-on developed by Algebraic that puts the Material Point Method (MPM) directly into Blender. Get the latest release!

This blog post is about the making of a scene that shows a space ship emerging from the desert. The purpose is to test and showcase Squishy Volumes’ capabilities in scenes with millions of particles.

Blender version:	5.0.1
Squishy Volumes version:	0.2.0-alpha4
Number of particles:	6.070.868
Number of grid nodes (varies over time):	~1.500.000
Simulated frames:	250
Directory size:	786 GB 💀
Bake time:	18.75 hrs
Render time:	14.29 hrs
Mode:	Explicit, CPU [1]

Data for the nerds.

We’re going to look at this example of what we can do with Squishy Volumes and what challenges to look out for. This blog post is not a step-by-step tutorial, though.

The general idea of the scene is to showcase the awesome power of this space ship. Sand is really heavy, so if the space ship is able to emerge from the depths of the desert and lift tons of material, yeah, that makes it all the more menacing. Here’s the link to this super cool Sci-Fi Ship LowPoly 3D model. [2]

We’ll need lots and lots of sand particles, some static flooring, and an animated collider for the simulation input. For the output, we can make some slight modifications to the Squishy Volumes default visualization and of course, the background, etc.

We’ll face some challenges in defining simulation input, baking, and simulation output. Then we’ll discuss visualization tricks and conclude the blog post with a few comments on how the add-on can be improved.

So, what are the challenges?

Challenges

Some parts are relatively easy; we won’t go into too much detail there. For example, setting up the sand.

Other parts are harder. We’ll need to deal with non-manifold edges, inconsistent collider grids, exploding sand, and, last but not least, efficiently working with the outputs.

Let’s start with the input.

Simulation Input

We’ll have a particle input for the sand and three collider inputs: one for the floor and two for the space ship. The model’s guns are provided as a separate object, and it’s more convenient to use them as a second animated collider.

The Squishy Volumes input panel listing our three inputs.

Sand

The sand was relatively easy to get “right”. The sand is spawned in this simple square “bowl” with the Squishy Volumes default generating nodes.

Simple input shape, we can conceal it later.

It’s worth having the sand “soft”, since we pay for stiff material with a higher simulation runtime. Here, it’s 1 MPa Young's Modulus. Realistic values are at least 10 times that, but it has to be just hard enough to be visually convincing.

The default Squishy Volumes input generating modifier.

Space Ship

The space ship colliders were a bit tricky. But thanks to Blender operations and modifiers we can work around the non-manifold edges and use Squishy Volumes Collider Grid output to debug inconsistencies.

Non-Manifold Edges

The model does have a bunch of non-manifold edges. That is not a problem for rendering and many mesh operations, but it becomes problematic for determining whether a point is inside or outside a mesh. Squishy Volumes needs to do just that and throws this error:

The Squishy Volumes non-manifold error popup.

To inspect the mesh, we can use this select non-manifold operation:

That is where the non-manifold operator is hiding.

In this case, it’s possible to leverage Blender’s Remesh Modifier to get manifold geometry. This is with a Voxel Size of 0.05 m:

Remeshing gives us a nice mesh.

One might be tempted to use some adaptive remeshing, alas…

Inconsistent Collider Grid

If the collider mesh is “weird” enough, the grid embedding may become inconsistent. This can cause all kinds of wrong behavior.

In this case, I thought it would be a good idea to do some adaptive remeshing, but that caused some hefty squishing, and Squishy Volumes dialed down the adaptive timestep all the way to zero, which results in this error:

Squishy Volumes gives us a cryptic error popup.

It’s not obvious at all what’s causing this, but if we add the collider grid as an output like this:

The Squishy Volumes operator for adding outputs.

We can inspect the values visually and spot some issues at the tip of the vertical stabilizer:

The Squishy Volumes collider grid with some inconsistencies.

>.<

It is always a good idea to verify that the distance has a consistent sign (indicated by color).

Removing the adaptivity of the remesh modifier resolved the issue. The next challenge comes up during baking.

Baking

Squishy Volumes bakes the simulation by advancing in time step-by-step. We want the largest possible time steps for performance.

There’s a maximum value Time Step that we can specify, and with Adpative Time Steps enabled, Squishy Volumes will use a heuristic to determine a (smaller) safe value.

The Squishy Volumes bake panel with time step settings.

In this scene, the heuristic failed. A few frames into the bake, the sand explodes as the space ship pushes through it.

As a workaround, we can limit the timestep to 0.0005 s, keeping everything stable from start to finish.

It now remains to work with the output.

Simulation Output

During baking, we need a fast way to monitor progress. And once the simulation is finished, we want to be able to play it back quickly.

Visualize as Points

While baking, it’s a good idea to check the output every now and then. The default visualization modifier from Squishy Volumes lacks this, and its Deformed Cubes visualization can brick Blender. But a simple setup like this does the trick:

A simple node setup for point rendering.

This visualization doesn't brick Blender.

Even with millions of particles, the viewport stays responsive, and we can see whether our sand has exploded yet.

Once the simulation is finished, we can speed things up further.

Bake to Bake

The data transfer from Squishy Volumes to Blender doesn’t change after the simulation finishes. For a given frame, Squishy Volumes needs to read the simulation results from disk, perform some data wrangling, and hand them over to Blender via the “Rust->Python->C++” bridge.

That tends to be slow, and in this scene, it took seconds per frame. To add to the issue, the synchronization is driven by a frame-change handler that “magically” overwrites the geometry on the output object.

By utilizing Blender’s native bakes, we can alleviate these issues. We do add a manual step, though.

We can put this as the first modifier on the output:

A minimal bake node setup does the trick.

And then bake the Squishy Volumes bake into a Blender bake. This still needs to step through the frames and fetch the data in the same way as before, but it’s not being displayed while baking, and afterwards, it plays back fast.

We can now disable Sync on our simulation, which skips that whole data business:

The Squishy Volumes overview panel where we can disable syncing.

And in fact, we could disable Squishy Volumes completely now and get rid of the huge cache directory.

There are two things to keep in mind with this workflow.

We need to rebake the bake-to-bake each time we re-simulate
The Bake Target should be Disk, otherwise saving (and autosaving!) is slow.

But with this workflow, it can be quite satisfying to look at the animated result and inspect it from all angles, and it’s a real enabler for the creative work that follows.

Visualization

We’re done with challenges; in this part, we just talk about visualization tricks.

The sand is displayed as deformed cubes from the default visualization, but with a different material that has some sand colors and subsurface scattering.

Fake Floor

To smooth out the boundary between the actually simulated material and the static floor, we can add another “fake” surface. That surface has some purely geometric cubes scattered on it with the same look as our simulated ones.

Conceal the awkward input shape.

Dust Volume

Another trick worth noting here is to use a second particle output for the “dust”. For this second output, we use the basic surface reconstruction with scaled-up radii and convert it to a low-density volume. This way, it looks like the kicked-up sand produces dust and the spotlight’s cone becomes a bit visible.

The surface resconstruction can be used as a light-scattering volume.

Bonus trick: The Squishy Volumes Restrict View object operation allows you to view a selected region of material, which is very useful.

Then there are other topics, like the background and world shader, that we could discuss, but they are not directly related to Squishy Volumes and are much better covered elsewhere.

Conclusion

Here we go over the challenges again and discuss how Squishy Volumes could make them less challenging.

The error handling of the non-manifold issue might be good enough as it is. Blender provides tools to find and fix this issue, and it seems hard to fix automatically.

The inconsistency of the collider grid is something we can hopefully improve! It would be helpful to have some sort of automatic sanity check at the very least. This specific issue might also be a bug and shouldn’t have happened in the first place.

Unintended explosions are annoying, especially because they tend to occur some time into the bake. And the workaround of manually setting a low maximum can hurt performance. I suspect that the time-step heuristic needs to be changed. Needs more investigation.

Adding the cheap point visualization to the default modifier is a no-brainer.

The workflow utilizing Blender’s bakes is very exciting! Maybe Squishy Volumes can offer more tooling around it to reduce the number of manual steps. And maybe the data transfer could also be improved a bit; it still takes some time for the bake to record all the frames.

And of course, there are many more ways in which Squishy Volumes can and will improve that we didn’t discuss. One important one is overall performance. It’s still punishing to restart a simulation to try any different input. (GPU support, pls)

Finally, I think the result looks not too shabby! It is really cool what Squishy Volumes enables us to do, despite the challenges. This scene sets the bar for future Squishy Volume projects.

Try creating a scene with Squishy Volumes and join our Discord!

We are happy to help you out. <3

[1] This is currently the only supported mode. In the future, there will also be GPU support and implicit integration.

[2] Usually, when I'm posting something, for example on Discord, I like to share the .blend file. In this case the license of the space ship model prohibits this.

Making of Tree Clipper

Wed, 04 Mar 2026 00:00:00 +0000

TL;DR: Tree Clipper is an Add-on and library for exporting and importing as .

’ development has been on hold for the last couple of months in favor of . I am very proud to say that Tree Clipper is now ready for use and has been accepted on the official extension platform as well. Big thanks to the contributors, especially Brady Johnston and Jan-Hendrik Müller!

This blog entry provides motivation and an overview of the features, but is mostly about the technical challenges we faced while making Tree Clipper.

Check out the !

Motivation

Blender’s node trees are arguably a visual scripting language. Yet, the usual software development tools and workflows do not apply as it’s a graph-based language rather than a text-based one. You can see where I’m going here: Tree Clipper changes that.

And JSON is a handy text-based format because many tools in many languages support it. If only it had trailing commas.

(╯°□°)╯︵ ┻━┻

From my perspective, a software developer’s perspective, this is already ample motivation. But wait, there’s more: It’s actually really easy to go from JSON to a compressed (Base64) string and back! This provides a convenient way to share that is useful for any Blender node tree user. (Not only add-on devs)

Shoutout to Brady Johnston for this idea!

If you have ever played with any vigor, you have also encountered its and maybe also one of the unofficial sharing websites, like . Basically, Blueprints are also compressed strings that enable players to copy and share designs via the system clipboard. Need a ? Just copy from the browser & paste in-game without losing a beat.

So that is another angle to look at Tree Clipper: it enables us to do a with Blender’s node trees. Imagine the speed with which we could exchange ideas, teach, and debug. Not to mention that we can analyze and search JSON with lean tools without depending on the Blender executable.

The potential is exciting!

Why Not Use <..>?

Yes! Depending on what we want, there are better solutions.

For example, binary .blend files might be better suited. Especially, if we’re also interested in exporting/importing meshes or other large data. Node trees can be loaded from a .blend file . And there’s the , which offers a nice set of workflows. These can also leverage Blender’s own compatibility system. Nice!

Given that we’re interested in a text format, we’re out of luck when it comes to official support. There is no official JSON (or any text-based) export/import of nodes, and a relatively recent for this was rejected.

However, there are a few add-ons that are similar to Tree Clipper. Let me refer to the section of the README on GitHub.

Features

Alright! Tree Clipper’s purpose is to export and import nodes as JSON. It does that. Trees, subtrees, interfaces, nodes, links, sockets, the whole shebang.

Basic Workflow

We get a panel in the (geometry/material/compositor/texture) node editor that looks like this:

Exporting

This is the basic pop-up for exporting (the current tree and subtrees are exported):

We make two choices here.

Either save directly into the Clipboard or to a File on disk. This is needed because (very) large setups do not fit into the system clipboard.
For sharing, the Compressed Base64 string is more convenient, but plain JSON is preferable for add-on development.

Here are two export examples:

Compressed:

TreeClipper::H4sIAAQhjmkC/+1XbW/iOBD+K1U+rxDZAi33rarQCh0Lqy2ctFpVlnGG4KtjW7YD7VX89xs7CTg0x+2edLrVafuBwrw4M8/MM568JmsBMgNDdmAsVzL55SoZ9vq9NHl3lTgDQJjgWrcNUN0begOpMiDeyqL462vCM/zfR0VGHcWvr4mkBXiXD6AKcOblao4u1vuWFsiGPgHBLwZNNlRYqOXw7AxtFM6UXs4tMaV0vABSn954OJpHv5gSypBKlswX84l/WAYbWgpHcqNKTULYe565LdqkgxAwWGa4dnWG3mctfAS1C5cOzIYyiAKKRHXqaZw6ZY7vAD0zeK513EFhA2Ann/exTzCIsLy+hGXSHbdV7AkccS86WHvAH4Io9ttyhGBHRQkRdEHIJSlUxje8VZWNMgwQOElQIbJIg3Xh0mpgjqjS6dK1dZpKEMSpPBfxowR9wZ6yINCPd5xagCyxDdA7g1iuQqpUEEHXICIFdc7wdemwO1RBeUDj02I6X8blPxk1WAbAsKDMlQaOmN2tlovYj8sqr+S3u9kqNBSipCrRYrX8tApP8cU7HvGwuP91skwOh3dNoQc/a/mj13I6v1jKx8PB1zOMPXti8PAt6/HrqOF7ROdRbCkUo3Wtv47f93s4hm7x89EjWqsIXVslMMcOm2h+eXGyBZ5vfRZpvxIcW8wPsKtpSDtUqwI7wLWnRnKZE22UpnkTTnI3mzUjmpXWqYKEqXo+ZX1U/d6ofzPGv9v+YDAe3YwQjW+T+SSqponOtVu1J1Vj2NOoDVJtYMdhf9bjcZ9VQLWOcniVYDfEfeyBiKp30zl/H0OhKxJExreXhvX4HxD8LAWQFC/k7JS54PKJCF5wD9KgPx42iXXwqXMOaOzunP9RqPjCrBv7w2TxcbL8/CXExq1GIhO7pZVyNsWrMxpfaee9/iOmdb96WC4+diZ1P/18P5tUVK6ueJ41qfjhGrhypIqmBqSPUJZCxFCkf8VjJOPfE/nc6DuZvKgm808qv6FyenGXSq//bX6m/x05B/8/cr4ZvunwwqjupvKJKy0uV+tMvaAfNx2ffudkaHrEH7v0y7vfUaRUrmFZfaYHLo53dLEd2xeP9SjyrPW+41kQg70xSN9qJayvG6dOv9PrJnh0dUqJ9vIWLYLRE/ybkFr/3mZuo4CMd4ktK4XuUmjc1c7kvuykALvtELPS7KBDrhUew4Qqs7PXwj3ljuD26t9J2VOHZ26Aop0Gybg4nx8NAKSgkuZQbbOnsnsmPOMbHS6kviIeR8tAVove4fAn7fQnsCoPAAA=

JSON:

{ "blender_version": "5.0.1", "tree_clipper_version": "0.1.5", "node_trees": [ { "id": 0, "data": { "name": "Geometry Nodes", "use_fake_user": false, "use_extra_user": true, "is_runtime_data": false, "tag": false, "color_tag": "NONE", "default_group_node_width": 140, "description": "", "bl_use_group_interface": true, "interface": { "id": 1, "data": { "active_index": 1, "items_tree": { "id": 2, "data": { "items": [ { "id": 3, "data": { "name": "Geometry", "description": "", "socket_type": "NodeSocketGeometry", "hide_value": false, "hide_in_modifier": false, "force_non_field": false, "is_inspect_output": false, "is_panel_toggle": false, "layer_selection_field": false, "menu_expanded": false, "optional_label": false, "attribute_domain": "POINT", "default_attribute_name": "", "structure_type": "AUTO", "default_input": "VALUE", "in_out": "OUTPUT", "item_type": "SOCKET" } }, { "id": 4, "data": { "name": "Geometry", "description": "", "socket_type": "NodeSocketGeometry", "hide_value": false, "hide_in_modifier": false, "force_non_field": false, "is_inspect_output": false, "is_panel_toggle": false, "layer_selection_field": false, "menu_expanded": false, "optional_label": false, "attribute_domain": "POINT", "default_attribute_name": "", "structure_type": "AUTO", "default_input": "VALUE", "in_out": "INPUT", "item_type": "SOCKET" } } ] } } } }, "nodes": { "id": 5, "data": { "active": 6, "items": [ { "id": 6, "data": { "location": [ 920.0, 80.0 ], "location_absolute": [ 920.0, 80.0 ], "width": 140.0, "height": 100.0, "name": "Group Input", "label": "", "warning_propagation": "ALL", "use_custom_color": false, "color": [ 0.6079999804496765, 0.6079999804496765, 0.6079999804496765 ], "select": false, "show_options": true, "show_preview": false, "hide": false, "mute": false, "show_texture": false, "inputs": { "id": 7, "data": { "items": [] } }, "outputs": { "id": 8, "data": { "items": [ { "id": 9, "data": { "name": "Geometry", "description": "", "hide": false, "enabled": true, "link_limit": 4095, "show_expanded": false, "hide_value": false, "pin_gizmo": false, "type": "GEOMETRY", "display_shape": "LINE" } }, { "id": 10, "data": { "name": "", "description": "", "hide": false, "enabled": true, "link_limit": 4095, "show_expanded": false, "hide_value": false, "pin_gizmo": false, "type": "CUSTOM", "display_shape": "CIRCLE" } } ] } }, "bl_idname": "NodeGroupInput", "parent": null } }, { "id": 11, "data": { "location": [ 1400.0, 80.0 ], "location_absolute": [ 1400.0, 80.0 ], "width": 140.0, "height": 100.0, "name": "Group Output", "label": "", "warning_propagation": "ALL", "use_custom_color": false, "color": [ 0.6079999804496765, 0.6079999804496765, 0.6079999804496765 ], "select": false, "show_options": true, "show_preview": false, "hide": false, "mute": false, "show_texture": false, "inputs": { "id": 12, "data": { "items": [ { "id": 13, "data": { "name": "Geometry", "description": "", "hide": false, "enabled": true, "link_limit": 1, "show_expanded": false, "hide_value": false, "pin_gizmo": false, "type": "GEOMETRY", "display_shape": "LINE" } }, { "id": 14, "data": { "name": "", "description": "", "hide": false, "enabled": true, "link_limit": 4095, "show_expanded": false, "hide_value": false, "pin_gizmo": false, "type": "CUSTOM", "display_shape": "CIRCLE" } } ] } }, "outputs": { "id": 15, "data": { "items": [] } }, "bl_idname": "NodeGroupOutput", "parent": null, "is_active_output": true } } ] } }, "bl_idname": "GeometryNodeTree", "annotation": null, "links": { "id": 16, "data": { "items": [ { "id": 17, "data": { "is_valid": true, "is_muted": false, "from_socket": 9, "to_socket": 13 } } ] } }, "is_tool": false, "is_modifier": true, "is_mode_object": false, "is_mode_edit": false, "is_mode_sculpt": false, "is_mode_paint": false, "is_type_mesh": false, "is_type_curve": false, "is_type_pointcloud": false, "use_wait_for_click": false, "is_type_grease_pencil": false, "show_modifier_manage_panel": true } } ], "external": {}, "scenes": {} }

Importing

The import adds the tree as a group node by default:

That’s it, byeee ~

External Items

Ok, there’s a good chance that the basic features are plenty enough for us, but what if we reference “external” items like other objects or materials or collections or images or …

There are no external items in the basic example above, but have a look at this one and notice the additional UI in the export pop-up:

Now, these references to objects, materials, etc., could be vital to the setup’s function! But we’ve drawn our line in the sand; those can’t be in the export. The next best thing we found is to provide the export user with the means to create an import interface of sorts. Meaning, the exporter can provide a “hint” on what the item should be set to on the importing side.

For the importer, it looks like this:

These listed items can then be filled by the already existing objects, images, collections, etc., in the importer’s Blender project before running the actual import.

That’s it for real, bye.

Backwards Compatibility

( ͡° ͜ʖ ͡°)

Starting from Blender 5, which is also the minimum version, we have backwards compatibility! Tree Clipper would be much less useful without it.

At the moment, it’s really just getting things from 5.0 to 5.1, but that worked out pretty good. For example, the , and Tree Clipper does what you’d expect:

Use in Other Addons

Alright, one more key use case for Tree Clipper.

The tree exports can be shipped with other add-ons, which can then import these setups for their users. This is possible because the core logic is a separate available on .

Other add-ons can also define additional properties on the built-in nodes or define new node types altogether. It’s expected that third-party add-on devs will either overwrite the existing handlers or provide additional handlers for their custom types. More on this in the .

If you are an add-on developer and would be interested in using Tree Clipper in that way, HMU! There’s little to no documentation on how to use the core logic, and we’re still figuring out what the API should look like.

That’s about all I wanted to point out feature-wise. Come stick around and see how it works under the hood!

How it Works

How it Works? How it Works.

So, this might be obvious, but we’re limited to the Python API for exporting and importing node trees. The task is to scrape all the information we need to recreate a given node tree And good news: the information we need to recreate is available via the Python API!

And (almost) all (except for ), information can be scraped and recreated in the same way.

We’ll glance at exporting, look at the handlers used for exporting and importing, and see that importing is much more involved than exporting.

Exporting

To export, we feed the (root) tree to a recursive function ( ), which takes a Python object and populates its JSON representation with the results of recursive exports of its properties. That’s the basic idea.

The are limited to simple data types (bools, ints, floats, strings, and enums, which are also strings), pointers to other Python objects, and collections of Python objects. That might sound like a lot of properties, but it really narrows down what Tree Clipper must be able to handle, and all these properties map nicely to JSON!

Here’s a schematic of what the structure of a tree looks like from the Python API:

The point here is that we can reach all of the interesting stuff by following the arrows. In some cases, we can get there by taking multiple paths. For example, the sockets of a link are always part of the inputs or outputs of the respective node. The depth of this structure isn’t bounded; there can always be another subtree within a .

Depending on the type of object, e.g., , we want to export different things. An exported link looks something like this:

{
    "id": 199,
    "data": {
        "is_valid": true,
        "is_muted": false,
        "from_socket": 13,
        "to_socket": 75
    }
}

Each exported object gets an id and data, and in this case, the pointers to the sockets have been serialized beforehand and are referenced by the id they received at that time. Checking the , there are a few things that are skipped because we don’t need them to reconstruct the link. is_valid and is_muted should also be skipped if they’re set to the default. Optimization for the future.

In any case, we want to specify handling for certain types while retaining a default export for most cases. There are, after all, 500+ different node types, and most fall into the “simple” category.

So, we’ve opted to build a general recursive algorithm that can take care of the “simple types” while still allowing us to take the reins and specify some special export logic for types we deem “complex”. The type-specific code is contained in the respective handler.

Handlers

Passing a handler is the way to override what Tree Clipper does for a given type. Upon construction, the exporter (and importer as well) is , and for each object the exporter (or importer) encounters, it first tries to find the best match in that dictionary.

The best match could be a base class of that type. Here’s the that finds the most specific handler for a given type. And this enables us to define a partial handling of a type.

There is a set of properties already in the base class; those are considered handled, while the remaining properties of the actual type are considered unhandled. For the unhandled properties, a general export/import is applied. in the export and this in the import.

It’s worth noting that if there is a handler for a more general base class and also a more specific base class for a given type, the more general handler is completely ignored. That is a double-edged sword: we get complete control over specific types, but we also need to repeat ourselves for common things.

Tree Clipper provides the , which handle the special cases for Blender’s built-in nodes. (In that same file, the handlers are defined) The idea is that third-party add-ons with custom node types can modify it.

Importing

Importing is much more involved than exporting.

But first, let’s establish the similarities to the export. We also “follow the arrows” in a general recursive function ( ). And we also use handlers to specify logic for specific types.

The main difference is that we’re recreating and filling the structures as we go. Given a tree in JSON form, we start by adding a new node group, flesh out the interface, add the nodes one by one, and finally establish the links.

Apart from the order, there’s also this nasty pitfall to avoid: . And we are modifying containers all the time while importing. We’re adding trees, nodes, and links.

Getters

To avoid this pitfall, there are s in Tree Clipper. They are callables without arguments and return a “fresh” (and therefore safe) reference to the object we’re currently importing. The getter is passed down the recursion and is “wrapped” at each level.

Here we’re descending into a property with an identifier and wrapping the getter accordingly.

self._import_obj(
    getter=lambda: getattr(getter(), identifier),
    serialization=serialization,
    from_root=from_root,
)

And here, we’re iterating over the items of a collection and importing them, one by one.

def make_getter(i: int) -> GETTER:
    return lambda: getattr(getter(), identifier)[i]

for i, item in enumerate(serialized_items):
    name = item[DATA].get(NAME, "unnamed")
    self._import_obj(
        getter=make_getter(i),
        serialization=serialized_items[i],
        from_root=from_root.add(f"[{i}] ({name})"),
    )

The importer also tracks getters for all imported objects, which can be looked up by the id assigned by the exporter. That is how Tree Clipper can recreate links!

Order, Order!

The order in which we import stuff is important.

Let’s jump right to one of the most complicated cases: . Consider this setup, we’re able to define a default for the interface item “Menu”: However, since the possible values of this default are defined by the “Menu Switch” node on the right, we lose the ability to define a default if the connection is broken:

That means, to faithfully recreate the former setup with the default defined, Tree Clipper needs to order the import as follows:

Import the interface so that the sockets appear on the “Group Input”.
Import all the nodes, including their properties, so that the right side of the “Repeat” zone has a “Menu” entry and the “Menu Switch” has the enum variants. The sockets are implicitly created.
Pair the two ends of “Repeat”. Then the left side also gets the “Menu” socket.
Import all the links between the sockets.
Finally, set the default value for the “Menu” in the tree interface.

Rest assured, there are more tricky-icky things, like the ordering of interface items and multi-links, that need some special attention. But we’ll leave it at this example.

Testing

After implementing Tree Clipper, I’d personally have no trust in a solution that doesn’t have automatic tests. We have 🌟extensive🌟 tests for Tree Clipper. There were so. many. bugs.

We have generated tests, round-trip tests for really complex setups from community .blend files, and tests for specific bugs we’ve found and fixed.

Of course, that doesn’t mean that there aren’t any bugs. In fact, I’d put some big money on bugs! Bugs are always a good bet.

Future Work

Tree Clipper is just starting to get some traction in the Blender community. I hope this section will quickly go out of date :)

Compositor Nodes

Importing compositor nodes is less fun than it should be.

Have a look at the ; this part fuels my nightmares:

Additional outputs for any enabled render passes.

That means that the render passes of the , which is an external item, define the sockets of that node. Ugh.

So the importer needs to have a scene where the render passes match those the exporter used.

Currently, Tree Clipper exports that information and complains if the provided scene’s render passes don’t match, but it’s really annoying to fix it. Maybe Tree Clipper can adjust the scene to fit. That could be an unexpected change to the user of the import, though.

It may be acceptable if there were a pop-up warning 🤔

Import Performance

The other issue is that large node trees can take a long time to import.

Regrettably, this is not something that will go away quickly. It is a broader performance issue in how Blender verifies nodes added via Python. The more nodes there are in a group, the longer verification takes, so the runtime is quadratic in the number of nodes in a given group.

The workaround is to divvy up the nodes into more groups before exporting.

Key-Framed Values

This is a blind spot Tree Clipper still has >.< The Rotation socket in this Transform Geometry node is animated, but Tree Clipper will export whatever its current value is.

Conclusion

Developing Tree Clipper was more fun than it had any right to be. I’ve personally learned a lot about Python. Even though I do love Rust for its static typing and logic, it was refreshing to have almost none of that.

Tree Clipper is going to power the generation of Squishy Volumes’ node setups in the next release. And so far it’s going really great!

I hope that Tree Clipper can be useful to you as well <3

BCON 2025

Mon, 29 Sep 2025 00:00:00 +0000

The Logo is from the Blender Conference 2025, licensed under CC BY-SA 3.0.

TL;DR: It was a blast, three days of excitement and inspiration; if you’re considering attending next year, do it! Here’s the recording of my talk about Squishy Volumes:

Algebraic’s Squishy Volumes is an extension for Blender that allows you to simulate squishy stuff through the power of the Material Point Method (MPM)! We suspected that we were flying under the radar of potentially interested Blender users. To get our extension out in the open, I attended the Blender Conference (BCON) and gave a talk about it! Indeed, just a couple of days after the conference, we had new users eagerly creating their own simulations and exploring the limits of Squishy Volumes!

It was my first time at the BCON. I was definitely nervous, not only because presenting tends to be nerve-racking, but also because I had yet to meet the attendees IRL. Shoutout to blender.science Discord server! Connecting beforehand gave me much-needed confidence.

Any worries I had were (of course) completely unfounded because the Blender community is absolutely fantastic. I experienced an intense mix of collaboration and shared fascination, met so many awesome people, and it was packed with really cool art! The venue itself was also beautiful.

Photo by Raymond D. Neoh, Blender Conference 2025, licensed under CC BY 4.0.

My talk about Squishy Volumes and the extension itself was really well received. This feedback is obviously very motivating. The fingers are itching to make tutorials, add more features, improve usability, and maybe most pressing: implement GPU acceleration!

While the main goal was to share Squishy Volumes, many of the other talks were very interesting to me. Highly important are the recent updates in the realm of physics simulation within Blender itself and this related talk about Hair Simulation:

We will follow this development closely. At some point it may be possible to integrate MPM (or Squishy Volumes) into Geometry Nodes directly! The future will tell. And while it is currently impossible for extensions to define new nodes, there might be some very cool interop at the very least.

Apart from simulations, I’d like to mention these two talks in particular. Real science meets Blender. The kicker is that we are helping science along just by interacting with Blender! Apart from that, this demonstrates that large numbers of MPM particles will work just fine.

And one encounter was especially inspiring: William the Wunderkind. He created a full-blown piano with keys, hammers, dampers, and more, all in Blender, all by himself. Not something you would expect from the average child! The piano isn’t just for static renders, no. Using the knife tool and Blender’s native physics, he created an eye-catching animation: the piano goes into an industrial shredder. Amazing! We got to talk about Squishy Volumes, and I don’t think anyone at the conference asked questions about the extension with such genuine interest. The piano-into-the-shredder-scene is a really tough challenge for Squishy Volumes, and, of course, now it is a mandatory Milestone to reach. Thank you for this inspiration, William.

Another thing that cannot be overstated is that Flow, and Blender by extension, won the Oscar! We got to pose with it, how cool is that?! Here are two pictures, and BTW all these people are actually members of the aforementioned Discord server.

Photos by Jelmer de Haas, Blender Conference 2025, licensed under CC BY 4.0.

After every conference day, and before the first one, there’s a semi-official meetup at this cozy bar: deBALIE. This is a very accessible way to continue that important discussion or to just relax and reminisce.

As usual for me, two days after the conference, I’m in bed with a high fever. It seems that it also got a good number of other attendees. Another thing in common, I guess.

I attended the conference with the hope of inspiring others. I’m happy with my attempt and am eager to continue on this course. I found myself returning with a head full of fresh ideas, new friends, and a glowing soul. I can barely contain my excitement! ❤❤❤

PS: if you haven’t, please try Squishy Volumes and join our journey!

About Algebraic

Tue, 17 Jun 2025 00:00:00 +0000

Welcome!

I’m excited to introduce Algebraic, an independent company based in Germany, focused on developing plugins and games.

A little about me: I founded Algebraic in late 2024 to pursue my goal of publishing a custom physics engine for Blender, offering specialized features, dedicated support, and remote compute services. With over five years of professional software development experience, a Master’s degree in Computer Science from RWTH Aachen, and a genuine passion for Blender, I’m committed to delivering high-quality tools for creators.

Fueled by curiosity, coffee, and the occasional cat nap from my companions, Miri and Mia. Thanks for visiting!

Rust Blender Extension API with Hot Reloading

Tue, 17 Jun 2025 00:00:00 +0000

Blender and Rust are two of my favorite things. Over the years, I’ve tried a few ways of combining them, and here I’d like us to retrace the steps that led to one way that I’m particularly fond of:

A Blender extension that calls reloadable Rust code. Find the project with build instructions on GitHub.

As an example, this extension takes a mesh object and creates a new object consisting of point samples that are inside the mesh. To detect the inside, the extension leverages generalized winding numbers.

Here’s a screenshot of the video at the end.

Note that you could achieve this entirely with Geometry Nodes in default Blender by chaining a Mesh to Volume Node with a Distribute Points in Volume.

Motivation

Let’s assume the following. We have our idea for Blender and want to build the core logic with Rust. We prefer Rust over Python, maybe because of performance, or because we want to reuse some other Rust code, or maybe just because we think that Rust strikes the best compromises of any programming language out there!

We don’t want to create a custom Blender build from source (in this case, C/C++ would probably be the better choice), and we expect to tinker in the core (Rust) implementation for the most part of the development. Also, and this is key, the application programming interface (API) is not going to change much.

In essence, we want to use Rust and have fast development cycles.

Making Choices

There are many ways to get this done. I’d like to mention one important alternative right now: (re-)start a separate local server process. If your API is going to change a lot, you might want to look into that instead.

Blender’s Extensions

Let’s make it our first goal to avoid rebuilding Blender from source. A good way to achieve this is to build an extension. Extensions are easy to distribute and install. Extensions are written in Python, and we get an extensive API with Blender’s Python Module (bpy). We can write up our extension and bundle it into a ZIP file with Blender (from the command line). This ZIP file can then be installed from within Blender.

Within the Python part, we need to do three things:

Register and build the user interface
Read and write Blender’s Data
Call our core logic

Python is good, but we want Rust for the core logic!

Wheels Make it Go!

So, there’s our next challenge: how can we bridge between our beloved Rust and Python, which seems to be a mandatory stopover. Since both languages have been very popular for years, it’s unsurprising that a mature solution exists: PyO3.

It seems natural to wrap our core logic into a Python package, a wheel. This allows us to import it in other Python code for automatic testing. More importantly, this is the default way for Blender extensions to load binary code. PyO3’s maturin will turn our Rust code into a wheel file.

This file needs to go into our extension’s source tree, and we need to list it in the extension’s manifest; it’ll be bundled with the ZIP file, and we’ll be able to import our module from the extension code!

Let’s visualize where we are at.

Great, right? Nope, it’s horrible!

we expect to tinker in the core implementation for the most part of the development

The issue is that this approach doesn’t allow us to iterate on changes in the core logic with any speed to speak of. And it might be worse than you think.

Dynamic Libraries are too Static

First, let’s go back to how we “magically” get to call our Rust code from Python. A crucial detail for the wrapping library crate is that it needs to have the crate type cdylib, meaning it’s going to create a shared library with the binary code compiled from our Rust code. Then, the Python side can request that this shared library be loaded by the operating system (OS), find functions by name (there’s a lookup table), and call them. That is, assuming that the application binary inferface (arguments, etc.) matches what the Python side expects.

Dynamic and shared libraries refer to the same thing, but the OS prefers to think about them as shared. The OS would rather have different calls, threads, and processes reuse and share the library as much as possible. This is nice, but it hinders us from swapping it out for a new version! While it is possible to unload a shared library in theory, it isn’t easy to do reliably in practice. For example, the dlclose function Linux provides won’t work if any of the library’s symbols are still “in use”.

We finally arrive at the issue: we cannot change anything in our core logic and use it in our running Blender process. Instead, we have to shut down Blender, rebuild everything, and start again. Only to find that some cache still has our old version! Explicitly deactivate our extension, rinse, repeat.

This is annoying, especially if you have to reproduce some state in Blender to test a particular thing.

Finally, Reloadable Code

Actually, for the Python side, hot-reloading is readily available. We can use VSCode with this super helpful addon for extension development. Not only does this alleviate the need for explicitly building the ZIP with Blender on the command line (and installing it from disk), but it also gives us the option to reload our Python code!

So, that is the Python side done.

For the Rust side, we can go with David Wheeler: “All problems in computer science can be solved by another level of indirection.” There is a hot-lib-reloader solution in pure Rust that we can use between our core logic and our wrapping crate!

I’m not entirely sure how it works, but I believe the rather cheeky trick is to constantly make new names for the shared library that we want to be reloadable. This way, the operating system is forced to load the latest version from disk. Of course, the upper layers of our Matryoshka extensions are none the wiser, which is good!

So, that is the Rust side done, as well!

Live With the Choices

Good Idea I Stand By It GIFfrom Good Idea GIFs

Preventing Race Conditions

Actually, we’re not quite done with the Rust side. With our trickery, we’re angering the race-condition-gods, and we need to place at least one synchronization primitive to appease them.

Unfortunately, there are several subtle ways to mess this up because there is a thread from the hot-lib-reloader whose task is to replace our library, and it acts asynchronously. Here are some ideas of what might go wrong:

Some of the binary code we’re replacing is currently running
We have handed references to some structs in Rust to Python, and now their layout has changed

And there’s more: even though Python would traditionally allow only one call to our module at a time, due to its global interpreter lock (GIL), that isn’t necessarily the case anymore. And in our case, we’re going to get parallel calls from Blender and its render engine.

For once, we’re happy about the persistence of the shared libraries. It’s not possible to pull the shared library from under our feet while we’re still using it!

We’re not going to deal with all issues in a foolproof way, but the following tricks get us there most of the way.

Use a “context” trait to expose core logic
Allow a single context instance to exist at one time
Protect this instance with a mutex
Explicitly synchronize the library-reloading-thread

We think about this context as our reloadable library. Now we’re jumping ahead to show a few relevant places in the code: we’re left with a single function that needs to be hot-reloaded:

#[unsafe(no_mangle)]
pub fn create_context() -> Box<dyn Context> {
    println!("creating new rust context");
    Box::new(Impl)
}

And the spicy part of the code that deals with reloading looks like this:

let lib_observer = rust_hot_reload::subscribe();
loop {
    // wait for reload and block it
    let update_blocker = lib_observer.wait_for_about_to_reload();

    // wait for any library calls to finish and block further calls
    let mut context_guard = LOCK.lock().unwrap();

    // cleanup
    let context = context_guard.take();

    // this should block until any threads are joined and any resources are dropped
    drop(context);

    // let the library update commence and wait until it's finished
    drop(update_blocker);
    lib_observer.wait_for_reload();

    // fresh context with new lib version
    *context_guard = Some(rust_hot_reload::create_context());

    // context_guard is dropped and calls can continue
}

The middle part here is where we can still mess up. If we have any threads or resources in our core logic that might cause trouble when it’s replaced, they need to be joined and cleaned up when the context is dopped in a blocking fashion.

The Catch

I’ve hinted at this a few times; now it’s time to stop beating around the bush. Even with our fancy-schmancy reloading schemes, we should not hot-reload if we change our API (aka. context trait). If we do this anyway, all bets are off, and undefined behavior (UB) ensues. Let me point to the hot-lib-reloader blog post again for further caveats. Whether this partial reloadability is worth giving up certain safety guarantees during development is for you to decide.

Of course, we can regain the safety we’re losing as soon as we compile without hot reloading. Once we’re building to distribute, we can’t use hot reloading anyway.

Overview of the Code

Here, we examine the top-level structure, summarize the build and reload process, and conclude with testing the hot reloading.

We have four different Rust directories (crates) serving various purposes and a single python directory. Let’s visualize this!

rust_api

This crate defines context trait; it’s not reloadable.
rust_core

This crate implements the context trait; we implement the core logic here, and it’s reloadable.
rust_hot

This crate exposes one reloadable function that creates an instance of the context (and re-exports the context trait). We don’t need to edit this; it only exists to facilitate splitting the API and core logic. This crate is also the one we’ll rebuild for reloading.
rust_wrap

This crate is on the boundary to Python. Here, we rely on PyO3 to create a Python module and also utilize the hot-lib-reloader to orchestrate the reloading of the context creation function.

For the first build and, whenever we change something in the API, we let maturin create a new wheel from rust_wrap and build rust_hot using the standard cargo command. If Blender is running a prior version of our extension, disable the extension and shut down the Blender process as well.

However, for any subsequent changes to our rust_core, we only need to rebuild rust_hot using the standard cargo command.

See it in Action

Now we can tinker in our core logic to our heart’s content and immediately see the result in Blender. Check this out:

Conclusion

First, let’s address the drawbacks: this approach is clunky to get started, and it doesn’t alleviate the growing pains of the API. If we reload with a changed API, we’re toast (we get UB). And if we’re not careful in cleaning up our context, we might get bitten by zombie threads.

But once it’s up and running, we can write Rust code as if it were a natively supported language! We have direct function calls without any serialization overhead and benefit from the Rust ecosystem to accomplish nearly everything we want, from high-performance numeric parallel GPU tasks to complex networking.

Furthermore, we could build on existing solutions that work and primarily focus on plumbing. Shoutout to PyO3, the Blender Development addon, hot-lib-reloader, and, of course, Blender, Python, and Rust! ❤❤❤

Thank you for reading!