LLM 3D Scene Generation in Practice: Recreating a Classical Sculpture as an Interactive Web Experience

In the current wave of generative AI, large language models (LLMs) are no longer limited to natural language processing—their capabilities in code generation, 3D scene construction, and multimodal content creation are becoming increasingly prominent. We recently ran an in-depth, hands-on test of the advanced reasoning version of a major LLM. The goal was not to measure single-point generation quality, but to evaluate how well the model handles the full engineering pipeline: understanding an abstract humanities theme, decomposing complex requirements, orchestrating multiple technical tools, and finally delivering a complete, runnable web application.

The specific task: have the LLM autonomously design and develop a 3D interactive website that explains to a general audience how a famous Renaissance marble statue came into being. This demands not only solid front-end 3D rendering skills, but also a deep understanding of sculpting as an artistic act—and the ability to translate that understanding into interactive language.

1. Requirement Decomposition and Interactive Narrative Design

When issuing the instruction, we deliberately specified no visual style and no tech stack. Instead, we used a goal-oriented prompting strategy, leaving all decisions about narrative, visuals, interaction, and technical approach to the model. This puts the burden entirely on the model’s ability to abstract requirements and break down tasks.

After receiving the instruction, the model quickly produced two sharply different narrative architectures:

Plan A: Immersive dark-room experience (philosophical metaphor)

This plan frames sculpting as the “art of subtraction.” The page opens in a dark room with an intact marble cube standing at the center of the screen. Pressing and holding an on-screen “Chisel” button triggers chunk-by-chunk flaking animations, and the statue gradually emerges amid flying fragments.

The most elegant detail is its philosophical take on interaction: the interface offers an “Undo” button, but clicking it pops up the message “Marble has no undo.” By breaking the conventional fault-tolerance pattern of software, this design digitally reproduces the irreversibility of physical carving and dramatically heightens the emotional impact.

Plan B: Illustrated, layered reading (educational deconstruction)

This plan adopts a design language closer to a traditional exhibition catalog. Set against a paper-like texture, the story is divided into four acts. By dragging a slider on the side, users can clearly observe each stage of “subtraction,” from the raw block to the finely finished sculpture.

Its strength is clarity of information delivery, making it a better fit for audiences who want to understand the carving process step by step.

Developer takeaway:

These two proposals show that high-end LLMs now exhibit genuine “product manager” thinking. They are no longer passive code generators that simply execute instructions; they can proactively select appropriate UI/UX paradigms based on the theme—even creating artistic tension between copy and interaction. In practice, developers should make good use of this kind of “delegating” prompt to unlock the model’s cross-domain reasoning.

2. 3D Asset Processing and the Front-End Rendering Stack

However refined the narrative, delivering a 3D website ultimately depends on solid graphics code. In this test, the model autonomously chose a modern WebGL-based front-end 3D stack and successfully integrated real 3D scan data of the sculpture.

1. Integrating and optimizing 3D scan assets

Both plans loaded a real statue model in STL format from an open-source 3D scanning community. Raw scan meshes often weigh tens of megabytes, and loading them directly in the browser creates severe performance bottlenecks. When generating the code, the model automatically applied the mesh simplification strategy commonly used in industry:

// Illustrative code: LLM-generated 3D model loading and optimization logic
import { STLLoader } from 'three/examples/jsm/loaders/STLLoader';
import { SimplifyModifier } from 'three/examples/jsm/modifiers/SimplifyModifier';
const loader = new STLLoader();
loader.load('assets/david_scan.stl', (geometry) => {
    // The raw scan mesh has too many faces; simplify it to fit web performance budgets
    const modifier = new SimplifyModifier();
    const simplifiedGeometry = modifier.modify(geometry, geometry.attributes.position.count * 0.5);
    const material = new THREE.MeshStandardMaterial({
        color: 0xeeeeee,
        roughness: 0.7,
        metalness: 0.1
    });
    const mesh = new THREE.Mesh(simplifiedGeometry, material);
    scene.add(mesh);
});

2. Physical materials and lighting

