Skip to content

3.44.0

Choose a tag to compare

View all tags
@fernandotonon fernandotonon released this 29 Sep 06:01
3.44.0
66256b7

Roblox game-ready presets for image-to-3D

Two platform presets on the game-ready pass, for every image-to-3D backend (TRELLIS.2, Pixal3D, TripoSR, TripoSG), so generated assets come out under Roblox's upload limits:

preset triangles textures
roblox-accessory ≤ 4,000 (hard ceiling) capped at 1024 px
roblox-meshpart ≤ 20,000 (hard ceiling) capped at 1024 px
  • Ceilings, not budgets. The existing tiers accept landing a little over target when the simplifier stalls; Roblox rejects an upload past its limit, so these presets keep reducing until the count fits, and the lost relief comes back through the detail-normal bake. If the ceiling genuinely cannot be met, the generation fails with a clear error instead of exporting an over-limit asset under a preset that promised otherwise.
  • The texture cap is enforced on the final images, not just the bake request (xatlas treats the request as a hint), and the optional 2× upscale is skipped when it would cross the cap.
  • One preset table feeds the Inspector "Mesh" picker, the CLI and MCP, so the three cannot drift.

Using it

  • GUI: Object mode → AI: Image → 3D → Mesh picker. A Roblox preset snaps the Texture picker to 1024 px and shows the platform limits.
  • CLI: qtmesh generate3d photo.png -o hat.glb --game-preset roblox-accessory · qtmesh generate3d --list-game-presets
  • MCP: generate_mesh_from_image { "game_preset": "roblox-meshpart" } (the schema lists the ids; the response carries gamePreset, targetTriangles, strictTriangleBudget, textureSize)

Custom values on CLI/MCP. A preset is a base: --target-tris (0 = original density, else any 1..10,000,000) and --texture-size (any 64..8192) work alone or alongside --game-preset to override that preset's number. A value past a Roblox limit is honoured and warned about, never clamped. Same on MCP with target_tris / texture_size next to game_preset.

Also in this release

  • Text-to-motion no longer serves a zombie shamble for a plain "walk". The motion corpus mixes human and undead performances under the same action names and take selection is random, so an unqualified walk had a ~46 % chance of a shamble (and attack was 75 % undead). Clips now carry a human / undead / creature category; an unqualified prompt gets human takes, while "zombie walk" or "dragon flying" route to the matching category. Libraries already on disk are classified from provenance, so the fix applies without a re-download.

Full changelog: 3.43.0...3.44.0

Assets 15
Loading