Nova3D: Text-to-3D That Emits Blender Python Instead of a Fused Mesh
Editable, part-aware 3D generation from text or reference images. Open-source client for nova3d.xyz.
At a glance
- What is it?
- RareSense/Nova3D is an MIT-licensed Dart client and Blender add-on for a hosted service that generates 3D assets as executable construction programs. The part structure is the selling point, and the closed backend is the catch.
- Who is it for?
- Adopt Nova3D if your downstream work depends on selecting, retexturing, rigging or animating individual components, and you accept that generation runs on a hosted backend that the README describes as closed-source. Do not adopt it if you need an offline pipeline, a self-hostable model, or a permissive story about the generator itself: the MIT licence covers the app/ and blender-plugin/ directories, not the service they call.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 35 days ago.
- What is it written in?
- Mainly Dart, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Nova3D targets: meshes you cannot take apart
A diffusion generator returns one merged mesh. The README puts it plainly for the competing tools it names (Meshy, Tripo, Rodin): they extract a single merged mesh with no part boundaries. If you want the oven door to open, the escalator step to move, or one panel of a machine to get a different material, you are back to manual segmentation in Blender, and segmentation of an isosurface mesh is approximate by nature. Nova3D's answer is to never build the fused mesh at all. Its output is described as an executable construction procedure: Blender-native Python that compiles to a GLB whose components are named, separately addressable, and grouped into sub-assemblies with joint pivots. The audience is therefore narrower than "anyone who wants 3D from text". It is people whose asset has to stay editable after generation: game and VFX pipelines that need to rig or retexture parts, CAD-adjacent work where dimensions are stated in the prompt, and anyone who wants the source program to remain the source of truth rather than a baked artifact.
What the pipeline actually emits
The README's anatomy example is the clearest statement of the mechanism. A prompt asking for a gold engagement ring with an oval centre stone measuring 6.82 x 8.75 x 4.40 mm, a 17.00 mm inner diameter (US size 6.5), a 6.22 mm crown height and stated overall dimensions produces an asset where, per the README, every visually distinct component is its own named, editable mesh, grouped into named sub-assemblies, and the prompt-stated counts and dimensions hold up when measured back from the result. The assembly claim goes further: a robot arm is described as exporting as a depth-7 kinematic chain, where rotating any pivot moves its whole subtree. That is a scene-graph structure, not a mesh with vertex groups. The README also draws a line between Nova3D and post-hoc segmentation tools, noting that PartCrafter returns unnamed chunks and that CubePart must be handed part names before slicing a finished mesh into capped, approximate regions. Whether those characterisations of the other tools are fair is not something this repository demonstrates; treat them as the project's own positioning.
Repository layout and what is actually open
This is the part most readers skim and should not. The repository is a monorepo of clients and integrations, and the README states that the hosted generation backend is (currently) closed-source. The directories listed are app/ (the Flutter/Dart web client), mcp/ (an MCP server), blender-plugin/ (the Blender add-on), plus claude-skills/, docs/ and examples/, all three marked coming soon. The README adds that surfaces are being moved in one at a time, and that today only the client app and the Blender add-on live in app/ and blender-plugin/. So the MIT licence applies to the client code you can read, not to the model that produces the geometry. If your adoption decision depends on auditing or self-hosting the generator, this repository does not give you that, and no amount of reading app/ will change it. What you can audit is the client: how it authenticates, what it sends, and how it hands the result to Blender.
Getting it running: the client and the add-on
The README does not inline the setup steps. It points at 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. That is the whole installation story in the root document, and it is deliberately thin. Two consequences follow. First, the prerequisites that matter (Flutter SDK version, platform targets, how the client is pointed at the hosted service) live in a file this review does not have, so verify them there rather than assuming a bare flutter run will work. Second, the Blender side has its own README in blender-plugin/, and the release tags give you the version to install: blender-plugin-v1.3.1 is the most recent, published 2026-08-12, with v1.2.0 earlier the same day and v1.1.0 on 2026-08-07. Three add-on releases in five days is a fast cadence for a plugin, which is worth knowing before you pin a version in a shared pipeline. The mcp/ directory implies an MCP server surface for agent-driven workflows, but the root README gives no configuration keys for it, so do not plan around it from this document alone.
The trade-offs the README does not resolve
Three things stand out. The first is the closed backend, already noted: you are renting the generator. The second is the comparison material. The README leans on side-by-side videos against TRELLIS, Hunyuan3D, PartPacker, Tripo, Meshy and TripoSG, and asserts that explicit part structure is an added capability, not a quality tradeoff. That is a claim about fidelity made by the project about itself, illustrated with hosted images and YouTube links. It is not a measurement you can reproduce from this repository, and the README offers no methodology for the comparisons. The third is documentation coverage. The root document says the architecture write-up and the examples gallery (generated assets plus their source programs) are both coming soon. Those are exactly the two artifacts a prospective adopter needs: the thesis document to judge the design, and the example programs to see what the emitted Blender Python actually looks like. Until they land, you are evaluating the idea and the client, not the generator's output.
Where Nova3D sits against a CSG or parametric toolchain
The README positions Nova3D against two families. Diffusion generators give fidelity but no part boundaries. CSG and OpenSCAD-style systems guarantee solids but, in the README's words, cap out on organic shapes, hierarchy, and materials. Nova3D claims Blender's scene graph as its native representation and calls it a strict superset of both. The practical difference from OpenSCAD is the interesting one: OpenSCAD is deterministic and local, so a script you wrote today rebuilds the same solid tomorrow with no network and no model. Nova3D is generative, so the same prompt is not guaranteed to yield the same program, and generation happens on a remote service. You get organic shapes and materials that a CSG script would force you to model by hand; you give up reproducibility and offline operation. For a bracket, a jig, or anything where the dimensions are the deliverable, a parametric script is still the better tool. Nova3D earns its place when the shape is organic or decorative and you still need the parts addressable afterward.
Maintenance, releases and licence boundaries
The repository is active, not archived, with a last push of 2026-08-12, and the release history is concentrated on the Blender add-on rather than the client. That tells you where current effort is going, and it also means the add-on is the component most likely to shift under you between minor versions. Budget for re-testing the add-on against your Blender version on each release rather than assuming backward compatibility across v1.1.0, v1.2.0 and v1.3.1. On licensing: the repository is MIT, which is permissive for the code it covers, and the README states the hosted backend is closed-source. That split is the thing to check against your own constraints, because MIT on the client does not grant you rights to the service, its output terms, or the model. This is a factual boundary, not legal advice; read the service's own terms before you build a commercial pipeline on generated GLB files.
Editorial conclusion
Adopt Nova3D if your downstream work depends on selecting, retexturing, rigging or animating individual components, and you accept that generation runs on a hosted backend that the README describes as closed-source. Do not adopt it if you need an offline pipeline, a self-hostable model, or a permissive story about the generator itself: the MIT licence covers the app/ and blender-plugin/ directories, not the service they call. Before committing, verify three things: the prerequisites listed in app/README.md against your Flutter toolchain, the exact add-on version you install against the blender-plugin-v1.3.1 tag, and whether the hosted API's terms match how you intend to use exported GLB assets commercially.
Community notes