Nova3D: 3D Assets as Executable Programs, Not Fused Meshes

The problem Nova3D targets: meshes you cannot take apart

Most text-to-3D tools hand you a single merged mesh. You can render it, you can 3D print it, and that is roughly where the story ends. If the model has a hinge, a lid, or a wheel, the geometry is fused into one surface with no boundary between the moving piece and the body. Selecting the door means selecting triangles by hand, and retexturing one component means retexturing all of them.

The README frames Nova3D against two families. Diffusion-based generators such as Meshy, Tripo and Rodin are described as extracting "a single merged mesh with no part boundaries". CSG and OpenSCAD systems are described as guaranteeing solids but capping out on organic shapes, hierarchy and materials. Nova3D's claim is that Blender's scene graph is a strict superset of both: you get solids and you get named parts.

The audience is narrow but real. Technical artists who need to rig or retexture individual components. Game and VFX pipelines that consume GLB and expect an assembly hierarchy rather than a blob. Engineers generating mechanical or CAD-adjacent objects where a stated dimension has to survive into the output. The repository's own example is an engagement ring prompted with an oval center stone of 6.82 x 8.75 x 4.40 mm, a 17.00 mm inner diameter, and named pavé diamonds along the band.

How the code-native pipeline works: Python in, structured GLB out

Nova3D does not diffuse a mesh. According to the README, the pipeline writes Blender-native Python that compiles to a structured GLB. The generated program is the source of truth; the mesh is its compiled output. That single design decision explains most of the project's behaviour.

Because the output is produced by a program, every visually distinct component can be emitted as its own named, watertight part, grouped into named sub-assemblies. Joint pivots are placed at articulation points, and the README describes a robot arm exporting as a depth-7 kinematic chain where rotating any pivot moves its whole subtree. PBR materials attach per part. Because the artifact is code, it is inspectable and editable after the fact in a way a baked mesh is not.

The repository layout reflects this split. The hosted generation backend is closed-source. What is open is the Flutter/Dart web client in app/, an MCP server in mcp/, and a Blender add-on in blender-plugin/. The README also lists claude-skills/, docs/ and examples/ as coming soon, so the "3D as code" thesis document and the gallery of generated assets plus their source programs are not in the repository yet. That is a meaningful gap for anyone who wants to study the emitted Python before committing.

Installing the Nova3D client and running a first generation

The README does not put install steps at the top level. It points to app/README.md for prerequisites, setup, features and troubleshooting, and states that the web client connects to the hosted Nova3D service with no local backend required. So the honest starting point is that file, not this one.

What the top-level README does give is the shape of the workflow. You open the app, authenticate against the hosted service, and submit either a text prompt or a reference image. The repository structure tells you the client is Flutter/Dart and that it lives in app/:

cd app

From there, app/README.md is the file that documents prerequisites, setup, features and troubleshooting. The top-level README does not reproduce the Flutter commands, so take them from that file rather than guessing at flags.

For Blender users the path is different and better documented by release history. The repository publishes tagged Blender add-on releases, most recently blender-plugin-v1.3.1 on 2026-08-12, preceded by blender-plugin-v1.2.0 the same day and blender-plugin-v1.1.0 on 2026-08-07. Installing the add-on means taking that release artifact into Blender, at which point generated assets arrive as editable scene objects rather than an import. The README does not document rollback or downgrade between plugin versions, so if you pin a pipeline to v1.2.0 you are on your own for reverting.

Where Nova3D stops being the right tool

The largest limitation is structural, not technical. The hosted generation backend is closed-source, and the README says so plainly. You cannot run generation on your own hardware, audit the model, or keep working if the service is unavailable. Every part-aware property in this article is a property of a service you call, not of software you own. The MIT licence covers the clients and integrations in this repository, not the generator.

Second, the repository is mid-migration. The README states that surfaces are being moved in one at a time and that today the client app and Blender add-on live in app/ and blender-plugin/. The claude-skills/, docs/ and examples/ directories are marked coming soon. Anyone hoping to read the architecture document or study emitted source programs alongside their assets will not find them here yet.

Third, the approach is the wrong fit for a whole class of work. If you want a dense organic scan, a photogrammetry-style surface, or a single printable solid with no internal structure, the part hierarchy is overhead you will not use. The README's own comparison concedes the diffusion models produce "dense isosurface meshes", which is exactly what some pipelines want. Nova3D is optimized for structured asset generation, and prompting it for an undifferentiated blob is fighting the design.

Finally, the README's comparison imagery is hosted on imgur and YouTube. Nothing in the repository states how those comparisons were produced, so the fidelity claims should be treated as vendor presentation until you reproduce them on your own prompts.

Nova3D against PartCrafter, CubePart and the mesh-native generators

The README draws two distinct comparisons, and they are not the same argument.

The first is against mesh-native generators: Meshy, TRELLIS.2, TripoSG and Hunyuan3D. These produce a merged surface. Nova3D's difference is that it never builds a fused mesh in the first place, so there is no segmentation step to undo. The README claims the advantage is not limited to multipart editing and that explicit part structure is "an added capability, not a quality tradeoff", which is a claim about silhouette control and feature delineation that you would need to check against your own prompts.

The second comparison is more interesting because it is against other part-aware systems. PartCrafter is described as returning a handful of unnamed chunks. CubePart, per the README, must be handed the part names and then slices a finished mesh into capped, approximate regions. That is the real architectural difference: post-hoc segmentation versus generation-time part emission. A sliced region has an approximate boundary and a cap where the cut happened. A part generated as its own watertight object does not. If your downstream work depends on clean instance separation or on editing one component without touching its neighbours, that distinction decides the tool.

OpenSCAD and CSG systems sit on the other side. They give you guaranteed solids and precise parametric control, but the README positions them as weak on organic shapes, hierarchy and materials. Nova3D's bet is that Blender's scene graph covers both ends.

Maintenance, releases and what the MIT licence actually covers

The repository is not archived. Its last push was on 2026-08-12, and the release history is compressed: blender-plugin-v1.1.0 on 2026-08-07, then v1.2.0 and v1.3.1 both on 2026-08-12. Three tagged plugin releases inside six days suggests active iteration on the Blender integration specifically, though the README does not describe what changed between them and the repository does not publish a changelog in the files available here.

Upgrade cost is concentrated in the Blender add-on. If your team pins plugin versions for reproducibility, the absence of documented rollback means you should keep the previous release artifact yourself before upgrading. The Flutter client in app/ carries the normal Dart dependency burden, and app/README.md is where prerequisites and troubleshooting live.

On licensing: the repository is MIT, which is permissive and places few obligations on how you use the client code. That licence does not extend to the hosted service. The README is explicit that the generation backend is currently closed-source, so the terms governing generation, storage of your prompts and assets, and commercial use of outputs come from nova3d.xyz and its app, not from the LICENSE file in this repository. Read those separately. This is a description of what the files say, not legal advice.

Editorial conclusion

Adopt Nova3D if your pipeline needs named parts, an assembly tree with joint pivots, or Blender-native source you can edit after generation, and if you accept a hosted backend you do not control. Do not adopt it if you need an offline, self-contained generator: the README states the generation backend is currently closed-source, so the open repository gives you the Flutter/Dart client in app/, the MCP server in mcp/ and the Blender add-on in blender-plugin/, not the model. Verify first that the hosted service's terms and current availability match your production requirements, and check app/README.md for prerequisites before you commit a pipeline to it.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. RareSense/Nova3D on GitHub
4. README
5. Releases