Nodes/Avatar Graph/Object Call Update Tag
ComfyUI Node

Object Call Update Tag

Force Blender's dependency graph to notice a change

By avatechai·Created 3 years ago·Updated 2 years ago· 264
Object Call Update Tag
  • BPY_OBJ
  • BPY_OBJ

If you've done Blender scripting before, you already know the feeling: you mutate an object's data through Python, nothing crashes, but the viewport (or whatever depends on it) just... doesn't update. That's what this node fixes. It's a 1:1 wrap of Blender's ID.update_tag() - it doesn't change your mesh, your rig, or your image, it just tells Blender's dependency graph "something about this object changed, go recompute whatever depends on it."

Where it fits in Avatar Graph

Avatar Graph (avatechai/avatar-graph-comfyui) is the pack behind this node - it rigs a flat character image into an interactive avatar by segmenting it, meshing each piece, and driving the mesh with a "Shape Flow" runtime graph. The README only documents a handful of nodes (Segmentation, Create Mesh Layer, Join Meshes, Create Shape Flow, Avatar Main Output); this one isn't among them. It belongs to a much larger, undocumented family - the pack auto-exposes most of Blender's own Object API as draggable nodes, and Object Call Update Tag is one of those raw wrappers. You'll only reach for it if you're chaining several Object_* operator nodes together and something isn't refreshing between steps - not while following the standard rigging tutorial.

How it works

Blender caches a lot of derived state - modifier results, dependency graph evaluations, viewport draw data. If you poke an object through a lower-level API call that doesn't go through Blender's normal "this changed" bookkeeping, that cache can go stale. Calling update_tag() marks the object (and, depending on flags, its data or its transform) as dirty so the next evaluation picks up the change. It's a nudge, not an edit.

Inputs and outputs

There's exactly one field, and it's optional:

  • BPY_OBJ - the object to tag. Leave it unwired and the underlying call falls back to whatever object is currently "active" in Blender's own context - the same behavior you'd get running bpy.ops from the Python console without selecting anything first.

The output is also BPY_OBJ - the same object, passed straight through. That's the pattern across this whole node family: each one takes an object, does its one thing, and hands the object back out so you can keep stringing more Object_* nodes onto the same chain without breaking the wire.

How to install it

Install through ComfyUI Manager - search "avatar-graph-comfyui" and restart - or clone it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/avatechai/avatar-graph-comfyui
cd avatar-graph-comfyui && python -m pip install -r requirements.txt

The hard requirement that actually trips people up: the pack pulls in Blender's bpy package, and bpy is pinned to Python 3.10.x, nothing newer. Windows users get a prebuilt Python 3.10 ComfyUI zip in the README for exactly this reason; on Mac/Linux, build a dedicated conda env (conda create --name comfyui python=3.10) instead of fighting your existing one. Restart with --enable-cors-header so the live avatar preview can talk to editor.avatech.ai - skip it and exports still work, you just lose the live panel.

Common issues & troubleshooting

The install is the fragile part, not this node. Because bpy needs Python 3.10 specifically, dropping the pack into a 3.11/3.12 environment - the default on most current ComfyUI setups - will fail outright. There's at least one report of installing Avatar Graph on ComfyUI Desktop leaving the install badly broken (an oversized logo, a stray audio-permission popup) badly enough that a full ComfyUI reinstall didn't fully clear it. Test it in a fresh or portable ComfyUI instance first if you're not already on a dedicated 3.10 environment.

As for the node itself: it can't error in any interesting way, and it also can't fix a genuinely broken graph - if something downstream still isn't reflecting a change after this node fires, the more likely culprit is that the object you actually needed to tag wasn't the one wired (or active) at that point in the chain, not that the tag call silently failed.

Categoryblender

Inputs (1)

NameTypeDefaultDescription
BPY_OBJoptBPY_OBJ

Outputs (1)

NameTypeDescription
BPY_OBJBPY_OBJ