3D Generation with LLMs: Recreating the Birth of Michelangelo's David

    Historically, evaluating an LLM's coding ability meant checking if it could write correct functions. However, with 3D spatial understanding and visual orchestration, a more valuable test emerges: can it independently complete an end-to-end creative pipeline from research and narrative design to engineering delivery? This article explores how to use LLMs to recreate the birth of Michelangelo's David in a web experience. It covers task prompt design, 3D asset processing pipelines, rendering techniques for a "subtractive sculpture" effect, interaction paradigms, performance optimization, and cloud deployment. Ultimately, it highlights a shift in the developer's role—from writing code to defining problems and evaluating outcomes.

    1. Background: From Code Generation to Experience Generation

    In the past, evaluating the programming capabilities of Large Language Models (LLMs) mostly depended on whether they could write correct functions or complete a piece of logic. Now that models possess 3D spatial understanding and visual orchestration capabilities, a more valuable evaluation dimension has emerged: given an open-ended prompt, can the model independently complete the full-chain creation process—from asset research and narrative design to interactive implementation and engineering delivery?

    “Recreating the birth of Michelangelo’s David” serves as an ideal technical testing ground for three reasons:

    1. The theme naturally aligns with “subtractive” logic. Michelangelo described his work as “releasing the form already existing inside the stone.” Sculpting is essentially subtraction. This creates a metaphorical isomorphism with 3D rendering techniques like fragment culling, dissolving, and clipping—where the interaction itself embodies the theme.
    2. Assets are accessible and legally licensable. Cultural heritage digitization projects have recently released vast amounts of museum-grade 3D scan data, including high-precision scans of David, mostly under Creative Commons licenses. This provides a legal foundation for derivative creations.
    3. Comprehensive evaluation scope. A webpage demonstrating “a form emerging from stone” involves at least 3D format processing, mesh simplification, shader programming, loading strategies, narrative copywriting, and mobile adaptation. It comprehensively tests the engineering completeness of the model’s delivery.

    2. Prompting as a “Creative Brief”: Task Design for LLMs

    When people ask a model to “make a 3D website,” they often get a templated page mashup. The difference usually lies not in model capability, but in the quality of the prompt. An ideal creative task prompt typically includes five elements:

    1. Goal and Audience: Instead of “make a David statue website,” use “help ordinary people understand how the statue was born from stone”—translating a business goal into a cognitive goal.
    2. Success Criteria: “The audience doesn’t just memorize facts, but gains a new understanding of sculpting and is willing to stop and observe.” Provide a perceivable acceptance standard.
    3. Full Autonomy: Explicitly hand over the narrative angle, visual style, interaction method, and technical approach to the model. Prevent it from retreating into a conservative, checklist-style implementation.
    4. Delivery Constraints: Emphasize “runnable and experienceable, not stopping at the proposal or render stage.” Anchor the output on engineering deliverables rather than a PPT.
    5. Environment Self-Evaluation Prompt: Allow the model to first assess what its current environment can do (searchable, codeable, 3D tool integration) before autonomously proceeding.

    These five principles also apply to complex tasks given to AI coding tools in daily development: Goal-oriented + Full Autonomy + Delivery Anchor. This combination is key to pushing the model from a “code completer” to a “creator.”

    3. 3D Assets: Public Scan Data and Processing Pipeline

    3.1 Asset Sources and Licensing

    Major cultural heritage digitization projects have published high-precision 3D scans of classic sculptures. These generally cover well-known works and are mostly released under Creative Commons licenses (e.g., Attribution-ShareAlike). Note two things when using them: retain attribution information on the page; if derivative works must comply with the ShareAlike clause, verify the license version and scope in advance for commercial use.

    3.2 STL Limitations and Processing Pipeline

    The most common distribution format for sculpture scans is STL—it contains only triangular faces, lacks UV and material information, and records no topology. Loading raw data with millions of faces directly into a browser will crash any device. A standard processing pipeline looks like this:

    1. Raw STL (millions of faces)
    2. → Merge duplicate vertices / Rebuild topology
    3. → Mesh simplification (reduce faces based on visual importance, target 50k~150k faces)
    4. → Recalculate normals, bake Ambient Occlusion maps (bake details into textures to compensate for face reduction)
    5. → Convert to lightweight transmission format and enable mesh compression
    6. → Split into "stone block shell" and "finished statue" meshes

    Splitting into the “stone block shell” and “finished statue” is a key narrative decision: it gives the “subtractive” interaction two clear endpoints, while the intermediate process is handled by interpolation in the rendering layer.

    4. Three Rendering Approaches for “Form Emerging from Stone”

    How do you let users “chisel away stone to reveal David”? There are three mainstream engineering approaches:

    Approach A: Pre-generated Progressive Stages + Cross-fade. Offline, use mesh simplification tools to generate N intermediate forms based on different retention ratios (pure block → rough draft → generally shaped → finished product). At runtime, perform opacity transitions between two adjacent stages based on sculpting progress. Easy to implement, controllable performance, mobile-friendly. The downside is a weaker “peeling” granularity.

    1. // Approach A: Progress-driven stage cross-fade
    2. const stages = [block, rough, refined, statue];
    3. function updateReveal(p) { // p ∈ [0, 1]
    4. const n = stages.length - 1;
    5. const i = Math.min(Math.floor(p * n), n - 1);
    6. const t = p * n - i;
    7. stages.forEach((s, k) => {
    8. s.visible = (k === i || k === i + 1);
    9. s.material.opacity = (k === i) ? 1 - t : t;
    10. });
    11. }

    Approach B: Noise Dissolve Shader. Use 3D fractal noise to control fragment culling, with sculpting progress as a uniform threshold: fragments with noise values lower than the threshold are discarded. Add a highlight ring near the threshold to simulate chisel marks catching the light. Extremely low overhead, visually closest to “debris peeling.” Ideal as a surface overlay on Approach A.

    1. // Approach B: Fragment dissolve + chisel mark highlight
    2. uniform float uProgress; // 0=complete stone, 1=statue fully revealed
    3. vec3 noise = texture(uNoiseTex, vLocalPos * 0.08).rgb;
    4. float th = dot(noise, vec3(0.34));
    5. if (uProgress > th) discard; // chisel away
    6. float edge = smoothstep(th - 0.06, th, uProgress);
    7. vec3 col = mix(marbleColor, highlight, edge * 0.7); // chisel mark lighting

    Approach C: Runtime Boolean Operations (CSG). Geometric clipping based on actual chisel trajectory. Highest precision, but runtime boolean operations on complex meshes in the browser are costly and prone to topological degradation. Generally only used for offline pre-computation, not recommended for the main interactive loop.

    In practice, a common combination is A + B: stage meshes handle “gradual form appearance,” the dissolve shader handles “surface peeling,” and a particle system simulates falling debris. When holding the chisel button, progress drives the uniform, visually creating the effect of “layers of stone fading away, the figure slowly emerging.”

    5. Interaction and Narrative: Trade-offs Between Paradigms

    The same scan data and subtractive rendering base can grow completely different narrative shells. Two representative paradigms suit different scenarios:

    • Immersive Dark Room: Starts in a dark room with a marble block in the center. Hold the button to chisel, debris falls, the figure emerges. The theme is conveyed through first-person “tactile” feel. Strong metaphor, high emotional density; but low information density. A noteworthy detail in this paradigm: the interface provides an “Undo” button, but clicking it returns the message, “Marble has no undo button”—using violated expectations to drive the theme of “irreversible sculpting” into memory. This is an advanced use of interaction copy: letting the interaction mechanism itself participate in the narrative, rather than acting as decoration.
    • Exhibition Reader Style: Paper-colored background, act-by-act progression. A slider controls the stone block subtracting layer by layer to the finished product, pacing like flipping through an exhibition booklet. Clear information delivery, low cognitive load, friendly to low-performance devices; but weaker immersion.

    Selection advice: Choose immersive for “shock and virality,” reader-style for “education and explanation.” Mix them if conditions allow—use the dark room as a prologue, and the reader style for the main explanation. Notably, two seemingly different works share the same underlying model data and “progress-driven subtractive rendering.” The differences exist entirely in the presentation layer. This suggests that when AI generates front-ends and the technical base converges, evaluation should focus on narrative and interaction design.

    6. Performance and Experience Optimization Checklist

    The reputation of a 3D webpage often depends on details. Check item by item before delivery:

    • Resource Budget: Set limits for first-screen and total size (e.g., first-screen resources under a few MB). Scanned models must be decimated and compressed before going live.
    • Progressive Loading: Show the low-poly stone block and prologue text first, turning load wait time into part of the narrative. Stream the high-poly statue in the background.
    • Render Throttling: Only redraw when progress changes or the camera moves. Pause the render loop when the page is not visible.
    • Mobile Adaptation: Clamp devicePixelRatio, downgrade shadows and anti-aliasing, ensure adequate touch target sizes.
    • Memory Management: Release idle geometries and materials promptly after stage transitions to prevent memory bloat during long sessions.
    • Accessibility & Preferences: Provide keyboard-accessible operation paths. Respect the system’s “Reduce Motion” preference.
    • License Compliance: Clearly mark model sources, license agreements, and attribution information on the page.

    7. Cloud Deployment and Engineering Finalization

    Such works are typical static heavy front-ends. Cloud delivery is not complex: host static resources (models, textures, scripts) on object storage, use a Content Delivery Network (CDN) for edge acceleration, and enable compressed transmission. If you need lightweight backend capabilities like access analytics or sharing codes, deploy a small stateless service on a container platform. Integrate logging services and monitoring alerts to bring load times, render frame rates, and error rates into observability. Taking Baidu AI Cloud as an example, the aforementioned capabilities have corresponding product categories that can be directly combined, typically completing the loop from local prototype to publicly accessible delivery within half a day.

    8. Methodology Precipitation: The Shift in Developer Roles

    Looking back at the entire process, the LLM handled the majority of execution work: asset research, code implementation, and visual orchestration. Human value is concentrated in three areas: defining a good prompt (cognitive goals and success criteria), holding the engineering baseline (performance budget, license compliance, accessibility), and calibrating expression quality (whether narrative metaphors hold, whether interaction copy participates in the theme).

    When “from prompt to runnable work” can be handed to a model in one step, the ruler measuring developer efficiency is shifting from “how much code was written” to “the ability to define problems and accept results.” This is perhaps the biggest inspiration from this 3D practice: the stronger the tool, the more valuable the prompt.