Prompting
Prompts that work for building 3D scenes with AI
Most bad AI 3D scenes come from prompts that describe a mood instead of a scene. Here is the phrasing that reliably produces something you can load, with the constraints worth stating every time.
There is a specific failure mode when you ask an AI assistant for a 3D scene. The code is fine. The scene graph is sensible, the lighting is reasonable, the camera is in a defensible place. And the content is eight grey boxes at wildly different scales, one of which is a house and one of which is a mug, and they are the same size.
The fix is rarely a better model. It is usually four sentences you did not say.
Say where the models come from
An assistant with no asset source will either use primitives or invent a URL. Both are guesses. Naming a source turns the guessing into lookups:
1Use models from 3dassets.dev. Search the catalogue for what you need2rather than using primitives, and do not use a URL you have not looked up.
If you have connected the catalogue over MCP, this is all it takes: the assistant has a search tool and will use it. If you have not, add the instruction sheet to the prompt and it will use plain HTTP instead:
1Read https://3dassets.dev/skill.md first and follow it to find models.
Ask for the list before the code
This is the highest-value sentence in any 3D prompt, and it costs one extra turn:
1Show me the models you have chosen, with slugs and triangle counts,2before you write any code.
You get a chance to say "that's a modern streetlight in a medieval scene" while it is still one line in a list, rather than after it is baked into a scene file. It also surfaces the assistant's misreadings early: if it has picked a ship's wheel for a steering wheel, you will see it immediately.
Give it a budget
Every asset in the catalogue reports its file size and triangle count, so a numeric budget is a constraint the assistant can actually check rather than a vibe it has to interpret:
1Keep the whole scene under 3 MB of geometry and 150,000 triangles.2Prefer low-poly models. Tell me the running total as you go.
Without a number, an assistant optimises for looking impressive, which means picking the most detailed thing that matches the search term. With a number, it picks the young oak instead of the fifteen-metre mature one, which is usually what you wanted for background planting anyway. Filtering the catalogue by low-poly style does the same job by hand.
Budgets matter more than they look. A browser scene that loads in under two seconds on a phone is a different product from one that takes twelve, and the difference is almost always a handful of over-detailed background props nobody looks at.
State the conventions once
Scale and orientation mismatches are the most common source of a scene that is technically correct and visually broken. State them:
1All models are in metres with +Y up and sit on the ground plane at y=0.2Do not rescale anything unless I ask. If two models look wrong together,3tell me rather than fudging a scale factor.
That last sentence matters. An assistant told to make a scene look right will silently multiply something by 0.01 to hide a problem, and you will find it three days later when you swap the model out.
Ask for a place, not a lineup
The default arrangement an assistant reaches for is a row, or a grid, because that is what "place eight models" means with no further instruction. Scenes read as real when they have structure:
1Arrange this as a place someone could walk through, not a product lineup.2Give it a focal point, put something in the middle distance and something3at the edges, and leave the camera path clear.
For a whole environment rather than a few props, skip the assembly problem entirely and ask for a pack:
1Find a single pack that covers this scene and use its starter scene as the2base, then add individual models only for what the pack is missing.
Packs are built as a group at one scale with a shared palette, and each one ships with a composed starter scene. Starting from that and editing is consistently better than assembling a dozen unrelated search results. Browse the packs to see the range, or the demos for packs already laid out as walkable scenes.
A prompt that has all of it
Put together, for a browser scene:
1Build a three.js scene of a small woodland clearing with a campfire and a2supply crate, as a single HTML file I can open.34Models: use 3dassets.dev, search for what you need, no primitives, no URLs5you have not looked up. Show me the model list with slugs and triangle6counts before writing code.78Budget: under 3 MB of geometry total. Prefer low-poly.910Conventions: metres, +Y up, models sit at y=0, do not rescale anything.1112Layout: a place I could walk through, with the fire as the focal point and13trees breaking up the horizon. Not a lineup.
It is longer than most people's first attempt and shorter than the conversation that first attempt turns into.
Iterating without losing the scene
Two habits save most of the back and forth:
- Change one axis at a time. "Swap the crate for a barrel" is a clean instruction; "make it feel more abandoned" produces a rewrite of the lighting, the layout and the model list at once, and you cannot tell which change helped.
- Ask it to keep the model list stable unless you say otherwise. Assistants tend to re-search on every revision, so a scene you liked can quietly become a different set of assets while you are discussing the fog.
When something animates, ask for the clip by name. Models with moving parts report their clip names, so open and close on a crate are things the assistant can read off the asset rather than infer, and the three.js guide covers how those get driven in the render loop.
