Building a 3D Storytelling Website: A Hands-On Test from Raw Stone to Interactive Experience

1. Background: When Generative Development Meets 3D Storytelling

The capability boundary of generative development tools is expanding from “writing a snippet of code” to “delivering a finished, runnable product.” When a task grows from a single-file script into a multi-stage project—one that involves research, asset acquisition, 3D rendering, interaction design, and deployment—the challenge is no longer syntactic correctness but engineering judgment: Can the model assess what the environment actually supports? Can it weigh narrative goals against implementation constraints? Can it push a half-finished artifact to a state people can genuinely experience?

This test was built around a representative brief: create a Chinese-language interactive website that explains to a general audience how a classic sculpture is born from a block of stone. The goal was not to enumerate historical facts, but to give visitors a new understanding of what carving actually means—and to make them want to stop and look at the sculpture itself. Narrative angle, visual style, interaction approach, and technical route were all left open, to be decided by the executing agent.

The difficulty lies in how open-ended the brief is. There is no checklist of acceptance criteria, no prescribed tech stack, and no ready-made visual guidelines. What it tests is the entire chain from topic understanding to technical delivery.

2. Narrative Design: Making “Subtraction” Perceptible Through Interaction

2.1 Choosing the Core Metaphor

Carving is, at its core, a subtractive process: material is progressively removed from a solid block until the form emerges. This maps naturally onto an interaction metaphor—each “chisel strike” a visitor performs flakes away another layer of stone, gradually revealing the subject.

Two distinct narrative routes grew out of this metaphor:

• Immersive dark-room route: a dark scene with a stone model at its center. Visitors press and hold a button to keep chiseling; the stone sheds layer after layer and the form slowly appears. The atmosphere emphasizes presence, placing visitors at the carving site.
• Exhibition-reader route: a light, paper-like background divides the process into several acts. A slider controls how much stone has been removed, transitioning from a full block to the final form. The pacing resembles an interactive exhibition guide.

Both routes share the same real 3D scan as their asset foundation; they differ in narrative density and interaction granularity. The former emphasizes the physical feel of continuous operation, while the latter emphasizes stage-by-stage comparison and observation.

2.2 A Piece of Copy Worth Highlighting

One detail in the immersive route deserves a closer look: the interface offers an “Undo” button, but tapping it returns a single message—the stone has no undo. This is an attempt to turn an interaction limitation into narrative expression: the irreversibility of a subtractive process is felt directly through a refused action. Rather than writing a paragraph explaining that “carving cannot be undone,” the design lets visitors absorb that idea through the operation itself.

From an engineering perspective, this points to a broader principle: interaction feedback does not always have to comply with the user. A meaningful refusal is equally valid feedback design.

3. Assets and 3D Asset Processing

3.1 The Value and Cost of a Real Scanned Model

Both builds used the same publicly available 3D scan as their geometric base, sourced from an open cultural heritage scanning project under its corresponding open license. Using a real scan instead of hand-modeled geometry brings two immediate benefits:

1. Shape accuracy: the sculpture’s proportions, drapery folds, and anatomical details are preserved—what visitors see is the work itself.
2. Credibility: the narrative rests on real data rather than a schematic illustration.

The cost is just as obvious. Raw scans typically exceed a sensible polygon budget for real-time web rendering by a wide margin; loading them directly means long first-screen times and frame-rate collapse on mobile. Asset processing is therefore a step this kind of project cannot skip.

3.2 A Lightweight Processing Pipeline

A typical web-oriented 3D asset pipeline looks like this:

Raw scanned model (high polygon count)
   │
   ├─ Mesh cleanup: remove floating fragments, repair non-manifold edges
   ├─ Polygon reduction: set a face-count budget per target platform
   ├─ Normal baking: bake high-poly detail into the low-poly normal map
   ├─ UV repacking and texture compression
   └─ Export to a web-friendly format (e.g., glTF / binary buffers)

Key parameters to watch:

• Polygon budget: desktop can handle on the order of hundreds of thousands of triangles; mobile should stay well below that. Actual values depend on scene complexity and should be confirmed by testing on target devices.
• Geometry compression: a general-purpose mesh compression extension can significantly cut transfer size. Decoding happens on the client, so weigh decode time against the first-screen experience.
• Progressive loading: load a low-resolution version for the first screen, then swap in the high-resolution version in the background to avoid a blank-screen wait.
• Texture strategy: let the normal map carry most of the surface detail; base-color maps can drop to lower resolutions, and compressed texture formats should be used throughout.

3.3 Two Ways to Implement the Subtractive Effect

There are two common paths to the “stone flaking away layer by layer” effect:

Path 1: clip-plane-based segmented visibility. A movable clipping plane slices the model; geometry below the plane is cut away, creating the impression of chiseled-off material. It is simple to implement and cheap to run, but the cut surface reads as a flat, clean plane, lacking the texture of broken stone.

Path 2: fragmentation driven by geometry shaders or vertex displacement. The model surface is divided into regions that progressively shift outward and fade out as the operation progresses, simulating flakes peeling away. This looks much closer to a real chisel strike, but it requires additional fragment geometry and more complex shading logic, at a higher performance cost.

In practice, a compromise is common: keep the clipping approach for the main body to guarantee stable frame rates, then overlay procedural noise and particle effects along the cut edge to soften the flat plane. The particle system handles the “flying debris,” trading a small performance cost for a clearly visible gain in texture.

