Mesh Primitive Grid Add

A plane with one segment on each side is fine if you just need a flat rectangle. It's useless the moment you want that rectangle to deform - bend, wave, drape, displace. That's what the grid is for: it's a plane cut up into a subdivided X/Y mesh, and this node is Blender's real grid-primitive operator (bpy.ops.mesh.primitive_grid_add) showing up as a ComfyUI node. It's part of Avatar Graph, the pack that builds interactive 2D-to-3D avatars by running actual Blender via bpy inside ComfyUI's process - every mesh operator Blender has gets auto-generated into a node here, and this one just happens to be about grids rather than anything avatar-specific.

How it works

Same mechanism as any of this pack's primitive-add nodes: it creates a new mesh object and drops it into the scene. The difference from a plain plane is the subdivision - instead of four corner vertices, you get a grid of them, which gives any later deformation (a Screw operation, proportional editing, a shape key driven by Shape Flow) somewhere to actually bend. It's the classic starting mesh for cloth, terrain, or a displaced surface built from a height map.

Inputs and outputs

The two fields that decide what you actually get:

• x_subdivisions and y_subdivisions (both default 10) - how many cuts along each axis. Higher numbers give smoother deformation later at the cost of more geometry to push around.
• size (default 2) - the overall edge length of the grid before subdivision.

Beyond that it's the standard primitive-add boilerplate: location/rotation/scale vectors for placement, calc_uvs (leave on, gives the grid a basic UV layout), enter_editmode, an align enum (WORLD/VIEW/CURSOR), and a seed field that - worth flagging, since it shows up on every primitive node in this pack - isn't part of Blender's actual grid operator at all. It's most likely there so ComfyUI has something to key a re-run off, not because it changes the geometry. Output is a single BPY_OBJ, a live handle into the running Blender scene, ready to hand off to whatever mesh operation comes next.

Installing it

ComfyUI Manager: search "avatar-graph-comfyui", install, restart. Manual route: cd ComfyUI/custom_nodes && git clone https://github.com/avatechai/avatar-graph-comfyui, then cd avatar-graph-comfyui && python -m pip install -r requirements.txt, restart ComfyUI.

The requirement to get right before anything else: Python 3.10.x. The bpy package underpinning this whole pack is built for that exact minor version, and the README pushes you toward a dedicated conda environment (conda create --name comfyui python=3.10) on macOS/Linux instead of trusting your system Python. Windows gets a shortcut - a prebuilt ComfyUI + Python 3.10 zip linked in the README you unzip straight over your ComfyUI install, then add the pack via Manager. Restart with --enable-cors-header (macOS also needs --force-fp16); that flag is what lets ComfyUI hand off to Avatech's web viewer for a live 3D preview. Without it, the graph runs the same, you just save the mesh out manually from the pack's Avatar Main Output node afterward instead of watching it live.

Common issues

The Python version mismatch is the failure you'll hit first and most often - anything other than 3.10.x and bpy has no working wheel to install, and the whole pack fails to load rather than just this node. If everything loads but the grid looks wrong, it's almost always the subdivision counts, not a bug: a 10×10 grid at size=2 is a fine, dense little mesh, but crank subdivisions way up without a reason and you'll just be pushing a heavier mesh through every downstream operation for no visual benefit. This pack also brings a genuinely heavy dependency footprint compared to most custom nodes, since it's embedding real Blender machinery, so if you're seeing conflicts with other packs' pinned Python dependencies, that's a known hazard of the wider ComfyUI custom-node ecosystem rather than something specific to this grid node. And the pack's own README opens with a warning that nodes and templates are still actively changing, so treat a shifted default in a future release as expected drift, not breakage.