Object Unlink Data

Here's a Blender fact that bites people in graphs exactly the way it bites them in the viewport: two objects can share the same mesh data. You duplicate an object, and Blender is smart about it - the copy points at the same mesh until you edit it. That's efficient, and it's also a silent landmine. When you change that shared geometry, every object using it changes, and suddenly your left eye and right eye are both being remodeled.

Object Unlink Data is the tool for that moment. It wraps bpy.ops.object.unlink_data(), which makes the active object a single user of its own data - it copies the mesh (or curve, or whatever data block the object references) so future edits stop rippling through the shared copy. In a character rigging flow, that's the step you run right after you duplicate a mesh and are about to modify only one of the copies: left eye mesh, duplicate it, unlink it, then sculpt the left eye without touching the right.

It's a one-input node: BPY_OBJ is the object to break away from shared data. Output is that same object, now with its own private copy of the mesh. Nothing to tune, nothing to get wrong - this is the rare auto-generated wrapper that does exactly what you'd hope with a single knob.

The subtle version of this that trips people up: the pack also has Object Transform Apply, which can bake transforms into shared data and silently modify every object that uses it. That node has an isolate_users flag to guard against exactly that, and this node is the manual version of the same idea. If you're applying transforms or deforming geometry on anything you've duplicated, unlink first, apply second - the ordering matters.

Install is pack-wide: ComfyUI Manager → "Avatar Graph", or git clone https://github.com/avatechai/avatar-graph-comfyui into ComfyUI/custom_nodes and pip install -r requirements.txt on Python 3.10 (bpy==3.6.0). First launch downloads the ~2.4 GB SAM model.

Troubleshooting: run this on an object that's already single-user and it's a harmless no-op. The failure mode to watch for is the opposite - not running it, then wondering why editing one eye changed the other. If you never duplicate meshes, you may never need this node, but it's the cheap insurance that makes duplicate → modify-one pipelines behave.