🧊 MuAPI Image/Text to 3D

Here's a small oddity worth knowing before you go hunting: the pack's README table lists twelve nodes and 🧊 MuAPI Image/Text to 3D is not one of them. It registers anyway, so it shows up in your node menu under 🧊 MuAPI. If you went looking for docs and found nothing, that's why.

What it does: sends a prompt, one to three images, or both to a hosted 3D generator and hands back a URL to a mesh. Nine endpoints - meshy-6-text-to-3d, meshy-6-image-to-3d, meshy-6-multi-image-to-3d, tripo3d-p1-text-to-3d and -image-to-3d, tripo3d-h31-text-to-3d, -image-to-3d and -multiview-to-3d, plus custom. Tripo is the same lab behind TripoSR, the MIT feed-forward model that used to be the only image-to-3D anyone could actually run (triposr.json); here you're using their commercial service instead.

Set expectations first

The KB's 3d-generation.md opens on the single most useful fact in this area, from the top comment on a 2026 release thread: "what people not in 3d mean by 'high-quality 3d asset' is very, very different from what people in 3d mean by that. These are extremely low-quality 3d assets." The silhouette is impressive; the geometry underneath is triangle soup with machine-generated UVs and no rig. So: great for a static prop, a background filler, a game-jam asset, or a 3D print. Useless as-is for anything that has to deform.

That last one is the good news, though - for printing, nobody cares about topology. Remesh, slice, done.

The inputs

model and prompt are the required pair. prompt is required by the schema but can be left empty, which is what you do for the image endpoints - the node only attaches it to the payload if it has content. Text-to-3D is the mode where you actually type.

Optional: image_1, image_2, image_3 (IMAGE), plus api_key, custom_endpoint and extra_params_json.

The routing rule is short and worth internalising: if the endpoint name contains multi or multiview, all connected images go into an images_list array; otherwise only image_1 is sent, as image_url. On the single-image endpoints, extra connected images are uploaded to the API and then quietly discarded - real behavior, wasted bandwidth. Connect exactly what the endpoint can use.

Note the KB's point that "text to 3D" is a workflow label rather than a model class: most single-prompt-to-3D pipelines are text-to-image then image-to-3D. Meshy and Tripo both sell a native text path, so you don't have to chain it here - but you'll usually get a better asset by generating a clean, well-lit, single-subject image locally first and using *-image-to-3d.

Outputs, and the missing one

model_url (STRING) and request_id.

There's no mesh output - no MESH, no socket you can wire into a 3D node. That's a limitation of the whole API-node pattern: the asset is a file on their CDN, and getting it into your graph is a download. Do that and use ComfyUI's native 3D nodes, which the KB's 3D doc calls the light tier: Load3D accepts .glb/.obj/.fbx/.stl and gives you an orbitable viewport right on the canvas, Preview3D renders it with materials and exports, SaveGLB writes it out. Drop the downloaded file in ComfyUI/input/ and load it by name.

Install

Manager → Install via Git URL → https://github.com/SamurAIGPT/muapi-comfyui → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/SamurAIGPT/muapi-comfyui
pip install -r muapi-comfyui/requirements.txt

Nothing to download. Worth saying out loud, because the local image-to-3D story is the opposite: ComfyUI-3D-Pack builds a pile of CUDA extensions and is famously painful to install. Nine hosted endpoints and an empty models/ folder is a much gentler introduction - you just pay per asset.

Troubleshooting

If you get a URL but the mesh looks melted, that's the model, not the node; try the multiview endpoint with three clean views (front, side, three-quarter) rather than one. If the call fails with an empty image payload, check that image_1 is actually connected - the text endpoints reject a missing prompt the same way, and both come back as endpoint errors rather than node errors. And a custom_endpoint typo produces exactly the same error shape as a valid endpoint with a bad payload, so verify the endpoint string against muapi's docs first.