Recreating Michelangelo's David with LLMs: A 3D Interactive Web Development Case Study

1. Project Design: Why “Carving David” as the Test Case?

Recently, I conducted an experiment: assigning a nearly constraint-free, open-ended prompt to an LLM coding assistant, challenging it to execute an “ambitious creation”—building an interactive website that helps ordinary people understand how Michelangelo’s David was born from a block of stone. The goal was for the audience to not just memorize historical facts, but to gain a new understanding of “the act of carving” and be compelled to pause and observe the artwork.

This prompt holds testing value for three reasons:

• Inherent Computability: The essence of carving is subtraction—removing excess material from a stone block. This naturally maps to technical approaches like Constructive Solid Geometry (CSG), voxel culling, and distance field clipping. The model has a clear implementation path, avoiding the loop of “overthinking without executing.”
• Strong Coupling of Narrative and Technology: If the goal were merely to teach art history, a standard text-and-image template would suffice. To make the audience “gain a new understanding of carving,” the “subtraction” must be transformed into an operational interaction. This simultaneously tests the model’s creative judgment and engineering execution.
• Verifiable Deliverables: Whether the final product runs, if the 3D is smooth, and if the copy holds up can be judged at a glance. This effectively avoids false completion, where the model just generates beautiful proposal documents.

2. Prompt Engineering: Delegating Decision-Making

The prompt deliberately constrains only three things: the target audience (ordinary people), the expected effect (gaining a new understanding of carving and willing to linger), and the delivery standard (runnable, experienceable, not stopping at the proposal or rendering stage). The narrative angle, visual style, interaction method, and technical route were left entirely blank. The model was explicitly required to first assess its current environment’s capabilities, then autonomously proceed to delivery.

Goal: Create an interactive website that helps ordinary people understand how the David statue was born from a block of stone.
Expectation: The audience gains a new understanding of "carving" and is willing to stop and observe.
Constraints: Narrative, visuals, interaction, and tech stack are up to you. Assess your environment capabilities first, then autonomously proceed to a runnable deliverable.

This approach contrasts with the common “checklist-style” requirements. Checklists test a model’s execution capability, while open-ended prompts test its judgment. How will it choose the narrative angle? Will it proactively search for assets? When facing ambiguity, will it repeatedly ask for clarification, or make a decision and provide reasons? For teams evaluating the true level of AI coding assistants, the latter provides far more information than the former.

3. Two Divergent Implementation Routes

Two independent generations of the same prompt took entirely different routes, forming a perfect comparative experiment.

Route 1: Dark Room Chiseling, Interaction-Heavy. Opening the site reveals a dark room with a marble block in the center. The user holds down a “chisel” button, and the stone peels away block by block, slowly revealing David from within. The entire site feels like a small ritual: the only action is chiseling, and the only feedback is the reveal. The most interesting part is an easter egg—the UI provides an “Undo” button, but clicking it prompts the message: “Marble has no undo key.” Carving is irreversible, and the interaction design perfectly mirrors the theme. Such details cannot be listed in a checklist; they are spontaneous design decisions born from the model’s understanding of the subject.

Route 2: Exhibition Reader, Narrative-Heavy. The other version took a “paper exhibition” route: a paper-colored background with a story progressing in four acts. The user drags a slider to watch the stone block “subtract” layer by layer into David. It resembles a digital companion to a physical exhibition, with clear information architecture, a low learning curve, suitable for fragmented browsing scenarios.

Shared Data Foundation. Both versions utilized the same museum-grade 3D scan data of David (STL format, under a Share-Alike open license). This proves the model functioned effectively in the autonomous retrieval phase: it found authentic, legally compliant assets rather than passing off a low-poly model.

4. Core Technical Breakdown: Making “Stone Peeling” Work

4.1 3D Assets: Loading and Decimation

The original scan file is massive (often tens to hundreds of MBs); loading it directly will freeze the browser. The standard processing pipeline is: Decimation → Normal Recalculation → Mesh Compression Encoding → Asynchronous Chunk Loading. During decimation, a balance must be struck between volume and detail: the face, hands, and curly hair are detail-sensitive areas where higher mesh density should be preserved based on curvature.

// Pseudo-code: Load the decimated STL asset and apply marble material
const geometry = loadSTL('/assets/david-decimated.stl');
geometry.computeVertexNormals();
const marble = new PBRMaterial({
  color: 0xdcd6ca,   // Cold white of Carrara marble
  roughness: 0.5,
  metalness: 0.02,
});
scene.add(new Mesh(geometry, marble));

4.2 Three Approaches to the Peeling Animation

“From block to statue” is the technical core of the site. There are three common industry approaches:

