Building 3D Interactive Websites with AI: An Engineering Guide from Text Intent to Experience

1. Background: When “Generate a Website” Becomes a Natural Language Prompt

In the past, building an interactive educational website with 3D models required collaboration among front-end engineers, 3D artists, interaction designers, and content editors. Today, powered by large language models (LLMs) with code generation and tool-calling capabilities, developers can use a simple natural language description to drive the creation of a runnable application.

A typical task prompt might look like this:

Build an interactive website that helps everyday people understand how a classic sculpture is born from a block of stone. The goal is for the audience to not just remember a few historical facts, but to gain a new understanding of “the act of carving” and be willing to stop and observe the work. You decide the narrative angle, visual style, interaction methods, and technical approach.

While this prompt specifies no frameworks, APIs, or data structures, it implies a massive amount of engineering decision-making: Where do the 3D models come from? How are they loaded? How do interactions bind to the narrative? How is performance guaranteed? This article provides a systematic technical implementation path to answer these questions.

2. Overall Architecture: Breaking Down Vague Intent into Executable Modules

From an engineering perspective, such a task can be decomposed into five layers:

1. Content Layer: Theme materials, narrative scripts, copywriting.
2. Asset Layer: 3D models, textures, audio, fonts.
3. Rendering Layer: WebGL rendering pipeline, lighting, materials, camera controls.
4. Interaction Layer: User input, state machines, animation transitions.
5. Delivery Layer: Static site generation, CDN distribution, performance and compatibility.

A common architectural choice is to rely on the browser’s native WebGL capabilities, combined with a mature 3D rendering library to build the scene. The overall data flow is as follows:

User Input → State Machine Update → Scene Graph Modification → Render Loop
   ↑                                                              ↓
Narrative Script ← Asset Loader ← 3D Assets (Geometry + Materials)

Here, the state machine is the critical bridge between “narrative” and “rendering”. Without a state machine, interactions are merely scattered buttons. With a state machine, every chisel strike, every layer of peeling, and every line of text becomes a node in the same state transition diagram.

3. 3D Asset Acquisition and Processing: Engineering Real-World Scan Data

3.1 Asset Sources and Licensing

High-quality 3D scan data typically comes from open cultural heritage projects, released under Creative Commons licenses. Before use, you must verify:

• Whether the license type permits commercial use and redistribution;
• Whether attribution and ShareAlike requirements apply;
• Whether original source information must be retained.

In engineering practice, it is recommended to include licensing information in the site footer or an “About” page, ensuring compliance and boosting credibility.

3.2 Geometry Simplification: From Millions of Polygons to Interactive

Scanned models often have extremely high polygon counts, and loading them directly will cause excessively long initial load times. Common simplification strategies include:

• Mesh Simplification: Using the Quadric Error Metric (QEM) algorithm to reduce the polygon count to 5%–10% of the original;
• LOD (Level of Detail) Tiering: Keeping high-resolution models for close-up views and preparing low-resolution models for overall browsing;
• Vertex Compression: Quantizing floating-point coordinates to fixed-point to reduce transfer size.

A pseudo-code implementation for simplification using a general mesh processing library looks like this:

// Pseudo-code: Mesh simplification workflow
const original = await loadMesh('scan.stl');
const simplified = simplifyMesh(original, {
  targetRatio: 0.08,      // Keep 8% of polygons
  preserveBoundary: true, // Preserve boundary features
  aggressiveness: 7
});
const compressed = quantizeVertices(simplified, {
  positionBits: 14,
  normalBits: 10
});
await exportToGLB(compressed, 'david-lod0.glb');

3.3 Format Selection

For the web, glTF/GLB should be the preferred format because:

• It features binary encapsulation, containing geometry, materials, and animations in a single file;
• It has the best compatibility with loaders from mainstream rendering libraries;
• It supports the Draco compression extension to further reduce file size.

4. Rendering Layer Implementation: Lighting, Materials, and Camera

4.1 Scene Setup

A minimalist scene initialization roughly looks like this:

const scene = new Scene();
const camera = new PerspectiveCamera(45, aspect, 0.1, 1000);
const renderer = new WebGLRenderer({ antialias: true });
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
const ambient = new AmbientLight(0xffffff, 0.4);
const keyLight = new DirectionalLight(0xfff5e0, 1.2);
keyLight.position.set(5, 8, 6);
scene.add(ambient, keyLight);

