Mesh Primitive Cube Add Gizmo

This is the odd sibling of Mesh Primitive Cube Add, and the naming tells you why: in Blender's own UI, "Cube Add Gizmo" spawns a cube you can immediately resize by dragging a little on-screen handle, before it's committed to the scene. Both nodes ship in Avatar Graph - the avatar-rigging pack that turns a 2D portrait into a blinking, lip-syncing character - because the whole pack runs real Blender via the bpy Python package behind the scenes, and every Blender mesh operator gets auto-exposed as a ComfyUI node. This one's bpy.ops.mesh.primitive_cube_add_gizmo, unmodified.

How it works - and why it looks different from the plain cube

Same result as the regular cube-add: a new cube mesh object in the scene. The interesting part is what's missing. The plain Cube Add node has a size field. This one doesn't - because in real Blender, the gizmo variant is built for interactive resizing after placement, so its sizing lives in the transform (scale, or a full transform matrix) instead of a single number typed in up front. That's a genuinely useful distinction to spot: it tells you this node is a mechanical port of an interactive Blender tool into a graph with no mouse in it. Practically, unless you specifically need to drive the cube from a matrix elsewhere in your graph, you're almost always better off reaching for the plain Mesh Primitive Cube Add node instead - same cube, an actual size field, one less thing to think about.

Inputs and outputs

Optional across the board, so it runs with zero configuration:

• location, rotation, scale - the standard XYZ placement vectors.
• matrix - a full 4×4 transform (16 values) if you want to place and size the cube in one shot instead of separate location/rotation/scale fields. This is the gizmo-specific field the plain cube node doesn't have.

Plus the usual boilerplate every primitive-add node carries: calc_uvs (basic UV generation, leave it on), enter_editmode, align (WORLD/VIEW/CURSOR), and a seed field that isn't a real Blender parameter for this operator at all - most likely there to give ComfyUI something to force a re-run with, not to affect the geometry. Output is a single BPY_OBJ, the live handle to the new cube for the rest of your mesh-editing chain.

Installing it

Through ComfyUI Manager, search "avatar-graph-comfyui" and install, or clone it manually: cd ComfyUI/custom_nodes && git clone https://github.com/avatechai/avatar-graph-comfyui, then inside that folder python -m pip install -r requirements.txt, then restart.

The requirement that actually matters is Python 3.10.x - the bpy package this pack is built on is pinned to it, and the README leans on conda to get there cleanly (conda create --name comfyui python=3.10) rather than hoping your system Python lines up. Windows users get a shortcut: a prebuilt ComfyUI + Python 3.10 environment linked right in the README, which you unzip over your ComfyUI folder before installing the pack itself through Manager. When you restart, add --enable-cors-header (and --force-fp16 on macOS) - that's what lets this pack's live 3D viewer talk to ComfyUI. Skip it and the graph still executes; you just lose the live preview and have to save the model out manually from the pack's Avatar Main Output node.

Common issues

The main way this pack fails to load at all is a Python version mismatch - anything other than 3.10.x and bpy won't have a compatible build available, so double-check that before digging further into any error. Because this pack embeds a genuine chunk of Blender's Python API, it's a heavier dependency than most custom nodes, and it can collide with other packs' pinned requirements - a routine hazard in a system where every custom node brings its own install script. If you're specifically trying to use the matrix input and getting geometry in the wrong place or scaled oddly, that's very likely a matrix math mismatch rather than a bug in the node - this field expects a proper 4×4 transform, and it's easy to feed it something malformed if you're building it by hand elsewhere in the graph. And as with everything in this pack, the README carries its own warning that nodes and templates are actively in flux, so treat a shifted default or renamed field in a future version as the project moving, not a regression.