3DGenStudio turns a text prompt into a textured mesh without leaving one workspace

A production layer over ComfyUI rather than a generator

The scope of 3DGenStudio is broader than any one model. Its description is orchestration of complete 3D generation pipelines, from text to image, image editing, mesh generation and UV unwrapping through to texturing, all in a single visual workspace powered by ComfyUI and external APIs. That word orchestration is the accurate one. The project does not ship its own diffusion model. What it ships is the layer that connects the stages, keeps the intermediate results, and gives you somewhere to look while a job runs. The dependency on ComfyUI is explicit and structural: the repository carries a comfyui_workflows/ directory with the workflow definitions, and the changelog records constant updates to ComfyUI nodes and workflows for models such as Trellis2, Pixal3D and Hunyuan. The SetupWizard handles the ComfyUI installation and the model downloads, and the changelog shows it gaining entries for specific image models over time, including Qwen Image 2.1, MOSS Image, Flux3 Klein and UltraTex. For a user this means the tool is only as good as the ComfyUI stack behind it, and the tool also improves as those workflows are revised.

Three project types for three different ways of thinking

The workspace is not a single canvas. It offers three project types, and the differences between them are the clearest sign of how the author expects work to be organised. The Graph project is a node graph, where each stage is a node and the changelog records a new node type for Rig Mesh, nodes that keep their last parameters, a Reorganize button, and the ability to paste an image directly into the project. The Kanban project is a board, with columns for stages such as Rigging, where the current displayed image or mesh can be fed into the ComfyUI workflow of that column. The Batch project type was added later, in August 2026, and it extends the Kanban idea into automation: stage actions such as AutoUV, Auto Retopo, Transfer Rig and Flatten to Albedo, execution moved to the backend, and the ability to run a batch by stage. It also supports image, mesh and boolean types and deleting a result. The Graph form suits experimenting with one asset, Kanban suits moving many assets through a fixed pipeline, and Batch suits running that pipeline unattended. Which one you pick changes how the rest of the tool behaves.

The MeshEditor carries the stages that are not generation

Once a mesh exists, most of the real work happens in the MeshEditor, and the changelog shows it growing a set of distinct modes rather than one editor with a long toolbar. AutoUV handles unwrapping, and the entries show it being improved with more options and getting a fix for normals. AutoRig does rigging, and it has accumulated weight painting, bone editing with add and delete, improved motion capture, custom animation save and import, and a transfer rig feature that moves a skeleton and weights from a high poly mesh to a low poly one. Projection places the texture, with a fix for blend overlap seams against the original texture. Segmentation splits a mesh into parts, and the entries note that exported parts can keep the mesh texture. Bake and Game-Ready are the shipping modes, Game-Ready being about export rather than editing. There is also an Auto Retopo path with a Clean Non-Manifold Edges option and a fix for open edges. The practical consequence is that the mesh work is a set of separate pipelines with their own state, so a stage can be re-run on an existing asset instead of regenerating the whole chain.

Third party APIs sit alongside the local models

ComfyUI is not the only engine. The changelog records integrations with external services, and each one arrives with its own model catalogue. Hitem3D appears with an API v1 addition and later a v3.0 model. TripoAI gained an 8K texture quality option described as extreme. There is a QwenVL component for image understanding, Kimodo for animation work, and MoCapAnythingV2 for video to motion. The Graph page gained labels for external APIs so you can tell at a glance which node calls out to the network, which is a small but telling detail about a tool that mixes local and remote compute. The cost model follows from this. Local ComfyUI work consumes the GPU on your own machine and downloads models into your SetupWizard cache, while API nodes bill an account elsewhere. If you build a Batch project around external APIs, you are automating spending, and the batch stages are the place where that needs a budget before it needs a workflow.

A desktop app that can hand the shared work to a server