// Simplified illustration of clipping and edge perturbation (pseudocode)
float cut = smoothstep(cutPlaneMin, cutPlaneMax, worldPos.y);
float noise = fbm(worldPos.xz * 8.0) * 0.06;
float alpha = step(cut - noise, 0.5);
if (alpha < 0.5) discard;

4. Frontend Interaction and State Management

4.1 The Interaction State Machine

A “press and hold to chisel” operation needs a clear state machine to prevent render jitter or inconsistent state caused by repeated triggers:

Idle ──press──▶ Chiseling ──progress +1──▶ Chiseling
                  │
                  ├──release──▶ Idle (progress retained)
                  ├──progress cap reached──▶ Revealed (final state)
                  └──undo triggered──▶ Rejected (message shown, back to Idle)

Key design points:

• Progress throttling: the render loop and the operation progress are decoupled. Input only updates the progress value; the render side reads it once per frame, so high-frequency events never drive geometry updates directly.
• Irreversibility lock: once the final state is reached, operation entry points are locked, while free rotation of the view is preserved so visitors can keep examining the finished piece.
• Interruption recovery: progress is retained when the button is released. This matches the real rhythm of “chisel, pause, chisel” and lowers the cost of accidental inputs.

4.2 Balancing Performance and Experience

Performance optimization for real-time 3D scenes follows well-established best practices:

• On-demand render loop: reduce the update frequency when there is no interaction, cutting background power draw.
• Lazy resource loading: textures and sounds not needed for the first screen load later.
• Device capability detection: dynamically cap pixel ratio and shadow quality based on hardware capability and screen resolution.
• Fallback strategy: if the rendering context fails to initialize or the frame rate stays persistently low, switch to a static image sequence or video so the content remains accessible.

5. From Website to Short Video: Reusing One Narrative Across Media

After the website was delivered, the next task was to produce a roughly one-to-one-and-a-half-minute vertical Chinese short video, based on the finished work and the research behind it, that explains the essence of the sculpture to a general audience and sparks interest in learning more.

This step is really a test of asset reuse: the 3D scenes, camera angles, copy, and color palette accumulated during the website phase can carry over into the video storyboard. Common approaches include:

• Reusing the 3D scene to record push-in shots of key viewpoints, avoiding duplicate modeling.
• Reusing highlight moments from the interaction—such as the last shard of stone falling away, or the form fully revealed—as the video’s climax.
• Reusing the validated narrative structure, compressed into three or four beats: starting point (the stone) — process (removal) — turning point (irreversibility) — result (the finished sculpture).

The engineering prerequisite for cross-media reuse is disciplined asset organization: 3D scenes, camera parameters, and copy should be stored separately so they can be recombined across deliverables, rather than being coupled to a single page’s logic.

6. Engineering Findings from the Test

6.1 Having Ideas Is Not the Same as Delivering

In multi-stage tasks, models often produce reasonable plans and correct local implementations, yet stall midway through a long chain: assets downloaded but not wired into the scene, the scene running but the interaction unfinished, the interaction working but with no performance fallback. The core difference in delivery capability is not the quality of any single piece of code—it is the ability to keep converging, where every step moves toward “runnable and experiential” instead of endlessly opening new branches.

6.2 Trade-offs Between Cost and Speed

Multi-stage tasks are sensitive to call volume and duration. Stronger reasoning usually comes with higher per-call cost and longer response times, and both are amplified during the iterative asset processing and debugging phases. In real projects, a common strategy is tiered usage: strong reasoning configurations for hard decisions, lighter configurations for repetitive code edits and asset housekeeping, keeping the overall cost curve under control.

6.3 Assess the Environment Before Writing Code

At the start of an open-ended brief, evaluating what the current environment can do is the critical first step. The available toolchain, network access, rendering environment, and deployment channel—any missing piece changes the technical route. Skipping the assessment and writing code directly tends to surface every problem at once during integration.

6.4 Actually Watch the Final Video

Once a video is produced, it must be played back and checked: Is the first frame black? Do subtitles overflow their bounds? Are audio and video in sync? Is the vertical safe area cropped? None of these issues show up in engineering logs; they can only be caught by watching.

7. A Reusable Practice Checklist

For developers bringing 3D storytelling to the web, the following checklist may help:

1. Choose the metaphor before the technology. The interaction metaphor determines the implementation path. First clarify “what action will help visitors understand the theme,” then pick a rendering approach.
2. Front-load the asset pipeline. Finish mesh cleanup, decimation, baking, and compression before writing page logic to avoid rework later.
3. Decouple progress from rendering. Input events only update state; rendering consumes state once per frame. This keeps things stable under high-frequency operations.
4. Design meaningful refusals. Constraints such as irreversibility can become narrative expression rather than plain error messages.
5. Prepare a fallback path. 3D rendering is unreliable on some devices; a static fallback ensures the content is always reachable.
6. Organize assets for reuse. Keep scenes, cameras, and copy separate, leaving room for later videos, articles, and other derivative formats.
7. Use “experiencable” as the acceptance standard. Don’t stop at “the code is finished.” Finish when others can open it, operate it, and understand it.

8. Closing Thoughts

The conclusion of this test can be condensed into a single sentence: the difficulty of a 3D storytelling website lies not in any single point, but in the completeness of the chain. From topic understanding to metaphor design, from optimizing real scanned assets to building the interaction state machine, from performance fallbacks to cross-media reuse, every link calls for engineering judgment rather than template application. For developers, the capability truly worth building is a methodology for reliably converging an open-ended brief into a runnable product. For tools, the evaluation standard should shift from “can it generate code” to “can it complete the delivery.”