Building an Interactive 3D Narrative Website: Recreating Michelangelo's David with AI

1. Designing the Brief: Give the Model a Creative Problem, Not a Checklist

The most valuable starting point for this kind of project is the prompt itself. Rather than listing functional requirements, the brief contained five key elements:

• Goal statement: Build a Chinese-language interactive website that helps general audiences understand how the statue of David emerged from a block of stone.
• Success criteria: Visitors should come away not just with historical facts, but with a changed understanding of what sculpting involves — and a willingness to pause and observe the work itself.
• Creative freedom: Narrative angle, visual style, interaction approach, and technical stack were all left to the executing agent.
• Process constraints: The agent could search for references, source assets, write code, and use 3D tools, but was required to first assess what was feasible in the current environment before proceeding autonomously.
• Deliverable definition: The output had to be a runnable, experiential piece — explicitly not a proposal or mockup.

The underlying distinction matters: checklist-style tasks suit deterministic engineering, while creative tasks are better constrained by user outcomes rather than implementation steps. When you clearly define the audience, the intended emotional response, and the deliverable, while leaving the solution space open, the model shifts from filling out a form to actually creating something. Supporting practices that worked well in this project included: allowing reuse of assets and code to encourage accumulation of reusable material; requiring an upfront environment self-assessment to reduce hallucinated proposals; and defining “done” through verifiable states like runnable, experiential, and traceable.

2. Same Source Material, Two Narratives: Interaction Metaphor Defines the Experience

Given the identical brief and source assets, two different AI coding assistants produced two strikingly different approaches — conveniently illustrating two classic paradigms of interactive narrative.

Approach A: The dark-room immersion route. The core thesis was “David is what remained in the stone.” The page opens into a dark room with a marble block at its center. The user holds down a button to chisel, and layers of stone fall away as the statue gradually emerges. The most memorable detail is an “Undo” button that, when clicked, displays the message: “Marble has no undo.” That single line turns the essence of sculpting — subtraction and irreversibility — into an interactive metaphor. The interaction itself becomes the narrative.

Approach B: The exhibition-reader route. A paper-toned background, a four-act linear structure, and a slider that lets users scrub through the block’s transformation into David. The information delivery is more linear, the cognitive load lower, and it works better as a “digital catalog” style educational piece.

The difference between the two routes has nothing to do with rendering technology. It lies in information architecture and interaction metaphor. The first prioritizes experience, using atmosphere and ritual to convey the theme; the second prioritizes comprehension, using structure and pacing to ensure information efficiency. This illustrates that in AI-assisted creation, what ultimately determines quality is the choice of expression, not technical accumulation. Details like the “Undo button + marble has no undo” line encode the author’s understanding of the subject directly into the interaction logic — and the fact that models can spontaneously produce such details when given sufficient creative freedom is precisely the value of open-ended briefs.

3. Technical Breakdown: From Scan Data to a Runnable 3D Web Page

3.1 Source Material: Openly Licensed 3D Scan Data

Both pieces were built from the same real 3D scan of Michelangelo’s David, published under an open license that permits use and sharing with attribution. Museum-grade public scan resources are excellent raw material for 3D narrative projects, but three points require attention: verify the license scope and attribution requirements; accept the reality of data size — high-precision STL files easily run into hundreds of megabytes, making direct browser loading impractical; and establish a standardized processing pipeline.

3.2 Processing Pipeline and Rendering Considerations

A typical processing chain looks like this:

1. Format conversion: STL contains only geometry — no materials, no optimized topology. It needs to be converted into a scene-friendly mesh format such as glTF.
2. Mesh simplification: Reduce polygon count within visually acceptable limits. Keep detail on desktop; load lower-poly versions on mobile.
3. Material and lighting: Marble can be approximated with PBR materials plus slight subsurface scattering. Combine with three-point lighting and dark-room fog for a gallery atmosphere.
4. Loading experience: Compression, progress indication, and failure fallbacks are all essential to avoid losing users to a black screen.

3.3 Three Implementation Approaches for the “Subtractive Sculpting” Interaction

This is the core technical challenge — making the chisel action feel believable in the browser:

• Boolean operations (CSG): Subtract the chisel’s swept volume from the stone mesh in real time. Most realistic, but each operation requires mesh recomputation, which puts pressure on frame rate. Best suited to short desktop interactions.
• Morph targets: Bake offline multi-stage meshes from “full block → half-carved → finished statue” and interpolate by progress at runtime. Best performance; ideal for the primary presentation path.
• Clipping + dissolve: Use a clipping plane or noise-based dissolve mask to “peel away” the outer shell according to progress, combined with normal-extended hard edges and particle debris to fake the chisel effect. Lowest cost.

Real projects typically combine approaches: the outer shell peeling uses clipping or dissolve, while the finished detail uses high-poly morph targets. Example code:

// Example: hold button to advance sculpting progress
const chisel = { now: 0, target: 0 };
holdBtn.addEventListener('pointerdown', () => { chisel.target = 1; });
window.addEventListener('pointerup',   () => { chisel.target = 0; });
function tick(dt) {
  // Damped approach creates the feel of pressing into stone
  chisel.now += (chisel.target - chisel.now) * Math.min(1, dt * 2.5);
  // Map progress to morph weight or clip plane position
  statue.morphTargetInfluences[0] = chisel.now;
  clipPlane.constant = lerp(startC, endC, chisel.now);
  // Debris particles: emit only while chiseling, recycle via object pool
  debris.emit(chisel.target > 0 ? 10 : 0, dt);
}

On the engineering side, mobile implementations should use Pointer Events uniformly for the intuitive “hold to advance, release to stop” interaction. Particle systems should use object pooling to avoid frequent creation and destruction. Listen for WebGL context loss and show a refresh prompt. Prepare a fallback path for low-end devices, such as reducing particle count or switching to 2D sprite sequences.

4. From Website to Video: Repurposing Assets for a Second Deliverable

The second stage of the task chain had the agent produce a 60–90 second, 9:16 vertical short video in Chinese, based on the completed website and its research. The deliverable included a playable final cut, an editable project file, and a source material list. The agent was also required to actually inspect the final output and fix obvious issues.

This stage validates asset reuse: the website’s 3D scenes, copy, and research conclusions are all ready-made material, and storyboards can be derived directly from them. Meanwhile, the acceptance criteria escalate from “produce a page” to “produce a media file” — harder, but also more automatable. Duration, aspect ratio, encoding, audio-video sync, and black frames can all be checked programmatically. Key engineering practices include: storyboard first — output the script and asset list for human confirmation before rendering to avoid full rework; annotate the source of every shot for compliance and traceability; produce a rough cut before the final render to control the cost of resource-heavy tasks.

5. Field Notes: Treating AI as a Capable Collaborator That Still Needs Management

1. Having ideas is not the same as carrying them to delivery. On long creative chains, models may stall midway or wrap up prematurely. The countermeasure is breaking the large task into milestones (research → prototype → runnable → polish), with acceptance checks and continuation at each stage.
2. Flagship does not mean best value. Stronger models are often slower and more expensive, while newer generations typically offer significant speed and cost improvements. Use fast, inexpensive configurations for prototype exploration, then scale up for the final output.
3. Quota is a real constraint for creative tasks. Video and other resource-heavy tasks consume substantial budget. Plan accordingly: use lightweight approaches during the draft phase and reserve capacity for key deliverables.
4. Environment self-assessment comes first. Requiring the model to inventory available tools, assets, and constraints before proceeding significantly reduces unrealistic proposals and surfaces failures earlier.
5. Define acceptance criteria upfront. Hard deliverable definitions like “runnable, experiential, traceable assets, self-checked final cut” are far more effective than “do your best.”

6. Conclusion: When Implementation Costs Drop, Creativity Becomes the Scarce Resource

Looking back at the entire task chain: one openly licensed scan dataset, two stylistically divergent runnable websites, and one playable short video. None of the technical components — mesh processing, WebGL rendering, particle systems, video composition — were new inventions. The real differentiation came from narrative and interaction choices: the thesis that “David is what remained,” and the line “Marble has no undo.”

Once large models push implementation costs low enough, the bottleneck of creation shifts from “can it be built?” to “is it worth building?” For developers, prompt engineering is evolving into a form of creative delegation: define the audience, the benefit, and the deliverable clearly; leave the solution space open; and back everything with engineering-grade acceptance criteria. That may be the single most valuable skill to practice in the AI era.