Sculpting David with LLMs: A Guide to 3D Interactive Web Development

1. Treating “Recreating David” as a Comprehensive Test

Instead of running standard benchmark tests, it is more effective to give an LLM an open-ended, comprehensive task: build an interactive website that helps everyday people understand how Michelangelo’s David was born from a block of stone. The goal is for the audience to not just memorize historical facts, but to gain a new understanding of “sculpting” and want to spend time observing the artwork. The model must independently decide the narrative perspective, visual style, interaction methods, and technical approach, ultimately delivering a runnable, experiential website rather than stopping at a proposal or mockup.

This task is valuable for three reasons. First, it is comprehensive: it involves art history research, 3D graphics, interaction design, and engineering delivery. Strong single-point capabilities do not guarantee a complete end-to-end workflow. Second, it is open-ended: with no fixed technical route, it tests the model’s judgment—requiring it to assess its current environment and capabilities, and then proceed autonomously. Third, it is verifiable: the deliverable is a working website where the user experience is immediately obvious, avoiding the evaluation distortion where a model “seems to know everything but fails upon implementation.”

From a prompt engineering perspective, this task design is highly reusable: provide clear goals and audience (general public, gaining new insights), set explicit constraints (runnable, cannot stop at a proposal), and finally delegate all remaining decision-making power—“I want to see your creation, not just a page that checks boxes.” In practice, the phrase “deliver, not propose” is often the key switch that determines the quality of the output.

2. Before Building: Asset Evaluation and Data Processing

For 3D tasks, the first step is not writing code, but confirming assets. Fortunately, the David statue is a public cultural asset, and museum-grade 3D scan data is available online (distributed in STL format under open licenses). STL is an extremely minimal triangle mesh format: in binary, each triangle occupies a fixed 50 bytes, containing no topology, material, or hierarchy information. Original scans often contain millions of polygons; feeding them directly to a browser will stall both loading and rendering, requiring an offline processing phase first.

A typical processing pipeline looks like this:

1. Mesh Simplification: Use algorithms like Quadric Error Metric (QEM) to reduce the polygon count to a web-friendly level while preserving silhouette features.
2. Retopology: Resample both the raw block (stone cube) and the statue to the same topology to prepare for the subsequent “morph reveal.”
3. Compression and Format Conversion: Convert to a universal 3D transmission format that supports quantization to significantly reduce file size.
4. Material Approximation: The subsurface scattering of marble can only be approximated in a browser. A common approach uses Fresnel highlights, noise maps, and a warm, translucent tint.

Environment evaluation must also be done upfront: the target browser’s WebGL support, mobile bandwidth, and first-screen loading budget all dictate the available choices for the technical route. Asking the model to “first assess what the current environment can do, then proceed autonomously” establishes the right engineering habits for these tasks.

3. Core Interaction: Three Routes for “Chiseling Stone”

The soul of the entire website is the interaction: “hold down a button to chisel, pieces of stone fall off, and David slowly emerges.” There are roughly three implementation routes, each with trade-offs.

Route 1: Morph Target Interpolation (Recommended). Use the retopologized block mesh and the statue mesh as two morph targets. Interpolate vertex positions based on interaction progress, overlay noise displacement to simulate chisel marks, and use a roughness gradient to simulate “rough stone becoming polished marble.” This approach has low performance overhead and offers smooth, controllable transitions, making it the most reliable choice for the web.

Route 2: Runtime Boolean Cutting. Perform a solid cut for each chisel action, dropping realistic fragments. This provides the most “physical” effect, but continuous boolean operations are computationally expensive and numerically unstable in browsers. They can easily break the mesh in edge cases, making this route suitable only for small-scale accents.

Route 3: Shader Reveal. Keep the complete statue mesh and use a group of clipping planes with noise thresholds for fragment discarding. Visually, “the stone disappears, and the statue emerges.” This is the cheapest to implement, but lacking physical debris compromises the sense of immersion.

The optimal engineering approach is often a hybrid: use morph interpolation for the main mesh, an independent particle system for debris, and combine sound effects with slight camera shakes to provide near-tactile feedback. The conceptual code looks roughly like this:

// Conceptual example: Morph interpolation + particle feedback
const morph = { from: loadGeometry('block.glb'), to: loadGeometry('david.glb'), t: 0 };
function onChisel(strength, hitPoint, normal) {
  morph.t = Math.min(1, morph.t + strength);       // Advance reveal progress
  applyDisplacement(morph, noise(hitPoint));       // Chisel mark disturbance
  material.roughness = lerp(1.0, 0.35, morph.t);   // Rough stone -> polished
  spawnDebris(hitPoint, normal);                   // Debris particles
  if (morph.t > 0.92) playFinaleCamera();          // Finale camera movement
}

