Building 3D Interactive Narratives with LLMs: From Raw Stone to David

1. From a Prompt to an Experiential 3D Website

Using an LLM with code generation capabilities to independently build a “runnable, experiential” 3D interactive website from a natural language description is entirely feasible today. However, the real question is not whether it can be done, but whether the output is engineering-deliverable.

Consider a typical experimental scenario: instructing the model to create an interactive website that explains to a general audience how a classic sculpture is born from a raw block of stone. The constraints dictate that the narrative perspective, visual style, interaction methods, and technical roadmap are all decided by the model. Crucially, it must deliver a runnable product, not just a proposal or a mockup.

This task superficially looks like “building a webpage,” but it actually tests four capabilities simultaneously:

• Narrative Design: Can it translate the abstract concept of “subtractive creation” into a perceptible interactive metaphor?
• 3D Asset Processing: Can it source legally usable model assets and compress them to a browser-friendly size?
• Frontend Engineering: Can it manage state and performance without build tools or a backend?
• Self-Verification: Can it actually run the code, identify issues, and fix them?

Below is a step-by-step breakdown of the technical pipeline, providing a reusable implementation strategy and key considerations.

2. 3D Assets: Sourcing and Processing

2.1 Asset Sourcing and Compliance

Public museums and open cultural projects have released massive amounts of 3D scan data for sculptures, architecture, and artifacts. These are typically in STL or OBJ formats and licensed under Creative Commons or similar protocols. When using them, three steps are mandatory:

1. Verify the license type: Distinguish between “Attribution-ShareAlike” and “Public Domain.” The former requires derivative works to be equally open.
2. Retain attribution: List the original scan source and license in the page footer or an “About” module.
3. Record versions: Write the asset file’s hash and download time into the project documentation for future reproducibility.

Many scans come from crowdsourced scanning initiatives. While highly accurate, their file sizes often range from tens to hundreds of megabytes. Directly loading raw STL files into a webpage will instantly crash mobile browsers.

2.2 Mesh Simplification and Format Conversion

For browser-side rendering, glTF/GLB is the preferred format. It packages geometry, materials, and textures into a single file with a short parsing path. The conversion workflow generally looks like this:

# 1. STL to OBJ (for easier subsequent processing)
assimp export model.stl model.obj
# 2. Mesh simplification, target face count under 50k (mobile-friendly)
meshlabserver -i model.obj -o model_low.obj -s simplify.mlx
# 3. Export to GLB and enable Draco compression
gltf-pipeline -i model_low.obj -o model.glb -d

Three key parameters require attention:

• Target face count: Under 100,000 for desktop and under 30,000 for mobile are safe ranges.
• Draco compression: Geometric compression rates often exceed 60%, but you must register the corresponding decoder on the frontend.
• Normal recalculation: After simplification, vertex normals must be recalculated; otherwise, lighting will show obvious blocky artifacts.

2.3 Implementing the Procedural “Chipping” Effect

The core visual of “from raw stone to statue” is material being removed layer by layer. There are two mainstream approaches:

Approach A: Geometric Clipping. Use a continuously shrinking bounding box or plane, combined with a clipping plane to cut the mesh in real-time. The advantage is accurate physical semantics. The downside is inconsistent browser support for multiple clipping planes, and the cut cross-sections need to be capped.

Approach B: Shader Masking. Keep the complete geometry unchanged. Pass an “removed volume” parameter via the vertex shader, and in the fragment shader, determine whether the pixel should be discarded based on its world coordinates:

// Fragment shader snippet: discard pixels based on height threshold
uniform float uRemoveLevel;   // 0.0 ~ 1.0
varying vec3 vWorldPos;
void main() {
  float h = (vWorldPos.y - uMinY) / (uMaxY - uMinY);
  if (h < uRemoveLevel) discard;   // The "chipped away" part
  gl_FragColor = vec4(baseColor, 1.0);
}

The advantage of Approach B is that it doesn’t alter the geometry topology, has a constant performance overhead, and the threshold can be animated. The downside is the lack of a real sense of volume at the cross-section. In practice, you can overlay a noise function to make the discard boundary resemble irregular chisel marks:

float noise = fbm(vWorldPos.xy * 3.0);
if (h + noise * 0.05 < uRemoveLevel) discard;

This line of code dramatically improves the visual effect—a regular horizontal cutting line instantly transforms into a rough stone fracture.

3. Interactive Narrative: Turning “Subtraction” into Actionable Steps

3.1 Choosing the Interaction Metaphor

The most direct interactive mapping for the concept that “sculpting is subtraction” is holding a button to continuously remove material. Three design points are essential:

• The primary action must be continuous, not a single click. Holding for 2–3 seconds to see noticeable change matches the user’s physical sensation to the rhythm of “chiseling.”
• The undo button should create cognitive dissonance. Provide a prominent “Undo” button that, when clicked, returns a prompt explaining that operations taken for granted in the digital world do not exist for physical materials. This isn’t an easter egg; it’s part of the narrative.
• Progress cannot be reversed. Once a certain volume is removed, you can only move forward. This unidirectional nature is the essential constraint of sculpting.

3.2 Narrative State Machine

Break the entire experience into finite states to prevent logic from scattering across event callbacks:

