Building an LLM-Driven Interactive 3D Narrative Website: How a Statue Is Born from Marble

1. Background and Problem Breakdown

Asking a general-purpose LLM to independently complete “an ambitious creative work” is, in essence, a stress test of the model’s ability to execute long-horizon, multi-stage tasks. The brief called for an interactive website that would help general audiences understand how a classic sculpture is “subtracted” out of raw stone—so that viewers walk away not with a handful of historical facts, but with a genuinely new understanding of what carving itself is.

The brief decomposes into four mutually constraining sub-problems:

1. Narrative angle. A flat recitation of historical facts holds little appeal; the story needs a core metaphor capable of carrying the physical fact of subtractive carving.
2. Visual style. The look must match the narrative temperament—a dark room, a single light source, and a stone texture are the reasonable direction.
3. Interaction. The user must be made to act, rather than passively scroll through a page.
4. Technical route. The site needs genuine 3D geometry data—not pseudo-3D faked with texture tricks.

These four are not independent. For example, choosing a “peel away layer by layer” interaction requires the geometry to be a cuttable mesh rather than a single rendered image; choosing a dark-room visual requires a lighting system that supports spotlights and shadows, which adds extra rendering performance requirements. The rest of this article follows the order of engineering implementation.

2. Narrative Architecture: Making Subtraction the Core Metaphor

Traditional popular-science sites tend to tell an artist’s life through a timeline and explain technique through text and images. The core metaphor chosen here is different: the finished sculpture is “what remains” of the stone block. This reframes sculpture from “creation” to “removal,” which matches the essence of subtractive manufacturing and maps naturally onto interactive geometric-reduction operations.

Around this metaphor, the page is organized into three layers:

• Prologue. A dark room with a complete marble block at the center, lit only by a spotlight from above. The user receives no operating instructions—just one button labeled “Strike the Chisel.”
• Process. Each strike peels away a layer of chips according to preset layering rules, revealing the contour inside. Layer count is tied to geometric precision: the first layers remove a lot and the contour stays vague; the later layers remove less and detail gradually sharpens—mirroring the real carving rhythm of roughing out first and refining later.
• Ending. When the final form is revealed, the page presents an “Undo” button. Clicking it yields the response: “Marble has no undo key.” This is a deliberately anti-interactive design—the interaction itself fails in order to emphasize the irreversibility of subtraction.

The third layer is the crux of the whole narrative. If “irreversibility” is just a line of copy, readers will skim right past it. But when users click deliberately, build an expectation, and are then deliberately frustrated, the cognitive intensity is entirely different. This kind of “negative interaction” must be used sparingly in design—once per site is enough; any more and expression turns into annoyance.

3. Acquiring and Preprocessing the Geometry

Real 3D data is the foundation of this kind of site’s credibility. The public cultural heritage sector has mature open-scanning projects that publish high-precision mesh models of many sculptures and buildings under Creative Commons licenses, permitting reuse under attribution and share-alike terms. This project used a public scan mesh of a classic sculpture as its geometry source and kept the full asset attribution and license statement in the site footer—not as an optional courtesy, but as a basic obligation of using open assets.

The raw mesh then went through three preprocessing steps:

Step 1: Topological simplification. Raw scan meshes are often extremely dense—hundreds of thousands to millions of triangles—and rendering them directly in the browser will overwhelm mid- and low-end devices. Apply a mesh simplification algorithm that preserves contour features while pressing the count into an acceptable range, typically targeting 50,000–150,000 triangles. Pay attention to high-curvature regions (face, hands, drapery folds) during simplification to avoid excessive collapse in those areas.

Step 2: Coordinate normalization. Move the model’s bounding-box center to the origin and scale uniformly to unit size, so that camera and lighting parameters can be reused. Also confirm that the model’s “up” axis matches the rendering engine’s coordinate system, or the statue will end up lying on its back.

Step 3: Layered-cutting precomputation. This is the project’s core data structure. To support “peeling layer by layer,” the volume removed between the raw block and the finished piece must be discretized into layers. Two implementation approaches exist:

• Offline pre-cutting. Pre-cut N stage meshes in a modeling tool, export them as separate files, and load and swap them in order on the frontend. Pros: zero runtime computation. Cons: file size grows linearly with layer count, and transitions between layers look abrupt.
• Runtime clipping. Load both the full raw block and the finished mesh, progressively advance a clipping plane in the shader, and combine it with debris-particle simulation for the peeling effect. Pros: small payload and continuous transitions. Cons: you must cap the exposed cross-section yourself, or viewers will see that the model is hollow inside.

In practice, a hybrid was used: the overall contour advances via the clipping plane, which guarantees smooth transitions, and at the instant of each strike a short burst of debris particles is layered on top, using visual noise to mask the imperfect section capping. The particles are rendered with instancing, kept to a few thousand instances per batch—negligible impact on frame rate.

4. Rendering and Interaction Implementation Notes

