Stop porting your own work between 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 what 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.
Drag a value onto the thing it should drive
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.
What you make with it.
Skip the part where you rebuild the design.
The graph is the app. The document, the interaction and the 3D are one thing — so there is no flat mock to reimplement, and nothing drifts between design and build.
No design-to-code hand-off
The document is a first-class part of the graph — real elements, real CSS, real semantics. What a designer builds is what ships. You stop being the person who rebuilds a picture of the thing, and the pixel-comparison round disappears with it.
Deterministic, typed and inspectable
Strictly typed wires refuse mismatched connections instead of silently coercing them. The per-frame cook recomputes only what changed, and you can read what changed and why. It behaves like a system you can reason about, not a black box.
Escape hatches where you want them
Expressions on parameters, scripted operators and shader work are there for when the node palette runs out. The ceiling is not set by what someone else anticipated — it's set by what you're willing to write.
The export is an ordinary web page
A static semantic-HTML shell plus a runtime tree-shaken to only the families the project actually uses. A pure-DOM project carries no 3D payload. No proprietary player, no runtime lock-in, no vendor script between your page and the browser.
Agent- and script-reachable
It speaks MCP, so graphs can be driven, built and read from whatever agent or tooling you already use. Nodes are addressable by name, parameters are readable and writable, and the whole thing is scriptable from outside the canvas. An agent can also ask for the current render and iterate against what it sees, instead of working blind against a description of the graph.
Playable, not watchable.
Tap a link and it's already running. No install, no app store, no separate build — input, state and 3D live in the same graph as the artwork.
Input is part of the graph
Pointer, touch, keyboard, gamepad and hit-testing are operators you wire straight to what they drive. They're not a scripting layer bolted on at the end, so a drag can move a camera, a colour and a sound at once — and you can see the wire that does it.
State machines you can watch running
What the piece is doing now, and what moves it somewhere else, is a visible graph: title, playing, won, retry. You read the behaviour off the canvas instead of untangling conditionals, and you change it by moving a wire. You can also watch it run: the active state carries a ring, dwell shows as a progress bar, and a wire fattens as its condition approaches firing, so debugging is watching rather than logging.
Physics you direct, not a physics checkbox
Geometry, materials and rigid-body simulation cook every frame. Things fall, collide and settle because the piece is genuinely computing, not replaying a recording — so it responds to whatever the person does rather than the path you anticipated. You direct the solver too — hinge and slider joints with motors, impulse and torque, and turbulence you can weight with a field so it applies where you put it.
It ships as a link
No install, no store review, no native build. Someone opens a URL on a phone and is playing. And a piece that never uses 3D carries no 3D payload at all, so a small piece stays small.
Change it after it's live
It's a graph, not a build. Tune a number — difficulty, colour, timing — and what people are using is updated. No recompile, no resubmission, no waiting on a release window.
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.
The look-dev, and the piece that ships.
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 what you were building is already what 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 what comes back is material you place yourself. The piece that ships is a scene, and you never rebuilt it to get there.
It is early, and you will find edges — the families you'd reach for are here, some of the conveniences you're used to are not yet, and we'd rather you hit that in an afternoon than three weeks in. 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
When something works, save it and run it again.
These ship with the beta. Take one apart before you build anything from scratch.
Sketch to Render
WorkflowTake a concept sketch to a lit 3D render.
Scroll Story
SceneDrive a 3D narrative page from scroll.
Physics Rig
WorkflowLay out and animate with real physics.
Agent Hook
WorkflowDrive a graph by name from your agent over MCP.
Embed Widget
SceneDrop a live scene into an existing site.
Variant Matrix
WorkflowRun the full product × message × market grid.
The ones that matter.
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?
Yes, and today that is the main path. Point a provider node at Ollama, LM Studio or llama.cpp and the model runs on your own machine with no cloud round-trip. The alternative today is a key you paste, which sends the work to your own provider account under your agreement with them. Hosted generation, where we run it for you, is next rather than now.
What does it export?
Two kinds of output. 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 Claude Code or anything else that speaks the protocol — so a graph you build can be a tool your agent calls.
What does it actually export?
A folder. Semantic HTML, CSS and JavaScript, plus the assets the project uses. The runtime is tree-shaken to the operator families present in the graph, so a DOM-only project ships no 3D code. Put it behind any static host or drop it into an existing build — it's a web page, and it's yours.
Can I version-control a graph?
Partly, and we'd rather be straight about it. A scene is a file on disk, so you can commit it, branch it and see that it changed. What you can't do yet is read the diff the way you read a source diff — the serialised form is structural, not line-oriented, so a review tells you which nodes and parameters moved rather than telling you a story. A more readable on-disk format and a proper graph diff are being worked on. Until then, treat graph merges the way you'd treat binary assets: lock, don't merge.
Is there an API?
Today it's MCP. A running graph exposes a tool surface over the protocol: list and create nodes, connect them, read and set parameters, set expressions and flags, read back geometry, tables and channels, and trigger events. Anything that speaks MCP — an agent, a script, your own tooling — can drive a graph by node name. A conventional HTTP API for headless workflow runs is on the list and is not built.
Model it, wire it, and ship it from the same tab.
Free to start, nothing to install. Open a Recipe, take it apart, and see how far one graph gets you.
You'll find the edges faster than we will
You're the people who'll take it somewhere we didn't plan for. Tell us what you're building and what's missing — a list of absent operators from someone who has actually tried is worth more to us than any roadmap meeting.
No spam. A real reply from a human.