Nodes/ComfyUI-Pixal3D/Pixal3D: Load Pipeline
ComfyUI Node

Pixal3D: Load Pipeline

Pre-warm Pixal3D's 14 GB pipeline so the wait shows up in its own node

By dreamrec·Created 4 months ago·Updated 4 months ago· 22
Pixal3D: Load Pipeline
    • pipeline_ready
    low_vramfalse

    First, the honest answer: you almost certainly don't need this node. The Pixal3D: Image to Mesh node loads the pipeline on demand when you queue it, and that's the path 99% of people should use. Pixal3D: Load Pipeline exists for the other cases - when you want the load to happen explicitly, in its own node, on your schedule, instead of silently eating three minutes of the first queue.

    What it does

    It force-loads everything Pixal3D needs into VRAM before you run anything: the Pixal3D pipeline itself (the 4× DINOv3 extractors plus the structure/shape/texture sampling flows and decoders) and MoGe-2, the depth estimator that figures out camera intrinsics. That's roughly 14 GB resident once loaded, so "pre-warming" isn't free - it's parking the weight set in memory so the first actual generation is fast instead of a cold start.

    The source also logs per-stage timings as it loads - pipeline load time, then MoGe load time. If you're ever staring at an unresponsive queue wondering "is it stuck or is it loading?", that log line is your answer.

    The one input, the one output

    The entire node is one boolean and one socket:

    • low_vram - default false. The tooltip is the whole story: offload submodels to CPU between stages, recommended for cards under 24 GB. Flip it on for a 16 GB card and you trade wall-clock time for the ability to finish at all.
    • pipeline_ready (PIXAL3D_PIPELINE_READY) - the output. Wire it into the pipeline_ready socket on Pixal3D: Image to Mesh.

    Here's the subtle bit that confuses people: when pipeline_ready is connected, the Image to Mesh node honors the low_vram setting from this node and ignores its own low_vram widget. So set it once here, not twice, and if you change your mind later remember which node actually owns the setting.

    When it's actually worth it

    Three scenarios make sense: you're running a sweep of many seeds and want the load cost paid once up front and out of the way; you want the load's timing visible as its own step for debugging rather than hidden inside the first generation; or you're chaining Pixal3D into a bigger workflow and want the warm-up to happen at a moment you control. Otherwise - drop a Load Image into Image to Mesh and queue. Simpler.

    Installing

    Same story as the whole pack, since it ships with it. ComfyUI Manager: search ComfyUI-Pixal3D, install, restart. Manual:

    cd $HOME\Documents\ComfyUI\custom_nodes
    git clone https://github.com/dreamrec/ComfyUI-Pixal3D.git
    cd ComfyUI-Pixal3D
    & "$HOME\Documents\ComfyUI\.venv\Scripts\python.exe" install.py
    

    The hard requirements are the pack's, not this node's: Windows 10/11 x64, Python 3.12 + PyTorch 2.8 + CUDA 12.8 (ComfyUI Desktop defaults), an NVIDIA RTX 30/40/50 card, ~50 GB of disk for the one-time ~26 GB model download, and no AMD/Intel GPUs. Pixal3D the model is academic / non-commercial and not licensed for EU use, even though the wrapper itself is MIT.

    One trap if you do use it: this node is a warm-up helper, not a keeper. If you pre-load the pipeline and then stop using Pixal3D for a while, that ~14 GB sits in VRAM doing nothing. That's what the pack's third node, Pixal3D: Free Pipeline, is for.

    CategoryPixal3D

    Inputs (1)

    NameTypeDefaultDescription
    low_vramBOOLEANfalseOffload submodels to CPU between stages. Recommended for <24GB cards.

    Outputs (1)

    NameTypeDescription
    pipeline_readyPIXAL3D_PIPELINE_READY