AI Cinematic Website Build With Cursor

An AI cinematic website build with Cursor, Claude Blender MCP works by treating the agent as a junior designer you steer, not a vending machine. You supply the idea, reference screenshots, sourced 3D assets, and a design system, then let the agent render the hero, animate it, and verify each change in a browser until the result holds up.

What does the AI cinematic website build workflow actually require?

An AI cinematic website build with Cursor, Claude Blender MCP rests on four inputs before any code is generated: a plain-language idea, reference screenshots, real 3D and image assets, and a written design system. In the recorded walkthrough, Cursor's AI code editor hosted the agent session, Claude-family models handled UI reasoning, and Blender MCP let the agent drive the open-source Blender 3D suite through a Model Context Protocol connection.

The workflow then loops: prompt, render, screenshot in a browser, critique, revise. The agent, not the human, is responsible for opening the page and comparing its output against the saved references. That verification step is what separates this from pasting one sentence into a chat box and accepting whatever appears.

The host chose the Ferrari livery for the demo, so every later instruction carries the word Ferrari. Team switching, technical detail pages, and anything outside the hero were explicitly deferred. Narrow scope per run is a repeatable rule here, not a stylistic choice: the agent produced the first hero in a run the host described as over an hour of work.

How do references and a design system stop AI slop?

Reference screenshots and a written design system stop slop because they replace adjectives with images and tables. Words like cinematic, premium, and high quality map to a thousand possible layouts; a screenshot maps to one. When the host wrote "type behind" in the brief, only the reference image made that instruction unambiguous for the agent.

The design system came next. The agent was told to spin up one sub-agent per team, pull each team's palette from its official site, and write a design file per team containing colors, typography, and casing rules.

Each design file used a shared table structure: role, name, hex, plus RGB and HSL values, contrast notes, and usage text. Palette entries were labeled main, accent, text, and muted, with screen values rather than print specifications. One dark background and one type system were decided once and repeated across all three team files. Three Google Fonts covered display, UI, and monospace roles for specs and numbers.

Keeping assets in a folder beside the references and design files matters more than it sounds. The agent reads paths, and a references/ directory next to an assets/ directory makes the comparison loop mechanical instead of conversational.

Sourcing 3D assets: Sketchfab licenses and file size

A 3D model beat both an image and a video for the hero car, because the car had to move and respond to the pointer. The host sourced models from Sketchfab, a marketplace and hosting platform for 3D and AR content, filtered to downloadable results, and downloaded each in glTF binary (GLB) format at 4K texture size.

License terms were checked before download. The three car models used in the demo carried Creative Commons attribution licenses, which require crediting the creators. Driver headshots came from a press-style search for Formula 1 driver headshots.

File size was the immediate problem. One downloaded model arrived at 57 MB according to the host's on-screen check, and a separate timestamp in the video shows the same asset referred to as 54 MB. Either way it was far too heavy for a web hero. The agent optimized it to 0.98 MB, a reduction of roughly 58x from 57 MB, or roughly 55x from 54 MB. Both readings are the host's own screen values, not an independent benchmark.

That compression is a component-level result for one GLB asset in one Blender MCP run. It is not a general claim about web 3D performance, and it says nothing about render cost on a mid-range device.

How Blender MCP connects the agent to Blender

Blender MCP connects the agent to Blender through a Model Context Protocol server, so the agent can inspect and modify the scene while the human never opens the 3D application. In the walkthrough, the host installed Blender, enabled online access under Preferences, System, and installed the add-on from a downloaded zip inside the Add-ons panel.

The server then had to be registered with the editor. The steps were:

1. Install uv, the Python package and tool runner, and confirm the version.
2. Clone the Blender MCP repository to the local machine.
3. Read the absolute path with pwd in the terminal.
4. Add a server entry in Cursor's MCP settings pointing the command at uv and the path at the cloned repository.
5. OpenAI fresh session and ask the agent to confirm it can reach the server.

The host noted that other editors can be configured the same way with a converted config file. Two practical limits appeared: adding a new MCP server required a new agent session, and the cloned repository path must match the real user directory rather than a placeholder name.

Prompting the hero: five instructions that changed the output

The first hero prompt worked because it named the deliverable, the inputs, the constraints, and the stopping condition. The host's instruction set told the agent to build only the Ferrari hero from the existing 3D model, driver images, design file, and typography system, and to ignore team switching and technical sections.

Five instructions carried most of the weight:

• Read the reference folder and combine the strongest ideas without copying any single mockup.
• Prepare the GLB file so it is web ready, smaller, and not broken in the process.
• Render the actual 3D model rather than a screenshot of it.
• Place one driver left, the car centered, the second driver right, with large editorial type behind the subject.
• Use the browser to inspect the result at desktop width and keep iterating until the hero feels polished.

