Building a 3D Website with LLMs: Making Michelangelo's David Emerge from Marble

    This article explores how to use large language models to build an interactive 3D website that lets visitors "carve" Michelangelo's David out of a marble block. It covers the task-design principles behind a well-scoped creative commission, the technical pipeline for preparing million-polygon scan data for real-time web rendering, CSG-based boolean subtraction for chisel interactions, two contrasting narrative approaches built on shared assets, deployment and delivery considerations, and practical lessons on model tiering, milestone-based delivery, and cost management.

    1. Why “Carve a David” Is a Good Test for AI: Designing a Commission-Style Task

    To genuinely evaluate a large model’s abilities in 3D visualization, front-end engineering, and narrative organization, simple Q&A or single-page demos offer limited discrimination. A more valuable litmus test is a creative task with an open-ended goal but clear delivery standards: build a Chinese-language interactive website that helps ordinary readers understand how Michelangelo’s David was born from a block of marble.

    The prompt design itself deserves closer examination than the task:

    • Goal layer: Not to popularize facts, but to give the audience a new understanding of the act of “carving” and make them willing to pause and observe. This elevates the work from a “science page” to “experience design.”
    • Audience layer: Aimed at ordinary readers with no art history background—the comprehension barrier must be zero.
    • Autonomy layer: Narrative angle, visual style, interaction method, and technical approach are all delegated to the model. This is the key to testing planning ability—only by not specifying a solution can you see the model’s own aesthetics and judgment.
    • Delivery layer: First assess what the current environment can do, then push forward autonomously until a runnable, experienceable work is delivered. Stopping at a proposal or mockup stage is explicitly forbidden.
    • Constraint layer: Use only copyright-compliant assets and note their sources in the work.

    A reusable prompt template looks like this:

    1. [Goal] Build a Chinese-language interactive website that helps
    2. ordinary readers understand how the statue of David
    3. "emerges" from a block of stone
    4. [Audience] Ordinary readers with no art history background
    5. [Expectation] After viewing, they gain a new understanding of
    6. "carving" itself and are willing to pause and observe the
    7. work—rather than memorizing a few facts
    8. [Autonomy] Narrative angle, visual style, interaction method, and
    9. technical approach are yours to decide
    10. [Delivery] First assess what the current environment can do, then
    11. push forward autonomously until a runnable, experienceable
    12. work is delivered; do not stop at a proposal or mockup stage
    13. [Constraints] Use only copyright-compliant assets and note sources
    14. and licensing in the work

    The value of this “commission-style” structure lies in transferring judgment about “how to do it” to the executor while retaining hard constraints on “what counts as done.” In practice, it effectively filters out the common failure mode of “replying with a grand plan but never writing code.”

    2. Technical Route: How the 3D Interactive Website Was Built

    Reverse-engineering the implementation from the finished product reveals a fairly representative technical route, which can be unpacked layer by layer.

    1. Asset selection: Use scan files, not hand-modeling

    For a real-world object like David, the most reliable route is not to have the model “model from memory”—proportions will inevitably be distorted—but to use publicly released 3D scan files of classical sculptures (STL and other common formats). Such files are typically provided by public cultural institutions or open communities under open licenses (the asset used in this case falls under an attribution–share-alike license, requiring source credit and derivative works shared under the same license). Choosing the right licensed asset is both a compliance requirement and an engineering decision: scan data brings precise proportions and detail.

    2. Preprocessing pipeline: Trimming scan data to a real-time web rendering budget

    Scan files often have millions of polygons; direct loading will inevitably cause stuttering. Standard preprocessing includes:

    • Mesh decimation: Reduce polygon count while preserving contour features;
    • Geometry compression: Compress vertex data to reduce initial load size;
    • Alignment and normalization: Unify axes, center, compute bounding box;
    • Progressive loading: Load a low-precision model first, with details streaming in batches, using a placeholder during loading.

    3. Core interaction: Simulating “chiseling” with CSG boolean subtraction

    The most interesting mechanism on the site is “carving the statue out of the stone.” Its core algorithm is Constructive Solid Geometry (CSG): the stone’s initial state is a rectangular box enclosing the statue, and each “chisel strike” performs a boolean subtraction between the stone and a sphere at the ray hit point:

    1. // Pseudocode: core loop of the "chisel" interaction (engine-agnostic)
    2. const statue = await loadMesh('david_scan.stl'); // scan model, open license
    3. const block = createBox(statue.boundingBox); // initial stone: enclosing box
    4. let exposed = 0;
    5. canvas.addEventListener('pointerdown', () => chiseling = true);
    6. canvas.addEventListener('pointermove', (e) => {
    7. if (!chiseling) return;
    8. const hit = raycast(e, block); // raycast to find chisel point on stone surface
    9. if (!hit) return;
    10. block = csgSubtract(block, sphere(hit.point, R)); // boolean subtraction: chip away a piece
    11. spawnParticles(hit.point); // debris particles fly, reinforcing "sense of cost"
    12. exposed = estimateExposure(statue, block); // estimate statue exposure ratio
    13. if (exposed > 0.9) crossFade(block, statue); // above threshold: cross-fade to fine model
    14. });

    A noteworthy engineering detail: high-precision CSG on millions of polygons is impractical, so finished products generally adopt a “coarse chisel + fine reveal” strategy—early stages perform boolean subtraction only on low-precision proxy geometry, paired with debris particle effects; when the exposure ratio exceeds a threshold, they cross-fade to a preprocessed fine scan model. What the user perceives is a continuous “carving” experience, while rendering costs stay within budget.

    4. Two narrative forms: Same assets, two expressions

    Two finished products under the same prompt provide a valuable comparison:

    • Experiential route: A stone block stands in a dark room; hold a button to chisel, debris peels off, the statue gradually emerges. The emphasis is on the ritual sense of “time cost”—you must continuously invest attention to “earn” the work;
    • Exhibition-style route: Paper-colored background, chapter-based structure, drag a slider to observe the stone’s subtractive process from block to finished work. The emphasis is on information density and pacing control, more like an operable exhibition reader.

    Both routes share the same 3D assets and preprocessing pipeline; the difference lies only in information organization and interaction metaphor. This shows that decoupling assets from narrative is a fundamental skill in 3D web engineering; when commissioning AI, you can also split “asset pipeline” and “narrative expression” into two parallel workflows.

    3. Narrative Detail: What an “Undo Button” Teaches Us

    One of the most striking design details in the finished product: the page offers an “undo” button, but clicking it displays “Marble has no undo key.”

    Look closely and you’ll find three layers of intent:

    1. Interaction semantics intertextual with theme. Sculpture is a subtractive, irreversible art; an undo button that “can’t undo even when pressed” restates the theme in the language of interaction—more effective than ten paragraphs of explanatory text;
    2. Restraint beats accumulation. The site doesn’t chase information density; each screen has only one focal point, returning the time to “pause and observe” to the reader—echoing the original expectation in the prompt;
    3. Feedback creates a sense of cost. Particle splashes, sound effects, and slight vibrations when debris peels off make the act of “chiseling” physically perceptible. Interaction with cost gives the work weight.

    The generalizable methodology: when reviewing an AI-generated website, don’t just ask “are the features complete”—ask “is the interaction semantics intertextual with the theme.” The former is a checklist; the latter is design.

    4. From Website to Short Video: Repurposing the Same Assets

    After the website is delivered, the same assets can support a second form: based on the completed website and materials, create a 60–90 second Chinese short video for mass distribution on vertical-screen channels. The task prompt can also be templated:

    1. [Input] The completed website and its research materials
    2. [Goal] Create a 60–90 second Chinese short video to help the
    3. general public quickly understand the essence of the
    4. website and develop interest in learning more about the
    5. statue
    6. [Autonomy] Judge how the story suits video expression; narrative,
    7. shots, pacing, sound, and visual approach are yours to
    8. decide; you may reuse scenes and code from the website
    9. [Delivery] A playable 9:16 MP4, an editable project, and an
    10. asset source list; actually inspect the final cut and fix
    11. obvious issues such as black frames, subtitle misalignment,
    12. and audio-video drift

    Key engineering points for this stage:

    • A short video is essentially “putting the website narrative on a timeline”: storyboard script → voiceover copy → screen recording and motion effects → final composite output. Reusing the website’s scenes, code, and assets can greatly reduce production cost while maintaining information consistency;
    • “Actually inspect the final cut” must be explicitly written into the task. Otherwise, the model easily stops at a “generated” state, and issues like black frames, subtitle misalignment, and audio-video desync won’t be proactively fixed;
    • Deliverables must include an editable project and an asset source list, making the final cut maintainable and assets traceable—the same standard as software delivery;
    • In testing, if a custom video production workflow (skill) is configured for the model, final cut quality can be further improved; but video generation consumes quotas heavily, requiring advance budget and schedule planning.

    5. Hands-On Findings: The Triangle of Capability, Speed, and Cost

    After hands-on work, several reusable engineering judgments emerge:

    1. Tier models by role: flagship sets the skeleton, cost-effective versions flesh it out. The strongest model version in a given generation is often slow and expensive, while newer versions typically bring significantly lower cost and noticeably higher speed. A reasonable strategy: use the flagship model to lock down architecture, core interactions, and key aesthetics; use cost-effective versions for detail iterations, copy polishing, and batch minor fixes.

    2. The most common failure mode is “has ideas, but doesn’t make it to delivery.” Long tasks in a single session easily hit quota exhaustion, context overflow, and mid-task truncation; in testing, tasks were interrupted halfway through. Three countermeasures:

    • Milestone-based delivery: environment assessment → runnable MVP → feature enhancement → experience polish, with a runnable version persisted at each stage;
    • Breakpoint continuation: require the model to persist code and state so a new session resumes from the last milestone rather than starting over;
    • Assess the environment before acting: have the model first inventory what the current environment can do (network, available tools, compute) before pushing forward autonomously, reducing idle spinning based on assumed environments.

    3. Budget awareness must be written into the prompt. Video generation, 3D previews, and multi-round self-checks are major consumers; explicitly writing “budget ceiling and priorities” into the task significantly improves completion rates.

    6. Deployment and Delivery: A Minimal Cloud Closed Loop

    A 3D interactive website is essentially “a static site + large model files,” so the delivery loop isn’t complex:

    1. Hosting: Upload build artifacts to object storage and enable static website hosting;
    2. Acceleration: Distribute via CDN, with model files using progressive loading and chunked requests to avoid first-screen blocking;
    3. Observability: Integrate log services and monitoring alerts to observe request success rates, first-screen latency, and load failure rates;
    4. Compliance: Note asset sources and license information in the page’s “About” section—attribution–share-alike licenses require source credit and same-license sharing.

    Using Baidu AI Cloud as an example, the above loop can be completed with “object storage + CDN acceleration + monitoring alerts.” Major cloud providers have equivalent capabilities, and the process migrates directly.

    Before final delivery, check against a list:

    • Website is runnable and interactive, compatible with mainstream browsers
    • First-screen load time and rendering frame rate meet targets
    • Asset sources and licensing information fully noted
    • Short video MP4, editable project, and asset list all present
    • Production environment accessible, monitoring alerts configured

    7. Conclusion: Treat AI as a “Commissioned Creative Party”

    Looking back at the whole process, what’s truly reusable isn’t a specific website but a task methodology: goal, audience, expectation, autonomy, delivery, constraints—six elements forming a complete “commission.” A goal-oriented prompt lets the model bring real planning and judgment, while hard delivery standards keep it from stopping at the “mockup stage.”

    For developers, the more important role shift than tools is: from someone who writes code personally to a producer and art director for AI—defining “what counts as good,” reviewing “whether semantics are intertextual with the theme,” and guarding “compliance and delivery baselines.” The 3D narrative website is an excellent litmus test for a model’s comprehensive ability, because it simultaneously examines code, aesthetics, narrative, and engineering completeness. Next time you want to verify a model’s true level, find a topic you genuinely care about and give it the same kind of “commission.”