Key considerations include:

• Pixel Ratio Cap: Limit to 2 on mobile devices to prevent over-rendering;
• Lighting Hierarchy: Ambient light plus a key light plus a fill light are necessary to give marble materials a sense of volume;
• Tone Mapping: Use ACES or Reinhard to avoid highlight blowout.

4.2 Material Selection

Marble is a material with strong subsurface scattering. In real-time rendering, it is typically approximated using the following methods:

• Base color biased towards warm white;
• Medium roughness;
• Simulating indirect light via environment maps;
• Overlaying a layer of Fresnel rim light when necessary.

const marble = new MeshStandardMaterial({
  color: 0xf2ede4,
  roughness: 0.55,
  metalness: 0.05,
  envMapIntensity: 0.8
});

5. Interaction Design: Turning “Carving” into an Operable State Machine

5.1 State Definition

Taking the narrative of “from raw stone to statue” as an example, the state machine can be defined as:

IDLE → CHISEL_1 → CHISEL_2 → ... → REVEALED

Each state corresponds to:

• The visible geometry level;
• Camera position and orientation;
• Copywriting content;
• Available action buttons.

5.2 Chiseling Animation

The “peeling off pieces of stone” effect can be implemented in two ways:

1. Geometry Replacement: Pre-generating multiple simplified layers and switching them sequentially;
2. Clipping Planes: Dynamically cutting the mesh using clipping planes, combined with particle systems to simulate debris.

The second approach is more flexible but requires handling the capping of the cut edges. A compromise approach is to use geometry replacement for the main body and supplement the debris with a particle system.

function chiselStep(state) {
  state.layerIndex += 1;
  mesh.geometry = layers[state.layerIndex];
  playDustParticles(mesh.position);
  camera.focusOn(mesh.getBoundingBox());
  updateNarration(state.layerIndex);
}

5.3 The Counter-Intuitive “Undo” Design

An interesting interaction point is providing an “Undo” button, but upon clicking, instead of returning to the previous step, it triggers a prompt: “There is no undo key for marble.”

From an engineering perspective, this is a deliberate state machine branch: the button does not alter the geometry state; it only triggers a text animation. In implementation, simply adding a SIDE_EFFECT node to the state machine is sufficient:

const undoButton = {
  label: 'Undo',
  onClick: () => {
    if (state.phase === 'CHISELING') {
      showToast('There is no undo key for marble.');
    }
  }
};

This design transforms a “technical constraint” into “narrative expression,” making it a highlight worth preserving in AI-assisted creation.

6. Performance Optimization and Delivery

6.1 First Screen Optimization

• Chunked model loading: Load the low-resolution model first, then load the high-resolution model on demand;
• Use IntersectionObserver to lazily initialize off-screen scenes;
• Enable gzip/brotli compression to reduce GLB file size by an additional 30% or more.

6.2 Mobile Adaptation

• Limit shadow map resolution;
• Reduce particle count;
• Provide a “Low Quality” toggle that automatically detects device performance.

6.3 Delivery Format

It is recommended to build using a static site generator. The output consists of purely static files that can be deployed directly to object storage paired with a CDN. If dynamic capabilities are required, state synchronization and comments can be placed in an independent stateless service.

7. Checklist: From “Runnable” to “Great Experience”

Dimension	Check Item
Narrative	Does every interaction step have a clear intent?
Visual	Are lighting, materials, and tone mapping unified?
Interaction	Is there feedback, reversibility, and an element of surprise?
Performance	First screen load time, frame rate, memory footprint
Compliance	Asset licensing, attribution, privacy policy
Accessibility	Keyboard operation, contrast ratio, subtitles

8. Conclusion

Using natural language to drive AI to generate 3D interactive websites presents its real challenge not in “generating code,” but in translating vague content intents into executable state machines, loadable assets, and measurable performance metrics. The value of engineering lies in ensuring that every “chisel strike” corresponds to a state transition, that every “layer of peeling stone” incurs a controllable rendering cost, and that the final delivery is not just a page that opens, but a work that compels people to stop and observe.

As model capabilities grow stronger, a developer’s core competitiveness will shift from “being able to write it” to “being able to judge accurately”—judging which interactions are worth building, which performance metrics must be guaranteed, and which expressions truly move people. This is the most worthwhile direction to invest in during the era of AI-assisted creation.