4.1 Lighting and Materials

The dark-room atmosphere relies on a minimized three-point lighting setup: one spotlight slightly forward of overhead serves as the key light—high intensity, narrow angle—creating strong contrast between light and shadow; one very weak hemisphere light acts as ambient fill so the dark side doesn’t go pure black and lose its contour; and no global illumination beyond shadow maps, to keep the cost down.

The stone material uses a physically based rendering roughness model, with roughness set between 0.6 and 0.8, plus slight normal perturbation to simulate marble grain. Be careful not to stack strong environmental reflections on top: marble is a predominantly diffuse material, and hot specular highlights make it look like plastic.

// Pseudocode sketch of the clipping-plane advance
const plane = new THREE.Plane(new THREE.Vector3(0, -1, 0), startHeight);
material.clippingPlanes = [plane];
material.clipShadows = true;
function chip() {
  // Each strike advances by a fixed step; the step shrinks near completion
  const step = currentLayer < coarseLayers ? coarseStep : fineStep;
  plane.constant -= step;
  spawnDebrisParticles(plane.constant);
}

4.2 Camera and Controls

The camera is locked to a fixed default view, with only a small range of orbit rotation allowed, and pitch and zoom are clamped. This is a deliberate constraint: with fully free camera control, users spend their attention “playing with the camera” instead of looking at the statue. The center of gravity of the interaction must be singular.

Button triggers need throttling. The strike animation itself takes roughly 400–600 ms, during which the button is grayed out to prevent rapid clicking from making the clipping plane jump and the particles pile up. Details like this are easy to miss in the prototyping stage, but they directly determine how the experience feels in the hand.

4.3 Performance and Degradation

Mobile is a scenario you must cover. In practice, three tiers of degradation were set up:

• When the device pixel ratio is too high, cap the rendering resolution to avoid fill-rate bottlenecks on high-DPI screens.
• When the GPU is weak or the frame rate stays below a threshold, disable shadows and reduce particle counts.
• Provide a static fallback path: if WebGL context creation fails, fall back to a staged sequence of static images—preserving the narrative and the button interaction while sacrificing real-time 3D.

The third tier matters most. Cultural popular-science sites face an extremely wide device distribution; you cannot assume every visitor has a discrete GPU.

5. LLM Capability Boundaries and Engineering Compensation

Back to the original question: how does an LLM actually perform on a project like this?

What it handles well: requirement breakdown, narrative ideation, page-structure planning, most of the frontend code, and asset discovery plus license-information organization. Given a clear constraint (“don’t stop at the proposal stage—deliver a running artifact”), the model can push all the way through to an accessible page and contribute expressive interaction designs such as the “undo button.”

Where it struggles: stability over long chains. A task like this spans research, coding, debugging, and asset processing; a failure at any stage can stall everything downstream. Typical issues observed in practice: the geometry preprocessing script in the model’s first version often carries coordinate-system or unit-mismatch bugs that take several rounds of feedback to converge; and the model’s estimates of rendering performance skew optimistic, often proposing overly high polygon counts or heavy post-processing.

Three engineering compensation strategies are worth generalizing:

1. Force intermediate artifacts to be visible. Require the model to output inspectable intermediate results at every step—such as simplified-mesh statistics or single-frame render screenshots—not just the final deliverable. This exposes errors early and avoids re-running the entire chain.
2. Write performance budgets as hard constraints. Stating a “triangle-count cap,” “target frame rate,” and “first-load size cap” in the prompt works far better than a vague “mind the performance.”
3. Separate generation from acceptance. Let the model explore freely during the generation phase, then gate acceptance with automated checks (Lighthouse-style metrics, polygon-count statistics, console-error capture). Don’t mix the two phases.

6. A Reusable Technical Path

Abstracting one level up from this practice, the general path for building similar “subtractive-process visualization” sites looks like this:

Stage	Key Decision	Common Pitfall
Geometry source	Openly licensed, high-precision scan meshes	Ignoring attribution obligations under the license
Mesh preprocessing	Curvature-aware simplification within a polygon budget	Excessive collapse on faces and hands
Subtractive representation	Clipping-plane advance + debris particles masking the cut section	Missing section capping, producing a “hollow” look
Lighting and material	Single key light + weak ambient; high-roughness stone	Overly strong highlights; unconvincing material
Interaction constraints	Locked camera, throttled button, one single negative interaction	Too many interactions diluting the narrative focus
Compatibility and degradation	Resolution caps, feature toggles, static fallback	Blank screen on mobile

This path is not limited to sculpture. The assembly and disassembly of architectural components, the formation of geological cross-sections, the machining of industrial parts—any process that works by “removing from a solid block of material”—can reuse the same geometry-clipping and layered-narrative framework, swapping only the model and the copy. That is an extra dividend of choosing “subtraction” as the core metaphor: its technical implementation and its narrative structure are isomorphic—swap in a new subject and the whole thing transfers.