To reproduce the feel of marble in the dark-room environment, the model carefully configured PBR (physically based rendering) materials, tuning specular, roughness, and reflectivity parameters. It also added ambient occlusion (AO) and spotlight shadow casting to reinforce the sense of volume and drama as the stone flakes away.

3. Extending from a Static Web Page to a Cross-Modal Short Video

After the 3D website was complete, we pushed further to probe the model’s cross-modal boundaries: we asked it to independently produce a 60–90 second vertical (9:16) short video based on the finished site’s code and research, to promote the website to a general audience.

1. Audiovisual language and shot planning

Upon receiving the video brief, the model started by writing a storyboard script. It reused the site’s “stone flaking” and “no undo” moments as the core visual conflicts and planned the following shot sequence:

• Opening (0–15s): fade in from black to reveal the rough texture of the raw stone, paired with muffled chisel sound effects.
• Middle (15–60s): the camera orbits the 3D model; from the user’s first-person perspective, a tap on the screen sends stone blocks bursting outward as the statue’s core silhouette emerges.
• Ending (60–90s): a close-up of the “Undo” button, the “Marble has no undo” message appears, then the video fades out to display the website URL.

2. Asset reuse and render export

During video generation, the model did not create new assets. Instead, it directly reused the code and geometry from the front-end 3D scene, recording virtual camera path animations and converting the WebGL frame stream straight into a video frame sequence. This “code as footage” approach dramatically reduces the cost of cross-modal production.

Developer takeaway:

In real enterprise scenarios, an automated pipeline like “3D asset → interactive website → marketing short video” has clear commercial value. In e-commerce product display, for example, a developer only needs to provide a 3D product model, and the LLM can generate both an interactive web showcase and short-video assets ready for distribution. Combined with cloud object storage and audio/video processing services, this digital asset workflow can be hosted and distributed efficiently.

4. Pain Points and Engineering Reflections

Despite the model’s impressive creativity and code integration in this test, the process exposed several typical pain points in putting AI coding into production:

1. Trade-off between inference cost and response latency

Earlier versions of the model offered strong logical reasoning but slow generation and heavy compute consumption. The iterated version used in this test nearly doubled response speed and cut compute costs by roughly 50%, which shows that foundation model vendors are tackling the cost-effectiveness of advanced reasoning through algorithmic optimizations such as speculative decoding and KV cache reuse. Still, for long-chain tasks—from requirement understanding to video rendering and export—a single conversation can involve considerable waiting time, making such workloads better suited to asynchronous task flows.

2. Task interruption and state resumption

While working autonomously, the model occasionally hit “task dropouts” caused by context window limits or errors in intermediate steps, failing to carry through to final delivery in a single run. This means developers cannot rely on a single prompt for complex AI coding projects; a checkpoint-and-resume mechanism is essential:

• Break the large task into subtasks such as “environment setup,” “3D loading,” “interaction logic,” and “copy refinement.”
• Use an engineering framework to record the generation state of each step, so that when the model is interrupted, context injection lets it resume from the breakpoint.

3. Environment awareness and tool calling

Before executing, the model could assess the capabilities of the current sandbox environment—such as whether GPU acceleration was available or whether specific video encoding formats were supported—and adjust its technical route accordingly. But this awareness still depends on developers providing sufficient environment context in the prompt. Going forward, dynamic metadata injection from cloud-native environments should further improve the model’s ability to adapt during development in cloud sandboxes.

5. Conclusion

This test—having an LLM recreate a classical sculpture—shows that large language models are no longer mere “code completion tools.” They are evolving into “AI engineers” with a degree of aesthetic judgment, product thinking, and full-stack development capability. They can combine cold 3D scan data with a warm, humanistic historical story, and use WebGL rendering and clever interaction design to create deeply immersive product experiences.

For developers, our role should shift from “the person who writes the code” to “the guide and reviewer of the system architecture.” By designing prompts deliberately, introducing engineering-grade task orchestration, and leaning on cloud-native infrastructure for compute and storage support, we can use LLMs to unlock more innovative scenarios featuring complex interaction and cross-modal characteristics.