The last instruction is the one most people omit. Agents tend to check a render once, declare success, and stop. The host described the loop as dependent on that explicit line, and the resulting hero took over an hour of agent work before returning.

Iterating by eye: what to say when the output is wrong

Iteration worked because the host described the defect rather than the fix. After the first hero, the critique was that the monospace face looked machine-generated, the headline was too large, the drivers were too small, and the car occupied too much vertical space. No CSS values were supplied.

The second pass dropped monospace entirely in favor of a normal face, referenced mockup number four for a smaller headline treatment, and asked for serif driver numbers placed near each driver. Driver headshots were reprocessed first: an image model was used to convert a flat headshot into a cutout hero asset with a transparent background, preserving the suit and identity, and angled toward the car.

A short third round pushed the drivers larger, moved numbers 16 and 44 toward the screen edges, added a red glow behind each driver, and requested a different display font for the headline. The agent researched candidate fonts and picked one, which the host accepted. Roughly six or seven messages total were exchanged, all phrased as perception rather than specification.

The pattern is worth copying: say too dark, too light, too big, too small, wrong font. You do not need to know why a typeface fails to know that it does.

Adding the loading sequence and the scroll animation

Animation was split into two runs because each depended on the previous one finishing. The first run added an entrance layer and a loading state; the second added two scroll-driven depth layers that move the car and the camera.

The entrance layer was specified as concrete Notion: the car grows roughly 10 to 15 percent, drivers enter from the left and right edges, and the headline scales down from large to its settled size. Because a 3D asset needs to download, the host asked for a splash screen based on Formula 1 start lights, where five lights illuminate individually and then the page loads.

The scroll run covered the side profile and a camera path that stops at six named components: front wing, front suspension, halo, sidepod, power unit, and rear wing. The host suggested an animation library such as GSAP as one option and left the choice to the agent. Once the foundation and the Blender pipeline existed, this prompt was conversational rather than structured.

The agent also ran its own checks, including a throttled-network load test, and reported that the page passed. That is first-hand host observation of one agent session, not a reproducible performance study.

What the recorded build proves and what it does not

The build proves that a non-designer can direct a coding agent through a deliverable that reads as deliberately designed, given strong inputs. It does not prove that any single prompt produces this result, that the workflow generalizes to every framework, or that the compressed asset performs equally across devices.

Several details in the video are time-bound. The host referred to model generations that were current during recording and predicted newer versions by release date; treat all model version names in that discussion as historical. The recorded session also used a 1 million token context window and a high reasoning effort setting, which are editor configuration choices, not requirements.

Here is how the main claims separate by evidence type.

Claim	Evidence class	Scope
GLB reduced from 57 MB to 0.98 MB	Host's own screen check (class D)	One Ferrari car asset, one run
Hero built without human coding	Host narration (class D)	Single demo project
Throttled-network load test passed	Agent self-report relayed by host (class D)	One agent session
Models recommended for the workflow	Host opinion (class E)	Recording date, not current
Design system prevents drift	Host experience (class D)	Repeated across three team files

If you want the same result, the transferable parts are the sequence and the review loop, not the specific model names.

AI cinematic website build FAQ

• Do you need to know Blender to do this? No. The agent operates inside Blender through a Model Context Protocol server, so the human only installs the application, enables online access, and adds the server to the editor. The host stated no working Blender knowledge.
• Why use references instead of a longer written brief? Reference images collapse ambiguous adjectives into a single visual target the agent can compare against its own render. Words like cinematic and premium describe many possible layouts, so the agent cannot verify whether it matched the brief.
• How large should a web 3D asset be? The host set a working ceiling near 10 MB and treated the original 57 MB download as unusable. The agent in the demo reached 0.98 MB, but the correct target depends on the scene, texture budget, and target devices.
• Can the agent check its own work? Only if the editor exposes a browser tool and the prompt explicitly demands repeated inspection at desktop width. Without that line, agents typically verify once and stop, which leaves layout and contrast problems in place.
• Is any of this a benchmark? No. The size reduction and the load test come from one recorded session and are reported as host-observed results, not independent measurements.

Turning a recorded build into a written one

The interesting part of this workflow is not the render speed. It is that the whole method lives in spoken critique: too big, too dark, wrong font, move it up, keep going. That critique is the asset. It is also the part that disappears when it stays inside a 48 minute video.

If you have explained a build like this on camera, with the mistakes, the retries, and the reasoning, that recording already contains a written article. Skalablog takes a YouTube URL, transcribes the video, and drafts it into an article you can edit and publish.

Skala blog

Source video