On the narrative level, there is a brilliant finishing touch: provide an “Undo” button on the interface. When clicked, it returns the message, “Marble has no undo button.” This uses the interaction itself to convey the theme—sculpting is an irreversible art of subtraction; once a cut is made, it cannot be taken back. Good AI output often shines in these details where “form and content annotate each other.”

4. Narrative and Visuals: Same Data, Two Expressions

Giving the same task and scan data to different agents will yield drastically different works. One might take a highly immersive route: opening to a dark room with a marble block standing in the center under a spotlight. The user chisels blow by blow, with the narrative core being “David was what was left in the stone.” Another might take an exhibition reader route: a paper-colored background, divided into four acts, where dragging a slider peels away layers of stone. The pacing is slower, but the information density is higher.

There is no superior route between the two: the former wins in the ritual sense of the experience, while the latter excels in readability and knowledge transfer. This precisely demonstrates that handing over the decision-making for narrative, visuals, interaction, and technical routes to the model doesn’t yield randomness, but rather differentiated answers that human creators might not choose. When evaluating such outputs, focus on “whether the expression fits the theme” rather than scoring against a uniform checklist.

5. Performance and Delivery: Making the Work Truly “Experiential”

The most common failure of 3D websites isn’t poor visual effects, but taking three minutes to load and overheating the user’s phone. Before going live, at least four things must be done:

1. Progressive Loading: Provide a low-poly placeholder on the first screen, and progressively refine it after the user enters the interaction.
2. Size Budget: Establish strict upper limits for quantized and compressed meshes, textures, and code bundles.
3. Frame Rate Budget: Degrade particle counts and post-processing toggles based on device capabilities.
4. Static Deployment: Purely front-end sites like this can be distributed using object storage and a CDN. General cloud products like Baidu AI Cloud’s object storage and CDN acceleration can cover this, requiring no self-built servers.

The delivery standard is simple: a stranger receiving the link should be able to experience the entire thing without reading any instructions.

6. Extension Experiment: From Website to Short Video

Beyond the website, you can have the model create a 60- to 90-second 9:16 vertical short video based on the existing work to convey the site’s essence to a broader audience. The prompt essentials align with the website: judge whether the story is suitable for video expression; allow the reuse of scenes, assets, and code from the website, or reorganize the visuals; delegate narrative, camera work, pacing, and sound entirely to the model; deliver a playable final cut, an editable project, and asset sources; and finally, actually review the video and fix obvious issues.

Two points are worth noting in practice. First, asset reuse significantly reduces production costs and ensures visual consistency; camera movements in a WebGL scene can be slightly rearranged to serve as video storyboards. Second, video generation consumes far more resources than web pages, so quotas must be planned in advance. If necessary, integrate a custom rendering workflow so that engineering capabilities can compensate for fluctuations in generation capabilities.

7. Practical Findings: Five Reusable Lessons

1. Delivery rate on long tasks is the dividing line. Models often “have ideas but fail to make it to delivery.” The more complex the task, the higher the probability of being interrupted by speed, cost, or context limits. New-generation models usually show significant improvements in price and speed, but the engineering solutions remain universal—break down tasks, set checkpoints, and support resuming from breakpoints.
2. The instruction model of “assess the environment first, then proceed autonomously until a runnable work is delivered” is far more effective than listing feature checklists. The former stimulates judgment; the latter only yields a compliant but mediocre page.
3. Real assets determine the upper limit of texture quality. The physical precision brought by museum-grade scan data is unattainable through procedural modeling; public cultural assets are a treasure trove for 3D creation.
4. Human-in-the-loop cannot be omitted. You must watch the video yourself and play with the website yourself. Point out obvious issues and have the model fix them. There is always a round of quality closure after “delivery.”
5. When evaluating AI’s creative capabilities, look at the final experience, not intermediate products. Proposal documents and lines of code prove nothing; only an experience that a real user can complete from start to finish counts.

8. Conclusion

Having an LLM “sculpt” a statue of David appears on the surface to be a fun test, but it is essentially an engineering verification of “whether AI can undertake complete creative work.” The conclusion is cautiously optimistic: with clear goals, sufficient assets, reasonable delivery constraints, and a human quality loop, models can indeed deliver surprising end-to-end works. However, speed, cost, and long-task stability remain key variables for whether such practices can scale. For developers, the most valuable thing to do now is to design the “comprehensive test questions” in their own domains and let the models answer with their works.