Pixal3D MoGe-2 Loader ⚡

Pixal3D doesn't just want to know what's in the photo. It wants to know where the camera was. That's the one architectural difference that makes its preprocessing chain longer than TRELLIS.2's, and it's why this node exists: it loads MoGe-2 as a MOGE_MODEL so core's MoGe Inference can estimate a field of view for the conditioning stage.

The idea

MoGe (Microsoft Research and Tsinghua's Monocular Geometry Estimator) doesn't emit a depth map. It predicts an affine-invariant point map - a per-pixel 3D coordinate - plus a validity mask that excludes the sky and other regions where geometry is undefined. From that point map you can derive depth, focal length, camera intrinsics, even a mesh. That last property is why MoGe kept showing up in ComfyUI long before any of this: it's the model people reach for when they need geometry rather than a grayscale gradient.

Pixal3D uses it for the narrow slice it needs: a plausible camera FOV for the input photograph, which conditions how the model interprets perspective during reconstruction. Core ships the inference nodes; this loader only supplies the weights.

Inputs, output, and the chain

One required input, moge, pointing at moge-2-vitl/model.pt from Ruicheng/moge-2-vitl - the checkpoint the owner's extras/ folder carries. One output, moge_model (MOGE_MODEL), which only connects to MoGe Inference.

The chain is MoGe Inference → MoGe Geometry To FOV → the FOV feeding core's Pixal3D Conditioning. Note there's no strength, no resolution, no precision switch on this node - it's a loader in the strictest sense. Any tuning happens in core's nodes.

This is a Pixal3D-only step. TRELLIS.2 doesn't call MoGe at all, so if you're running the plain TRELLIS.2 graph you can leave this node out entirely and never think about it again.

Files and folders

The dropdown lists .pt, .pth and .safetensors files with "moge" in the name across models/trellis2/ and models/pixal3d/. The README's layout puts it at models/pixal3d/extras/moge-2-vitl/.

The loader is deliberately thin: it reads the state dict and constructs comfy.ldm.moge.model.MoGeModel from it directly. There's no "is this really MoGe?" validation, unlike the DINOv3 and BiRefNet loaders next door, which both refuse to return something ComfyUI doesn't recognise. So a wrong file here fails at inference, in the middle of the chain, with a shape or attribute error rather than a polite message at load time. Read the filename twice if you've been collecting 3D checkpoints all afternoon.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/ChrisColeTech/ComfyUI-GGUF-Loader
pip install --upgrade gguf

ComfyUI Manager, search "ComfyUI-GGUF-Loader", restart. Nothing in requirements.txt is MoGe-specific - this node needs no torch-hub download and no extra package, because core already carries the model code.

Where people get burned

Assuming MoGe is the background remover. It isn't - that's BiRefNet in the node next door. MoGe gives you geometry and camera; BiRefNet gives you a matte. Pixal3D's pipeline wants both, in that order: prepare the image, then estimate geometry, then condition. If you wire MoGe at a raw photo full of background clutter, it will happily estimate geometry for the clutter too, and the FOV estimate will drift toward whatever dominates the frame.

Expecting this to improve TRELLIS.2. It won't, because TRELLIS.2 never asks for it. Two Nodes doing similar-looking things in the same category is a common source of "why is this here at all" confusion - the answer is that 🤖 CCTech/TRELLIS.2 hosts both pipelines' loaders, and exactly one of them is a camera estimator.

Empty dropdown. Same story as the rest of the family: the name filter wants "moge" in the filename, and the folder must be under models/trellis2 or models/pixal3d. .pt files get scanned, but they're not versioned by extension the way safetensors are, so you can't tell by looking whether you have MoGe-2 or the older MoGe v1 - check the model card you downloaded from.

If you want the general background on what MoGe is good at outside this pipeline - mesh from a single image, in particular - the pack's neighbours do more with it than Pixal3D does. Here it's one input to a conditioning step, and that's the whole job.