const STATES = ['prologue', 'quarry', 'carving', 'reveal', 'reflection'];
const machine = {
  state: 'prologue',
  transitions: {
    prologue: ['quarry'],
    quarry:   ['carving'],
    carving:  ['reveal'],       // Forward only
    reveal:   ['reflection'],
    reflection: []
  },
  canGo(next) {
    return this.transitions[this.state].includes(next);
  }
};

The value of the state machine is that any request to “go back” is explicitly rejected, aligning at the code level with the narrative assertion that “marble has no undo button.” Narrative and implementation no longer conflict.

3.3 Camera and Pacing

The model’s initial state is a complete block of stone. The camera should slowly push in from a distance, giving the audience time to “observe the material.” As removal levels deepen, the camera gradually pulls closer and lowers its tilt angle—mirroring the real viewpoint changes when viewing a sculpture over 5 meters tall.

Recommended pacing:

Stage	Duration Ratio	Camera Behavior
Prologue	10%	Static, only ambient light changes slowly
Carving	50%	Slow orbit + push in
Reveal	30%	Pull back to full-body composition
Reflection	10%	Free rotation, no forced guidance

4. Frontend Engineering: Performance Control in Build-Free Environments

4.1 Tech Stack Selection

In scenarios where build tools are unavailable, you can directly import 3D rendering libraries via ES Modules:

<script type="importmap">
{
  "imports": {
    "three": "https://cdn.example.com/three/build/three.module.js",
    "three/addons/": "https://cdn.example.com/three/examples/jsm/"
  }
}
</script>
<script type="module">
  import * as THREE from 'three';
  import { OrbitControls } from 'three/addons/controls/OrbitControls.js';
  // ...
</script>

Note: In actual deployment, dependencies should be self-hosted to avoid relying on external availability and to facilitate version locking.

4.2 Performance Tiering

Do not expect a single configuration to work everywhere. Perform a capability check on startup:

function detectTier() {
  const gl = document.createElement('canvas').getContext('webgl2');
  if (!gl) return 'fallback';          // Degrade to static images + text narrative
  const isMobile = /Mobi|Android/i.test(navigator.userAgent);
  const dpr = window.devicePixelRatio || 1;
  if (isMobile && dpr > 2) return 'low';
  if (isMobile) return 'medium';
  return 'high';
}

Tiering strategy:

• high: Full model + real-time shadows + post-processing.
• medium: Simplified model + no post-processing, pixel ratio capped at 1.5.
• low: Low-poly model + baked lightmaps, pixel ratio capped at 1.
• fallback: Pure long-form text and image page, retaining the full narrative text.

The key takeaway: Regardless of the tier, the narrative must be complete. What degrades is visual quality, not content.

4.3 Loading Experience

3D assets are the biggest blocker for the first screen. Two things must be done:

1. Phased loading: Load a very low-poly placeholder model (a few hundred faces) first so users immediately see the “stone,” then stream the high-poly model in the background.
2. Interruptible: If the user leaves the page midway, immediately cancel subsequent requests to avoid unnecessary bandwidth consumption.

5. From Web to Video: Multi-Format Content Reuse

A common extended requirement is generating a vertical short video for distribution based on the completed website. This pipeline requires considering:

• Scene reuse: Render the 3D scene as an image sequence based on keyframes rather than screen recording; the visuals will be much more stable.
• Pacing reconstruction: The web allows users to explore slowly, but video does not. Within 60–90 seconds, it must complete the four beats: “Raw Stone → Carving → Reveal → Freeze Frame.”
• Subtitles first: In vertical video environments, users are often muted. Narrative information should primarily be carried by subtitles, with voiceover as a supplement.
• Asset traceability: Every 3D render frame and music segment used in the video must record its source and license.

Recommended output specs: 9:16, 1080×1920, H.264, audio 48kHz. Retain project files and asset lists for easy secondary editing.

6. Typical Problems and Solutions in Practice

Problem 1: Complete idea, incomplete delivery. Models tend to output beautiful architecture descriptions and first-screen effects but stall at the “make it actually run” step. The solution is to write delivery standards into the prompt: explicitly require an accessible URL or a runnable zip file, and demand self-verification.

Problem 2: Balancing cost and speed. High-capability models incur significant costs for long, multi-turn generation tasks. In practice, a tiered strategy can be adopted:

• Planning phase: Use a high-capability model to produce the narrative structure and technical roadmap.
• Implementation phase: Use a lighter model to batch-generate code, followed by a human or high-capability model review.
• Verification phase: Actually run the code, feed screenshots or screen recordings back, and let the model fix issues based on real output.

Problem 3: 3D asset accessibility. Not all users can smoothly render 3D scenes. You must provide:

• A complete text narrative path.
• Keyframe static images.
• Keyboard-operable interactions (spacebar to advance, arrow keys to rotate).
• Contrast and focus management that comply with accessibility standards.

7. Conclusion

Using an LLM to generate a 3D interactive website is not technically complex: a rendering library, an optimized open asset, a state machine, and a tiering strategy. What truly defines the quality of the final product is the consistency between narrative and implementation—“irreversibility” is not just copy; it’s an explicit one-way transition in the state machine. “Subtractive creation” is not just a title; it’s a per-pixel discard in the fragment shader.

For developers, the more valuable lesson is: treat runnable, verifiable, and traceable as hard delivery standards. Regardless of how tools evolve, these three principles will remain relevant. As for these generative capabilities, a reasonable positioning is a “collaborator capable of independent planning,” not a “black box that replaces engineering judgment”—where the boundary lies requires measurement with every practice.