Stop porting your own work between three tools.
Model it, generate the textures, wire the interaction and ship the page — in one environment. No export, re-import, hand-port to the web, then all of it again when the brief changes.
One graph, from the geometry to the page.
One environment instead of a fractured stack
3D, generative work, interaction and the document itself are all operators in the same graph. The geometry, the texture pass, the material, the camera behaviour, the state logic and the HTML sit next to each other — so there's no seam to carry work across, and no second build of the same idea just to get it onto the web.
Generation is a node, not a separate app
The model output is wired directly to the thing it feeds — a texture on your actual geometry, a background behind your actual layout. You're not downloading a PNG from a browser tab and re-importing it, and you're not rebuilding the connection every time you try another direction.
A real procedural graph, with strict typed wires
Ten operator families, a per-frame cook, and connections that only accept what they can actually take. Build once and generate many, deterministically — the same inputs give you the same result, which is the difference between a pipeline and a slot machine.
It ships as a URL, and only carries what you used
Export is a real web experience: semantic HTML for a fast first paint, with the runtime tree-shaken down to the operator families your project actually touches. A pure-DOM project carries no 3D payload at all.
An assistant that can only use nodes that exist
The built-in assistant builds against the real node registry, so it wires operators and parameters that are actually there rather than inventing plausible-looking ones. You get scaffolding you can open and edit, not a wall of code to debug.
Same brief, two shapes.
Today
Model and light it in a desktop tool. Wrangle the generative passes in two or three cloud tools, download, re-import. Rebuild the whole thing by hand in code because none of it runs on the web. Wire the interaction. Then the brief changes, and you walk the entire chain again from the top.
With nooodles
It is one graph. The geometry, the generative pass, the material, the interaction and the page are operators in the same environment. A direction change is a parameter, not a re-port — and the thing you were building is already the thing you ship.
Your output doesn't have to be a file.
A look-dev pass or a variant set is a workflow — it finishes and hands you material that you and your team then place. But the same graph can ship the interactive piece itself: a scene, at a URL, that someone opens and drives.
Nothing gets rebuilt to get there. The graph that made your frames is the graph that runs in the browser — so the piece and the material it produced can't tell two different stories.
The look-dev set
Renders, variants, sequences — files you take into the edit, the deck or the review.
- Mode
- Workflow
- Who opens it
- You and your team
The piece itself
A live page someone scrolls, turns, plays with — sent as a link, opened on a phone.
- Mode
- Scene
- Who opens it
- Your audience
Ten operator families, one graph.
Generation is one family among ten — a source, not the whole pipeline. Everything else you'd normally reach for a second tool to get is already sitting next to it.
Start from something that already works.
These ship with the beta — open them, run them, or take them apart.
Sketch to Render
WorkflowTake a concept sketch to a lit 3D render.
by Jacques ParysScroll Story
SceneDrive a 3D narrative page from scroll.
by Jacques ParysPhysics Rig
SystemLay out and animate with real physics.
by Jacques ParysAgent Hook
SystemDrive a graph by name from your agent over MCP.
by Jacques ParysWhat makers ask first.
Do I need to know how to code?
No. The graph is the primary way you build, and most projects never need a line written. If you do write code, it's there when you want it — expressions on parameters, scripted operators, and shader work — so the ceiling isn't set by what the node palette happens to cover.
How does this compare to the node tools I already use?
Same lineage, different substrate. It's a procedural engine with operator families, a per-frame cook and typed wires, so the way you think about building will transfer. The differences are that it runs in a browser with nothing to install, that generative AI is a node rather than a bolted-on panel, and that the web document is a first-class family — so the output can be a real page rather than something you rebuild for the web afterwards.
Can I self-host the AI?
Not on the entry plans — Free and Individual run hosted inference, so nobody needs a GPU to start. Running open models on hardware you control is the Studio and Enterprise option, for work that legally can't leave a building. See motion design studios for how that's set up.
What does it export?
Two kinds of thing. Files — stills, sequences and video for the assets a workflow produces. And the web: a scene exports as semantic HTML with a runtime tree-shaken to only the operator families you used, which you host wherever you like. A project that only touches the document family ships with no 3D payload at all.
Is there an API, or MCP?
nooodles speaks MCP. You can drive the editor, build and inspect graphs, read outputs and run a workflow by name from or anything else that speaks the protocol — so a graph you build can be a tool your agent calls.
Build it once, in one place.
Free to start, nothing to install. Open a Recipe, take it apart, and see how far one graph gets you.
Working with a team?
Tell us where to reach you and we'll set up a walkthrough.
No spam. A real reply from a human.