Skip to content

3.43.0

Choose a tag to compare

@fernandotonon fernandotonon released this 26 Sep 07:12

Pixal3D image-to-3D backend

Adds Pixal3D (TencentARC, MIT code + MIT weights) as an image-to-3D backend across the UI, CLI and MCP. It is a TRELLIS.2 fork that replaces the global DINOv3 cross-attention with view-aligned projection conditioning, so it runs on the same trellis-cli runtime and reuses TRELLIS.2's decoders byte-for-byte — one models directory serves both, with flow weights under a pixal3d_ prefix.

It is offered as an alternative worth trying on characters, not as a better model.

Using it

  • GUI: pick Pixal3D in the AI: Image → 3D backend list
  • CLI: qtmesh generate3d photo.png -o out.glb --backend pixal3d --resolution 1024
  • MCP: generate_mesh_from_image { "backend": "pixal3d" }

Needs its own ~11 GB flow set — AI Model Settings → "Pixal3D" (the TRELLIS.2 decoders are shared, so install those too).

Two constraints worth knowing

  • Pixal3D ships no res-512 texture flow, so --resolution 512 writes geometry only. Use 1024 for textures; the app now says so explicitly when it falls back.
  • --pixal-fov defaults to Pixal3D's own training value (49.13). Guessing mis-places the projection camera the whole backend depends on.

Also in this release

  • Orientation fix — Pixal3D output was reusing TRELLIS.2's placement and came out lying on its back. It now gets the extra −90°X rotation it needs; TRELLIS.2 is unchanged.
  • Concurrent generations are refused. A run holds several GB for minutes, and two at once drives a shared-memory machine into swap. The second request is now refused with an actionable message instead of queueing invisibly behind a multi-minute run.
  • Clearer texture guidance over MCP. target_tris defaults to 0 (native density) while the GUI defaults to 25 000; at native density the UV atlas fragments into thousands of charts and the bake shows black seam lines. MCP now warns, and the schema carries the measured numbers.
  • Readable trellis-cli errors. Failures were truncated from the wrong end, so the reason was discarded and users saw usage boilerplate. The actual message now comes through.
  • Viewport no longer spins the CPU/GPU when idle. The render loop ran uncapped with no vsync — roughly 38 % CPU on an empty scene. Capped at ~60 fps, that drops to under 10 %.

Full changelog: 3.42.1...3.43.0