Building a 3D Narrative Website with Large Models: From Raw Stone to Michelangelo's David

    This article walks through an end-to-end experiment in using large language models to design and deliver a working 3D interactive website that explains how Michelangelo's David emerged from a marble block. It covers prompt design, WebGL carving interactions, 3D asset preparation, performance optimization, and a website-to-video content pipeline.

    1. Experiment Setup: Handing Narrative, Visuals, Interaction, and Technology to the Model

    After the latest generation of large models began advertising stronger 3D and coding capabilities, I designed an ambitious creative task: build a Chinese-language interactive website that helps a general audience understand how Michelangelo’s David emerged from a block of stone. The goal was not just to leave visitors with a few historical facts, but to change how they think about carving itself and make them want to stop and observe the sculpture.

    The prompt was deliberately open-ended. Narrative angle, visual style, interaction design, and technical approach were all left to the model. I set only two hard requirements: first evaluate what was feasible in the current environment, then proceed autonomously until delivering a runnable, experienceable work. The model was not allowed to stop at proposals or mockups.

    I chose David for three technical reasons:

    • The craft metaphor maps naturally onto rendering techniques: subtractive sculpture corresponds directly to “peeling away” or “dissolving” effects that are easy to implement in real-time rendering and visually striking.
    • Zero-cost source material: David is one of the most thoroughly digitized cultural artifacts in the world, with publicly available high-precision 3D scan models under open licenses.
    • A controllable narrative structure: a single subject and single scene keep engineering complexity low, allowing computing power to be concentrated on expressiveness.

    2. Prompt Design: A Four-Layer Structure That Lets the Model Create

    Looking back at the experiment, the task prompt can be abstracted into four layers. This works as a general framework for giving open-ended creative tasks to AI coding tools:

    1. Goal layer: state the creative intent and audience (“help a general audience understand what carving is”) rather than listing features.
    2. Authorization layer: explicitly say “narrative, visual, interaction, and technical direction are up to you,” giving the model real decision-making room.
    3. Constraint layer: define the deliverable format (a runnable, experienceable finished product) and grant tool access (searching for references, finding assets, writing code, using 3D tools).
    4. Acceptance layer: explicitly define anti-patterns: “do not stop at a proposal or mockup” and “I want to see your creation, not a page that merely satisfies a checklist.”

    The acceptance layer is the easiest to overlook, yet the most important. Large models default to producing “safe intermediate artifacts” such as proposal documents, design drafts, or technical selection notes. Only by explicitly forbidding intermediate states can you push the generation process toward a complete deliverable.

    3. Technical Breakdown: How the Carving Interaction Works

    The experiment produced two approaches. One was an immersive dark room: the page opens into a dimly lit space with a marble block standing in the center. The user holds down a button to strike with a chisel, and pieces of stone break away until the sculpture gradually emerges. The other was an exhibition-style reading experience: a paper-toned background, chapter-based narrative, and a slider that lets users observe the stone being reduced layer by layer from a rough block into the finished form.

    The latter is essentially shape interpolation: applying subtractive deformation to a mesh with consistent topology, with the slider mapping to deformation progress. The former is closer to a game-like physical metaphor, typically implemented with a “shell-core” dual-mesh structure:

    1. // Pseudocode: core structure of the carving interaction
    2. const david = await loadModel('david.glb'); // Inner layer: high-resolution scanned sculpture
    3. const shell = buildShell(david, { noise: 0.2 }); // Outer layer: procedurally generated stone shell
    4. onPointerDown(ray => {
    5. const hit = raycast(shell, ray); // Raycast to find the chisel impact point
    6. if (hit) {
    7. carve(shell, hit.point, 0.05); // Dissolve the shell around the impact point
    8. spawnFragments(hit.point, 30); // Spawn debris particles
    9. playHammerSfx(); // Hammer sound feedback
    10. }
    11. });

    Shell dissolution is usually implemented in the fragment shader with a noise threshold. World-space coordinates are sampled against a noise function, and fragments below the current carving progress are discarded. A particle system adds flying debris, creating the visual impression of stone falling away piece by piece.

    One interaction detail deserves attention from anyone building narrative websites: the page includes an “Undo” button. Clicking it triggers the message “Marble has no undo.” The copy forms an intertextual relationship with the theme, turning the interaction itself into part of the narrative with a single line. This kind of narrative consistency is exactly what checklist-driven development rarely produces.

    4. Assets and Licensing: Using 3D Scan Data Correctly

    The experiment used publicly available cultural heritage 3D scan models distributed under Creative Commons Attribution-ShareAlike (CC BY-SA) licenses. Working with such assets requires three disciplines:

    • Attribution: clearly credit the source and license on the page.
    • ShareAlike: derivative works must use the same open license.
    • Format conversion: raw scans are often STL files containing only geometry, with no materials or UVs. They need to be converted to glTF/GLB and assigned baked or PBR materials to achieve the look of marble in WebGL.

    STL is a bare collection of triangular faces. Files are large and lack spatial structure, so loading them directly is slow and wasteful. The standard pipeline is to first reduce the polygon count from hundreds of thousands of faces down to a level browsers can handle smoothly, then bake high-poly detail into normal maps, and finally apply mesh compression. This often reduces file size by an order of magnitude.

    5. Performance Optimization: Making High-Resolution Scans Run in the Browser

    • Level-of-detail loading (LOD): use a low-poly placeholder on first paint, then stream in the high-poly model once interaction begins.
    • Compression and decimation: keep the triangle count within roughly one hundred thousand, combined with mesh compression for transfer.
    • Batching and instancing: render debris particles with instancing to avoid thousands of draw calls tanking the frame rate.
    • Mobile degradation: automatically adjust particle counts and rendering resolution based on device capability.

    For a production launch, static assets can be hosted on object storage and distributed through a CDN. These are standard cloud infrastructure services offered by major providers, so there is no need to build them from scratch.

    6. From Website to Short Video: A Multimodal Content Pipeline

    After the website was complete, the second task was to have the model create a 60–90 second Chinese vertical video (9:16) based on the existing site and research, conveying the essence of the project to a broad audience. The prompt structure mirrored the website task: determine whether the story suits video, reuse website assets where possible or recompose scenes as needed, deliver a playable MP4 and an editable project file, and actually review the output to fix obvious issues.

    In practice, a 3D website is a natural video asset library. Recording the carving interaction and rendering a few close-up shots offline with different camera parameters is enough to support an explainer-style short video. This website-to-assets-to-video reuse chain is far more stable than generating video from scratch.

    7. Practical Findings: Capability, Cost, and Delivery Completeness

    1. Having ideas is not the same as being able to deliver. The model can produce striking creative directions, but without explicit acceptance criteria and a self-checking loop, implementation tends to collapse. The solution is to break large tasks into verifiable milestones, requiring each step to be runnable rather than merely describable.
    2. Cost and latency are real constraints. The previous flagship model was capable but slow and expensive. The new generation maintains capability while cutting invocation costs by roughly half and noticeably improving speed. A sensible approach is model routing: assign creative ideation and architectural decisions to a strong model, and repetitive fixes and debugging to a lighter one.
    3. Evaluate AI output by its “sense of craft,” not a checklist. Among narrative, visual, interaction, and technical dimensions, narrative is the hardest to evaluate automatically. Details like “marble has no undo” mark the boundary between human and machine creation.

    8. Conclusion

    The value of this experiment lies not in any single generation result, but in validating a path: when a task prompt simultaneously provides clear goals, sufficient authorization, and strict acceptance criteria, a large model can deliver an end-to-end 3D work with narrative, interactivity, and engineering quality. For developers, the real threshold is shifting from “writing every line of rendering and interaction code by hand” to “designing tasks that give AI the confidence to create.”