• Voxelization Approach: Voxelize both the statue and the bounding box. The carving process removes voxels layer by layer from the block based on a distance field. It’s intuitive and makes particle debris easy, but resolution is limited, and the blocky look is obvious in close-ups.
• CSG Boolean Subtraction: Use a series of “cutter” meshes to perform boolean differences on the stone shell. This is closest to real carving semantics, but boolean operations are highly expensive in browsers, making it better for pre-baking rather than real-time.
• Distance Field + Shader Clipping: In the preprocessing stage, calculate the shortest distance from each vertex of the “stone shell” mesh to the statue’s surface (accelerated using Bounding Volume Hierarchy, BVH). At runtime, discard fragments in the fragment shader based on progress. This offers the best performance, and noise can be added to the edges for a jagged, uneven feel, making it the preferred choice for real-time web scenarios.

// Preprocessing: Calculate approximate shortest distance from each vertex of the stone shell to the statue surface
const dist = new Float32Array(shell.geometry.attributes.position.count);
for (let i = 0; i < dist.length; i++) {
  dist[i] = bvh.closestPointToPoint(getVertex(shell, i)).distance;
}
shell.geometry.setAttribute('aDist', new BufferAttribute(dist, 1));

// Fragment shader: uReveal goes from 0 (full stone) to 1 (statue fully revealed)
float edge = (1.0 - uReveal) * uMaxDist;
float chip = hash(floor(vWorldPos * 6.0)) * 0.08;  // Noise creates jagged peeling edges
if (vDist > edge + chip) discard;

4.3 Interaction and Narrative Details

• Input Method: Route 1 uses “hold to chisel,” trading duration for progress to simulate the feeling of labor. Route 2 uses a slider, explicitly giving progress control to the audience for easy alignment with the four-act narrative.
• Feedback Loop: The moment of peeling sprays stone chip particles (a lightweight billboard particle system works fine), paired with chisel sound effects, forming a complete “operation-feedback” loop.
• Lighting and Texture: A dark room with single-side hard light best expresses the texture of marble. The material uses high roughness and low metalness, with an added layer of faint subsurface light approximation.
• Restrained Copywriting: All explanations revolve around “subtraction,” avoiding piling on art history jargon, serving the core goal of “letting the audience understand carving.”

4.4 Performance and Delivery

Before going live, run through a checklist at least once: mobile frame rate (the majority of 3D web traffic comes from phones), first-screen load time (mitigated by model compression and progress bars), memory peaks (timely release of geometries and textures), and asset license compliance. To deploy the work publicly, the standard practice is to place compressed model assets in object storage and distribute them via a CDN. For heavy-load tasks like inference or video rendering, elastic scaling can be achieved using general-purpose capabilities like GPU computing and container services, such as those offered by Baidu AI Cloud.

5. From Website to Short Video: Content Asset Reuse

After the website passed acceptance, the second phase of the experiment was having the model generate a 60–90 second, 9:16 vertical short video based on the existing work. It had to decide how to adapt the story for video, reuse the site’s scenes and code, or reorganize the visuals. The deliverable was a playable final cut, an editable project, and asset sources, with explicit instructions to actually review the video and fix obvious issues.

A highly efficient approach in practice is to treat the website itself as a “rendering engine.” Use scripts to drive the camera path and key uniforms like uReveal, capture frames sequentially, and synthesize them. Then, add voiceover and subtitles, re-storyboarding for the vertical screen rhythm. The key constraint here is “actually reviewing the final cut”—common issues with generative video (audio-visual desync, subtitle truncation, jump cuts) must be manually resolved. Human-in-the-loop is an indispensable part of current multimodal delivery.

# Schematic configuration for a procedural video pipeline
scenes:
  - { id: prologue, source: reuse_camera_path,      duration: 8s }
  - { id: carving,  source: drive_uniform_uReveal,  from: 0, to: 1, duration: 30s }
output: { aspect: "9:16", duration: "60-90s",
          checks: [audio_sync, subtitle_safe_zone, transition_continuity] }

6. Practical Findings and Lessons Learned

1. There is a gap between “having ideas” and “sustaining delivery.” Under open-ended prompts, models can offer surprising narrative angles and interaction easter eggs. However, end-to-end delivery involves asset retrieval, long-code generation, and multi-turn debugging, testing both inference speed and cost. Only when model iterations reduce per-task cost and latency does the space for multi-turn trial and error truly open up. For creative tasks, “daring to try a few more rounds” is a prerequisite for quality.
2. Open-ended prompts expose model limits better than checklists. A comprehensive evaluation method combines both: first, open exploration to observe the model’s autonomous decision-making chain; then, checklist-based acceptance to hold the engineering baseline.
3. The human role shifts to the poles: prompting and acceptance. The prompt defines the direction, and acceptance sets the baseline (runnable, smooth, compliant). The middle implementation is handed to the model. Meanwhile, aesthetic judgments—such as whether the “undo easter egg” is worth keeping—currently remain a human strength.

7. Conclusion

Michelangelo famously said: the statue was already in the stone; he merely removed the excess. This statement explains the birth of David and unexpectedly serves as an accurate metaphor for current LLM coding. In the initial draft delivered by the model, the work is already “hidden.” The developer’s job is more like carving—using prompts to define the stone block, and using acceptance to chisel away the excess. As model costs and speeds continue to improve, the works worth being “chiseled out” will only increase.