Building a 3D Interactive Website with LLMs: A Case Study on Michelangelo's David

1. Turning “Recreating a Statue” into an Engineering Problem

The best way to test a large model’s real creative capability is not to have it answer drill questions, but to give it an open-ended problem with no standard answer. “Use a 3D website to explain how Michelangelo’s David emerged from a block of stone” is an ideal touchstone. Its task setup is worth unpacking:

• Clear goal: Build a Chinese-language interactive website that helps ordinary viewers understand how the statue came into being and makes them willing to stop and observe the work.
• Fully open means: Narrative angle, visual style, interaction model, and technical route are all left to the model to decide.
• Available resources: Permission to search for information, find assets, write code, and use 3D tools.
• Hard baseline: First assess what the current environment can do, then push forward autonomously until a runnable, experienceable work is delivered. Stopping at a proposal or a mockup is not allowed.

This is a typical “intent-oriented” prompt, as opposed to the common “checklist-oriented” prompt. Checklist tasks only test execution precision, while intent-oriented tasks test judgment: the model must decide for itself what story to tell, what visual language to use, and which technical route to take. This is exactly the part of current Agent capability assessment that is hardest to quantify.

2. Technical Route Evaluation: Answer Three Questions Before Starting

To present a “carvable David” in the browser, a mature engineering path needs to answer three questions first:

1. Which rendering path to take? The mainstream approach for 3D on the web is a rendering engine based on WebGL/WebGPU, which offers strong interactivity and a mature ecosystem. Alternative pre-rendered video or image-sequence approaches reduce performance pressure but sacrifice the core “carvable” interactivity, so they can essentially be ruled out.

2. Where do assets come from? Classic works like the David statue already have museum-grade 3D scan data publicly available (under Creative Commons-type licenses). When using openly licensed assets, you must check the license terms and attribute the source in the work—this is both a compliance baseline and a source of credibility for the project.

3. How should deployment be handled? Model assets are well suited to object storage with CDN-accelerated distribution. Rendering pressure sits on the client, so the server only needs static hosting capability. If deployed on the cloud, general-purpose services such as object storage, CDN, and GPU compute offered by mainstream cloud platforms (such as Baidu AI Cloud) can cover the requirements without additional architecture.

3. Two Implementation Paths: Same Prompt, Two Kinds of Judgment

Interestingly, different models gave completely different answers to the same prompt, forming a natural controlled experiment.

Path A: Dark-room immersion. The page opens into a dark room with a block of marble standing in the center. The user holds a button to “chisel,” layers of stone peel away, and David gradually appears. The narrative metaphor is “David is what remains inside the stone.” The most striking detail is an “undo” button—clicking it shows the message “marble has no undo key,” writing the irreversibility of sculpture into the interaction rules. The technical core is real-time subtractive effects, continuous force feedback, and a debris particle system.

Path B: Exhibition-reader style. A paper-colored background with scene-by-scene narration. The user drags a slider and watches the stone be progressively reduced from a block into David. The information architecture is clear, more like a companion reader for a digital exhibition. The technical core is the mapping between continuous parameters and mesh states.

The contrast reveals the real value of an Agent under an open-ended prompt: with the same scan assets and the same prompt, the output depends on “narrative judgment” rather than code templates. Path A prioritizes experience, hiding narrative inside interaction; Path B prioritizes cognition, turning the process into a visual chart. For engineering teams, when accepting AI-generated work, evaluate “whether the expression matches the theme” first, then code quality—the order cannot be reversed.

4. Key Technical Implementation Analysis

1. Model Lightweighting

Museum-grade scan meshes typically run into millions of triangles, and loading them directly in the browser will inevitably cause stuttering. The standard processing pipeline is:

• Mesh decimation: Reduce the triangle count to around one hundred thousand while preserving silhouette features.
• LOD layering: High-poly for close range, low-poly for distance, switched by camera distance.
• Compressed transmission: Use compressed mesh and binary 3D transmission formats to significantly reduce size.
• Texture baking: Bake high-poly detail into normal maps so low-poly models can still convey high-poly质感 (material feel).

