LLM-Driven 3D Interactive Content Generation: A Practical Guide from Prompt to Working Demo

1. Background: Asking a Generative Model to “Finish the Work”

The capability boundary of generative large models is expanding from text and images toward structured interactive content. A question worth examining: if you give a model only a “bold but loosely bounded” natural-language requirement—say, “Build an interactive website that helps ordinary people understand how a sculpture emerges from raw stone; narrative, visuals, interaction, and technical approach are all up to you”—can it deliver something truly runnable and experiential, rather than stopping at a proposal or a mockup?

This kind of task differs fundamentally from routine code completion. It tests four capabilities at once:

1. Narrative judgment: Can the model find a fresh angle for a historical subject instead of listing a timeline?
2. Visual and interaction design: Can it choose a presentation suited to the theme rather than applying a generic template?
3. Technical decision-making: Can it assess the runtime environment, select an appropriate 3D rendering approach, and complete asset integration?
4. End-to-end delivery: Can it chain these steps into an accessible page without stalling halfway?

This article walks through a real practice, examining where these capabilities shine and where they fall short, and distills reusable engineering methods. For neutrality, the specific tools involved are referred to generically as “a generative coding tool” or “an AI coding environment.”

2. Requirement Abstraction: Translating “Ambitious Creation” into Engineering Elements

The core tension in the original requirement is between “freedom” and “deliverability.” To get creative output, the prompt must leave room for the model; to guarantee delivery, the deliverable’s form must be constrained. In practice, the requirement breaks down as follows:

Requirement Dimension	Open Items (Model Decides)	Constraints (Must Meet)
Narrative angle	Which perspective to tell the “carving” story from	For a general audience, in Chinese
Visual style	Color palette, typography, whitespace strategy	Fits the sculpture theme, good readability
Interaction	Sliders, drag, buttons, animation pacing	Directly accessible in a browser, no obvious lag
Technical route	Rendering approach and asset organization	Runnable, experiential, not a static mockup

Experience shows that the fewer the constraints, the more likely the model produces something that “looks right” but doesn’t run; over-constraining, however, squeezes creative space into a fill-in-the-blank exercise. A balanced approach: lock down only two hard lines—“runnable” and “for a general audience”—explicitly delegate the remaining dimensions to the model, and state in the prompt that it should “first assess what the current environment can do, then proceed to a runnable stage.”

3. Narrative Design: Two Viable Expression Paradigms

Given the same requirement, different models produced narrative approaches that differed sharply in style yet were both viable—showing the subject admits multiple valid paths.

3.1 Process-Metaphor: Making “Subtraction” the Core Experience

The first approach seized on the essence of carving—removing excess material—with a highly distilled statement: the finished work is what “remains” in the stone. The page was organized as a dark room with a stone block at its center; users held a button to “chisel,” material flaked away layer by layer, and the form gradually emerged.

The value of this design is that it turns an abstract creative philosophy into an operable interaction. One copywriting detail was particularly clever: the page offers an “Undo” button, but clicking it shows “Stone has no undo”—a counterintuitive piece of feedback that embeds the insight “carving is irreversible” directly into the user’s action path. As a narrative device, this costs almost nothing to implement (a single message overlay), yet contributes far more to comprehension than paragraphs of explanatory text.

3.2 Exhibition-Catalog: Using a “Timeline” as the Browsing Skeleton

The second approach took the exhibition-catalog route: a light background with act-by-act narrative, where users drag a slider to watch the form “reduce” from a block to its final shape, layer by layer. It reads closer to a museum’s digital guide, emphasizing control, revisiting, and side-by-side comparison.

The two paradigms compared:

Process-metaphor: dark immersion → forced interaction → irreversible feedback → strong cognitive impact, best for short sessions
Exhibition-catalog: light reading → free dragging → repeatable comparison → high information density, best for detailed reading

This yields an important practical conclusion: under the same requirement, the “differentiated solutions” a model produces are usually not better-or-worse but better-suited-to-different-scenarios. The sounder engineering move is not to pick one arbitrarily, but to define the target audience and session length first, then choose the route.

4. Technical Implementation: Key Steps in 3D Assets and Web Rendering

4.1 Using Real Scanned Assets

Both approaches used the same real 3D scan of the statue (sourced from a public 3D scanning sharing project under an open license). Using a real scan rather than hand-modeled geometry matters for the theme: the surface undulations, wear, and proportions viewers see come from a physical object, giving the narrative higher credibility.

Several asset-handling steps deserve attention:

• Format and size: Raw scans commonly come as STL and similar formats with high triangle counts. Loading them directly in a browser causes long first-load waits, so mesh decimation and format conversion are required.
• License compliance: Openly licensed assets require preserving attribution and license information; the page should include an accessible section explaining the source.
• Orientation and scale: After import, orientation and units must be normalized, otherwise typical problems appear—upside-down models or distorted proportions.

