Opus 5.5 has been viral recently, especially all the "one prompt" fancy demos online.
But I wanted to try something different: not a one-shot scene, but a complete project that has to iterate through multiple sessions, maintain a coherent architecture, animate a full world, and finally export a polished video.
So I gave Opus 5.5 a fairly ambitious project:
Map of Middle-Earth — a miniature 3D Middle-earth diorama from LOTR, built with Three.js and WebGPU.
The final result is a browser-rendered world with real terrain data, 24 landmarks, dynamic weather and lighting, a cinematic route across the map, an original orchestral score, and a 3:47 short film rendered frame by frame.
This article is about what I learned from building the whole thing with Claude Code.
1. Architecture before implementation
One thing I've learned from working with coding agents is that large projects become messy quickly if you let every new feature create its own system.
Eventually the project may still "work", but nobody understands the whole thing anymore.
So before detailed modelling, I asked it to design the system space first:
- third-party geographic data
- Python baking tools
- terrain / water / vegetation / environment
- landmarks / emission / effects / route
- WebGPU render / interactive explorer
- stills / QA / video
Later, when the project grew from simple placeholder landmarks into a full cinematic world, the underlying architecture barely needed to change.
We mostly kept filling existing slots.
2. Make every frame a complete state
One requirement became increasingly important once video production was in:
any frame should be renderable independently.
So the project revolves around a SceneState which every system evaluates.
This means the route line, camera placement, annotations and environmental effects can all be reconstructed for an arbitrary timestamp.
It allowed us to:
- jump directly to a film frame
- resume interrupted renders
- compare specific frames
- render QA stills without playing the film
- increase samples only for selected frames
- render effects consistently across separate processes
Even particles were designed to be mostly stateless.
Instead of accumulating simulation history, their appearance is derived from a deterministic effect clock.
3. Landmarks are declarations, not mini applications
There are 24 major landmarks in the finished world.
The obvious approach was to build each location as an independent Three.js scene.
But I deliberately avoided that.
Each landmark instead declares what it needs.
Shared systems then realize those declarations.
A landmark doesn't create its own render loop, invent a new material system, or build a new particle engine.
It simply says:
I need smoke here.
or:
I need an emissive light here.
or:
flatten this terrain region.
That made it possible to build very different locations without turning the repository into 24 unrelated projects.
4. AI visual work still needs QA
AI can write valid geometry that looks terrible;
It can produce mathematically correct camera placement that frames the wrong thing;
It can also build a technically functioning landmark that reads as a toy from the actual film camera.
So "the code runs" is never enough.
We built a capture and review pipeline around the project.
The tooling could automatically render:
- individual shots
- contact sheets
- day/night comparisons
- before/after comparisons
- reference comparisons
- QA sets
The model can generate large amounts of code.
But visual judgment still has to close the loop.
Generation without evaluation is just faster randomness.
5. The laptop shaped the procedure
The entire project was developed on a fairly modest Windows laptop:
- 8GB RAM
- Intel UHD integrated graphics
- shared memory between CPU and GPU
Early on, full QA runs could push the machine into memory pressure.
Chrome, Vite, Node, capture tooling and the rendered scene were all competing for the same limited memory.
Instead of simply accepting instability, the tooling gained resource awareness:
- one heavy GPU job at a time
- machine-wide GPU locking
- memory guards before capture
- separate preview/review/final quality tiers
- sequential rather than uncontrolled parallel rendering
- resumable film rendering
The real-time preview was deliberately tuned for that machine.
Final quality could then spend much more time per frame offline.
6. Turning the world into a film
Once the static world was done, the next major task became directing.
The final film uses a picture-locked timeline containing camera movement, environmental state, annotations, effects and route progression.
A luminous gold path moves across the map while the camera travels from west to east.
The journey also moves through a full day, from daylight in Shire to night near Mordor.
The score became another interesting experiment.
Instead of using existing LOTR music, the project generates an original orchestral score.
The music pipeline uses Python tooling together with orchestral sample libraries.
The score follows the locked picture and is rendered separately before final assembly.
After building this project, I think the impressive part of AI coding models isn't one-shot generation.
The stronger capability is continuity across domains.
The same model can work across:
- architecture
- procedural modelling
- browser capture
- visual QA
- camera choreography
- music tooling
And because the project had stable architecture and project-state documents, later sessions could continue without reconstructing the entire context from scratch.
That makes AI especially useful for full-stack solo projects.
The code, architecture, rendering pipeline, QA tooling and reproduction steps are all open-source here:
https://github.com/earthwalker17/map-of-middle-earth
This is a non-commercial fan project, and none of the original film footage or music is used.
I started because I wanted to see how impressively Opus 5.5 could do for 3D scenes.
I ended up caring much more about:
Can a coding model stay coherent across an entire production process?
For this project, the answer was yes — if the architecture, constraints, judgment and verification loops are well-defined.
Top comments (0)