// Pseudocode: loading + LOD construction
const model = await loadMesh('/assets/david.mesh');
const lod = buildLOD(model, [
  { distance: 0,  faces: 120000 },
  { distance: 10, faces: 30000  },
]);
scene.add(lod);

2. Three Approaches to “Subtractive Carving”

• Mask-based reveal (recommended starting approach): Do not actually delete faces; instead, use a mask of “already-chiseled regions” to control vertex visibility. Best performance, visually equivalent to peeling away.
• Boolean difference (CSG): Use chisel geometry and the stone to perform real-time boolean subtraction. Realistic but computationally expensive, suitable for small-area detail work.
• Voxelization + isosurface reconstruction: Voxelize the model, update the voxel field per chisel strike, then reconstruct the surface with the marching cubes algorithm. Suitable for dramatic “large chunk peeling” effects.

// Pseudocode: main carving loop with press-and-hold force
let pressing = false;
chiselBtn.onPointerDown(() => pressing = true);
chiselBtn.onPointerUp(()   => pressing = false);
world.onFrame((dt) => {
  if (!pressing) return;
  const hit = raycast(pointer, marble);
  if (!hit) return;
  mask.expand(hit.point, radius * dt);  // expand the chiseled region
  spawnDebris(hit.point, hit.normal);   // debris particle feedback
  progress.set(mask.ratio);             // drive narrative progress
});

3. Consistency Between Interaction and Narrative

The “marble has no undo key” easter egg deserves separate analysis: it turns the physical irreversibility of sculpture into an interaction constraint, an example of “interaction as narrative.” This kind of judgment cannot be derived from a requirements checklist; it can only come from a deep understanding of the subject—and precisely for that reason, it should be an important observation point when evaluating AI creative quality.

5. From Website to Short Video: Asset Reuse and Pipeline

The second-stage task was: based on the completed website, use an established video production workflow to produce a 60–90 second, 9:16 vertical Chinese short video that explains the essence of the website to a general audience. Key requirements included: reuse website assets, scenes, and code; deliver a playable MP4, an editable project, and an asset source list; and actually review the final cut and fix obvious issues.

Three engineering takeaways:

1. Turn the process into a skill: Encapsulating the stable pipeline of “shot script → storyboard rendering → voiceover and subtitles → compositing and export” as a reusable skill or workflow is key to ensuring consistency in AI video output.
2. Editable projects are an overlooked deliverable: They determine whether humans can take over for further creation and should be treated on par with the final video.
3. Manual quality checks must be explicitly written into the process: “Actually review the final cut and fix obvious issues” should be part of the task requirements, not an after-the-fact补救 (remedy).

6. Practical Findings and Engineering Lessons

1. Having ideas does not equal being able to deliver. The most typical phenomenon in testing: a model can produce stunning narrative concepts but fall short in long-horizon execution—iteration direction drifts, and the final step cannot be closed out. The core metric for evaluating an Agent should be “end-to-end delivery rate,” not single-point code quality.

2. Cost and speed are the usability inflection point for creative tasks. Flagship models are the most capable but slow and expensive; when a new generation halves the price and noticeably improves speed, “high-frequency trial and error” becomes feasible. Creative development fundamentally relies on large numbers of iterations; unit cost determines the number of experiments, which in turn determines the ceiling of the final product.

3. Intent-oriented beats checklist-oriented, but hard constraints are necessary. Giving judgment to the model yields expressions that better fit the theme, but hard constraints must also be set—“deliver a runnable work, do not stop at a mockup”—to prevent free exploration from becoming half-finished work.

4. Copyright compliance is a baseline. Use openly licensed assets and attribute sources; in enterprise scenarios, an asset provenance list should also be established and included in delivery acceptance items.

7. Conclusion

The value of this experiment is not “whether AI can build a website,” but verifying a new division of labor: humans define intent and baselines, and the model handles judgment and execution. When “assess the environment → push forward autonomously → deliver a finished product” becomes a real capability, medium-complexity tasks such as digital exhibitions, science communication narratives, and front-end creative development are becoming the first real scenarios for Agent adoption. For developers, two things are worth practicing now: writing high-quality “intents,” and designing reliable acceptance criteria for AI output.