From Text to Playable Demo: Practices in 3D Content Generation with Large Language Models

Recently, several tech communities have showcased 3D interactive projects independently completed by Large Language Models (LLMs). Examples include an open-world driving game scene with streets, vehicles, and running characters; an interactive 3D webpage simulating a foldable device where screen content updates in real-time as it folds and unfolds; and an exploded view animation of a robotic arm disassembled into over 2,000 parts, complete with physical effects like cloth simulation. Even more notable is the cost data: one open-world demo took about 10 hours, consumed 4 million tokens, and cost roughly $52, while a short 3D dynamic clip took only 5 minutes and cost about $1.10.

Rather than relying on abstract claims about “models getting stronger,” these runnable, operable works and auditable costs provide solid metrics for evaluating generative AI capabilities. This article examines these cases as technical samples, deconstructing their implementation paths, cost structures, and engineering boundaries.

1. The Shift in Capability Focus: From Code Snippets to Complete Experiences

The evaluation of code-generating models has roughly evolved through three phases:

1. Completion and Q&A: Testing the correctness of single functions or algorithmic snippets.
2. Engineering Collaboration: Evaluating cross-file modifications, repository-level understanding, and standard-compliant delivery.
3. Experience Generation: Directly producing complete, runnable, interactive, and demonstrable works.

The core change in the third phase is that the deliverable has shifted from code to an experience. The evaluation criteria have changed accordingly: it is no longer about unit test pass rates, but whether the visuals are natural, interactions are responsive, and animations are convincing. These tasks simultaneously test a model’s spatial imagination, graphics knowledge, front-end engineering capabilities, and multi-turn error correction. It serves as a much more rigorous touchstone than simply “writing a sorting algorithm.”

2. Technical Deconstruction: How a Playable 3D Demo is Generated

2.1 The Technical Foundation of Web-Based 3D Rendering

Modern browsers provide standard graphics interfaces like WebGL and WebGPU. Combined with common web-based 3D rendering solutions, developers can build standard 3D applications containing scenes, cameras, lighting, and materials in just a few hundred lines of code. To generate such works, a model must comprehensively master:

• Scene Graph Organization: Hierarchical relationships between meshes, materials, textures, and lights.
• Camera and Controls: Orbit controls, first-person views, and basic collision detection.
• Resource Pipelines: Procedural geometry generation or external model asset loading.
• Performance Constraints: Draw call control, Level of Detail (LOD), and texture compression.

Taking the foldable screen interaction as an example, its core logic can be summarized in a snippet of pseudocode:

// Pseudocode: Foldable angle and screen content linkage
slider.addEventListener('input', (e) => {
  const t = e.target.value;              // 0 ~ 1
  const angle = t * Math.PI;             // 0° ~ 180°
  upperPart.rotation.z = -angle / 2;     // Upper screen rotates around the hinge
  lowerPart.rotation.z =  angle / 2;     // Lower screen rotates inversely
  screen.material.map = angle > threshold
    ? textureFolded : textureFlat;       // Switch screen content based on state
});

2.2 Two Generation Paths: Pure Code Modeling vs. External Asset Import

Community cases demonstrate two typical paths:

• Pure Code Path: The model directly generates geometry procedurally (describing the outlines and layouts of streets and buildings with code). The advantage is single-file delivery with zero external dependencies, making it ideal for lightweight demos and rapid validation.
• Asset Path: High-precision models are first created in desktop 3D modeling software, and the model then generates loading, binding, and interaction code. The aforementioned foldable screen project—taking about 1.5 hours and costing $12.5—falls into this category, delivering a 3D presentation that can be folded with synchronized screen content.

The value of the second path lies in connecting the previously disconnected processes of “modeling” and “web interaction” into a single pipeline, which is particularly useful for product showcases and creative proposals.

2.3 Physics and Motion: From “Viewable” to “Believable”

Cloth simulation and the exploded animation of a mechanical arm with over 2,000 parts test the model’s understanding of physics simulation and animation state machines. The key to an exploded view is recording the “assembly pose” and “exploded pose” for each part, then smoothly transitioning between them using interpolation:

// Pseudocode: Exploded view animation
parts.forEach((p, i) => {
  const dir = p.assemblyPos.clone().sub(center).normalize();
  const target = p.assemblyPos.clone()
    .add(dir.multiplyScalar(explodeDist * (i / parts.length)));
  p.position.lerpVectors(p.assemblyPos, target, easeInOut(t));
});

