Normalize to BBox

Somewhere between "I generated a mesh" and "I need to feed it to the next model," almost every 3D workflow hits a convention mismatch. One model wants its input centered at the origin with a bounding box of 1; the generator you used spat out a mesh floating in space at an arbitrary scale. Normalize to BBox is the standardizer: it centers the mesh on the origin and scales it so its largest dimension fits a target box. Dead boring, and it unblocks half the interoperability problems in 3D pipelines.

It's part of ComfyUI-GeometryPack ("ComfyUI libigl") by Andrea Pozzetti, and it's the transform you'll see sitting right after a loader in any workflow that feeds another model.

How it works

The node computes the mesh's bounding box, translates the center to the origin, then uniformly scales so the longest axis matches target_size. The author's tooltip is specific: 1.0 means the [-0.5, 0.5] box, and it calls that "default for TripoSF." TripoSR/TripoSF-style image-to-3D models train on exactly that convention, which is why this node exists - it's the exact preprocessing those pipelines assume.

The trimesh input accepts a mesh or a point cloud (the tooltip says so), so you can normalize a scattered point set before it becomes a mesh. Scaling is uniform, so aspect ratio is preserved - the mesh isn't squashed to the box, it's fitted inside it along its longest axis. The operation works on a copy; your original stays untouched.

Inputs and outputs

• trimesh - mesh or point cloud to normalize.
• target_size - the box size, default 1.0 ([-0.5, 0.5]). Small values shrink big scenes down to workable scales; the range runs 0.001 to 100.

Outputs:

• normalized_mesh - the transformed TRIMESH.
• info - STRING with the original center and extents, the scale factor used, and confirmation of the new bounds. That scale factor is worth reading - it tells you how far off your source was from the convention you just forced it into.

It also stores the original center and scale factor into the mesh's metadata, so a later step could in principle undo the transform. Don't count on a built-in denormalize node existing for every case - but the data's there.

Where it bites

The two failure modes are both about forgetting why you normalized:

• Comparing meshes - if you normalize before a distance check, you're comparing shapes in canonical space, which is often what you want. But if you wanted absolute error in original units, you just threw the units away. Do distance math before normalizing, or don't normalize one side of the comparison.
• Different target sizes - a mesh normalized to 1.0 and another to 2.0 are not in the same frame. Keep target_size consistent across a pipeline.

Install

Same as every node in the pack: search "GeometryPack" in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/PozzettiAndrea/ComfyUI-GeometryPack.git
cd ComfyUI-GeometryPack
pip install -r requirements.txt --upgrade
python install.py

Restart after. The pack uses the experimental comfy-env installer (with pixi and a heavy isolated 3D environment - Blender, CGAL, libigl, VTK), so first launch downloads a lot. GPL-3.0-or-later, fine for commercial work unless you redistribute modified copies. And as with the rest of this fast-moving WIP pack, if behavior shifts after an update, a clean reinstall beats debugging your graph.

It's two transforms (translate + scale) wearing a trench coat, and it's the difference between "the model ate my mesh" and "the model ate my mesh correctly."