4.2 Choosing a Rendering Approach

Browser-side 3D rendering can use a general-purpose WebGL rendering library or a higher-level scene framework. The main selection criteria:

1. Complex lighting and materials needed? Stone texture depends on normal and roughness parameters, requiring support for a physically based rendering pipeline.
2. Per-frame geometry modification needed? Flaking and chipping interactions implemented through geometry clipping demand higher vertex-processing performance.
3. Mobile compatibility: Texture sizes and the number of post-processing effects must be limited to avoid frame drops on low-end devices.

A common performance compromise is to pre-bake the “reduction process” as multiple stage models, switching and cross-fading between them to simulate continuous reduction rather than computing geometry in real time. This sacrifices continuity but significantly cuts runtime cost—a friendlier trade-off for a general-audience page.

4.3 Interaction State Machine Design

Whether “hold to chisel” or “drag the slider,” the interaction is essentially an ordered progression through the same set of states. Abstracting it as a state machine helps keep the logic stable:

States: S0 (raw stone) → S1…Sn (intermediate stages) → Sn+1 (finished form)
Events: press / hold / drag / release / reset
Constraints: stages advance forward only; reset triggers a message rather than rollback
Render mapping: each state maps to one set of visible geometry and camera parameters

Decoupling state from rendering lets frontend logic and the 3D scene iterate independently, and the same state definitions can later drive storyboards for other media such as short video.

5. Short-Video Re-creation: Asset Reuse and Shot Restructuring

After the website was complete, the next step was having the model produce a 60–90 second Chinese short video introducing the work to a general audience. This step tested whether the same narrative assets can be reused across media.

Viable reuse strategies include:

• Scene reuse: Capture the 3D scene directly from the web page as video footage, driving camera paths via script.
• Rhythm restructuring: The “free exploration” interaction of the web page must become “linear progression” in video, so shot order and dwell times need to be redesigned.
• Voice and subtitles: For a general audience, narration and subtitles carry the primary information; visuals carry mood and immediate impressions.

In engineering terms, the deliverables should include a playable vertical video file, editable project files, and a source-asset list, and the final cut should be actually reviewed to fix obvious problems—subtitles blocking visuals, jarring shot cuts, audio out of sync. This step is often the weak link of automation: generated video is more likely than generated pages to “look finished,” and needs human verification even more.

6. Practical Findings: Strong Ideas, Fragile Delivery

Across multiple runs, several observations emerged with broad reference value:

1. Idea quality and delivery completeness are not in sync. Models often deliver narrative angles and visual concepts beyond expectations, but tend to stall near delivery: environment assessment, dependency installation, asset conversion, and cross-device debugging fail far more often than solution design.
2. Cost and speed are real bottlenecks. For comparable tasks, the more capable versions are slower and more expensive; mid-tier versions improve price and speed markedly, but their completion rates on complex end-to-end tasks still require trade-offs. In practice, lower the expectation of “getting it right in one pass” and instead design a process that is “resumable across multiple passes.”
3. Failures concentrate in environment and assets. Page skeleton, copy, and interaction logic usually work on the first try; problems cluster around oversized 3D assets, blocked dependency downloads, and cross-origin access failures.
4. Human involvement should move earlier. Rather than patching things at the final stage, make “what the runtime environment can do” a front-loaded assessment item in the prompt, and require the model to output intermediate artifacts at key checkpoints (an accessible temporary page, an asset inventory) so blockers surface early.

The corresponding improvements can be summarized as:

Prompt side: explicitly require "assess the environment first → pick a route → deliver accessible intermediate states in stages"
Process side: make asset decimation, license attribution, and mobile verification fixed checklist items
Acceptance side: use "operable" rather than "completed" as the pass criterion for each stage

7. Conclusions and Reusable Takeaways

This practice shows that generative models can already carry a substantial share of the judgment and implementation work in “creative content engineering”: proposing distinctive narrative angles, choosing fitting presentation forms, writing runnable frontend skeletons, and integrating real 3D assets. But using them reliably in production still requires engineered constraints:

• Requirements: leave room for creation, draw hard lines for delivery;
• Technical: treat 3D asset processing, rendering performance, and state management as independent workstreams;
• Process: accept “multi-pass progression,” replacing one-shot acceptance with intermediate-state acceptance;
• Compliance: attribution and source notes for openly licensed assets must land in the page and the deliverables.

For teams hoping to use LLMs to validate creative concepts quickly, the value of this path lies not in “letting the model finish everything at once,” but in converting the model’s high-quality ideas rapidly into intermediate artifacts that real users can operate, then using human judgment to decide how deep to invest. This plays to the strengths of generative models while avoiding their uncertainty in long-chain delivery.