The deployment story has two halves and they are deliberately separated. The desktop app is an Electron application, with electron/ and electron-builder.yml at the top of the repository, and it is where ComfyUI and the mesh, rig and motion tools live on your own machine. The shared server holds assets, projects and user accounts. The Dockerfile makes the split explicit: the shared image runs the server in server mode and has no GPU, no ComfyUI, no Python sidecars and no third party API keys, because every user keeps those locally. Recent changelog entries extend that split in both directions: the multi-user server can be hosted on another machine, and the desktop app can use services from a remote computer. A Dockerfile file and a deploy_docker.bat are kept for the Windows path, and run.sh, run.bat and run_server.bat cover the local starts. If you work alone, the desktop app with its local SQLite database is enough. If a team needs shared assets and concurrent requests, the server mode is the part you deploy, and the database choice follows from that.

PostgreSQL for teams, SQLite for one person, and a migration in between

The compose file explains the database decision in comments rather than leaving you to guess. The service definition starts with PostgreSQL rather than SQLite because a team's requests have to run in parallel, while SQLite remains the engine for a single user desktop install, and the application code is identical on both. The db service runs the postgres:17-alpine image with a named volume, and the password variable is marked required with a comment explaining that a default password would still be a default password even though the database is not published outside the compose network. The visible service definition looks like this:

services:
  db:
    image: postgres:17-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${GENSTUDIO_DB_NAME:-genstudio}
      POSTGRES_USER: ${GENSTUDIO_DB_USER:-genstudio}
      POSTGRES_PASSWORD: ${GENSTUDIO_DB_PASSWORD:?set GENSTUDIO_DB_PASSWORD in .env}

Migrating an existing SQLite deployment is a documented step rather than a silent data loss, because the server refuses to start on an empty PostgreSQL database. The compose comment gives the exact sequence: start the db service, run the migration container with the from and to arguments against tools/migrate-sqlite-to-postgres.mjs and the GENSTUDIO_DATABASE_URL value, then bring the stack up. The npm scripts include the same migration as db:migrate. The changelog also records that the database was restructured and simplified in July 2026, and that projects can now be exported and imported, which is a sensible escape hatch when the schema moves under you.

Building from source and the licensing question

The package manifest names the app simply as app with version 3.5.4, and the scripts show how the pieces run. Development starts the server and the Vite client together, and the built application is served by the same server process:

  "scripts": {
    "dev": "concurrently \"npm run dev:server\" \"npm run dev:client\"",
    "dev:server": "node server.js",
    "dev:client": "vite",
    "build": "vite build",
    "start": "node server.js",
    "lint": "eslint .",
    "mcp:stdio": "node mcp/stdio.js",
    "electron:dev": "npm run build && electron .",
    "db:migrate": "node tools/migrate-sqlite-to-postgres.mjs",

The dist targets are per platform, win, mac and linux, and each one runs a set of check scripts first, including check:packaging, check:db, check:vfx and check:building, before vite build and electron-builder. The Dockerfile takes the same approach with a builder stage on node:24-bookworm and a runtime stage on the slim variant. It contains a detail worth knowing if you build your own image: sqlite3 is the only native dependency, its published prebuilt binary needs a newer glibc than the runtime stage ships, so the build sets npm_config_build_from_source and installs python3, make and g++ to compile it against the same Debian release.

The licence is where to be careful. GitHub reports the licence as something it cannot classify, which means the LICENSE file holds custom terms rather than a standard identifier, and the repository also carries a separate META-LLAMA-3-LICENSE file. The source code is open to read and the project accepts pull requests, but if your organisation needs to know precisely what you may do with the code and the bundled models, read the LICENSE file rather than assuming an MIT or Apache grant. The project itself is very much alive: the last push was on 2026-10-20, the release v3.5.4 shipped on 2026-10-18, and the changelog shows releases v3.5.2 and v3.5.3 in the weeks before that.

Editorial conclusion

Adopt 3DGenStudio when you need a repeatable chain from prompt to textured and rigged mesh and want to see each stage as a node, a kanban card or a batch job, especially if you already run ComfyUI locally. Do not choose it if you need a single text to mesh call, if you cannot supply a GPU machine for the Python sidecars, or if a custom licence that GitHub cannot classify is a problem for your organisation. Before starting, run the SetupWizard on the machine with your GPU, confirm that the model it wants to download is one you are allowed to fetch, and check the LICENSE file yourself, since the terms are not covered by a standard licence identifier.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. visualbruno/3DGenStudio on GitHub