The difficulty of such effects lies not in calling a specific graphics API, but in the overall spatial correctness between parts—this strictly requires the model to possess strong spatial reasoning and global planning capabilities.

3. Calculating Costs: Tokens, Time, and Iterations

Compiling public community data into a single table yields clearer conclusions:

Case	Output Format	Time	Cost
Open-world driving demo	Playable web prototype	~10 hours	~$52 (~4M tokens)
Short 3D dynamic clip	Dynamic demo page	~5 minutes	~$1.10
Foldable screen interactive webpage	Operable 3D showcase	~1.5 hours	~$12.50

This provides three engineering insights:

1. Token consumption correlates super-linearly with scene complexity. The 4 million tokens spent on the open-world demo did not go entirely towards the “first draft of code,” but rather into multi-turn error correction and detail polishing. Cost estimation should be based on “iterations × tokens per turn” rather than final lines of code.
2. Pricing differences amplify total cost gaps. The per-token price of differently positioned models can vary by an order of magnitude. Under complex tasks, the total cost gap is proportionally magnified. Some developers estimate that switching to a higher-priced model for the same task could increase total costs nearly tenfold. A pragmatic approach is to run baseline tests on small tasks first, then extrapolate total costs proportionally.
3. Demo costs do not equal production costs. Generating a demo page might cost only a few dollars, but reaching a launch-ready standard requires additional investment in code reviews, performance optimization, security testing, and continuous maintenance. Positioning AI generation as a “prototype accelerator” rather than a “development replacement” is a more pragmatic perspective.

4. Prompts and Workflows: Keys to Running Complex Projects on the First Try

Reviewing these successful cases reveals three shared workflow practices worth adopting:

1. Structured Requirement Descriptions. Clearly writing out the goal, scenario, technical constraints, and acceptance criteria yields a much higher success rate than a vague “make me a game”:

Goal: Generate a single-file HTML that runs directly in the browser
Scenario: Top-down view of a city block, including roads, buildings, controllable vehicles, and pedestrians
Constraints: Use only web-based 3D rendering solutions, no build tools
Acceptance: Vehicles can steer and accelerate, collisions prevent pass-through, framerate not lower than 60fps

2. Phased Delivery. Have the model generate a minimal runnable skeleton (a gray-box scene with basic interactions) first. Once the direction is confirmed, incrementally add art, animations, and audio. Maintain a runnable version at each stage to avoid generating a massive project all at once that becomes unmanageable.

3. Feedback Loop. Feeding runtime errors, screenshots, and performance data directly back to the model is the most effective way to compress iteration rounds. When possible, have the model simultaneously generate automated checking scripts (framerate sampling, collision detection), upgrading “visual inspection” to “data-driven validation.”

In terms of deployment environments, developers can invoke LLM capabilities via cloud-based model services, host the generated static pages in object storage, and distribute them through a CDN. Combined with logging and monitoring services, developers can observe real user-side framerates and errors, forming a “generate—preview—feedback” loop. Using the model services and storage/distribution products provided by platforms like Baidu AI Cloud as an example, this pipeline can be built entirely on general cloud capabilities without the need to construct infrastructure from scratch.

5. From Demo to Product: Four Hurdles in Engineering Implementation

1. Code Quality and Maintainability. Generated code often “runs but is hard to read,” lacking comments and clear module boundaries. It is recommended to treat the generated output as a draft, which engineers then refactor and supplement with tests before merging it into the codebase.
2. Performance Ceilings. Models have limited awareness of issues like draw calls and memory leaks. Complex scenes require manual intervention using profiling tools to locate bottlenecks before directing the model to optimize specific areas.
3. Asset Copyright and Compliance. Procedurally generated geometries carry low risk, but external models, textures, and audio must have verified licensing sources. An asset review process should be established before commercial use.
4. Recognizing Capability Boundaries. Currently, AI generation excels at “demo-level” experiences, but core gameplay logic, high-precision asset creation, and multiplayer real-time synchronization still require traditional development workflows. A reasonable division of labor is: AI handles exploration and validation, while humans handle deep refinement and quality control.

6. Conclusion

The greatest value of these community projects is not proving that “a certain model is powerful,” but rather providing a replicable evaluation methodology: measuring the capability boundaries of generative AI using real tasks, real costs, and real deliverables. For developers, more noteworthy than the stunning visuals is the emerging R&D paradigm taking shape behind them—structured requirements, phased delivery, and data-driven feedback. Once this workflow is established, the cycle from “idea to playable demo” shrinks from weeks to hours. This is the aspect of the current capability leap that every technical team should seriously evaluate and proactively test.