Can a Generative Model Handle an Ambitious 3D Interactive Creative Project?
This article explores what happens when a generative model is given an open-ended creative brief: build an interactive website that helps ordinary people understand how Michelangelo's David was carved from a block of marble. It examines the model's narrative choices, its selection of real 3D scan data, two contrasting design approaches (an immersive dark-room experience vs. an exhibition-reader format), the transition from website to short video, and key practical findings about the gap between "having ideas" and "shipping a working product." The article also discusses cost, speed, environment capability boundaries, and copywriting quality as factors that determine whether generative models can handle long, complex creative tasks.
Letting a Generative Model Complete an Ambitious 3D Interactive Creative Project
We have grown used to treating generative models as code completion tools, Q&A assistants, or copy generators. But in one experiment, I tried to give a model a task closer to genuine creation: no predefined page structure, visual style, interaction pattern, or implementation path—just a single goal. Build an interactive Chinese-language website that helps ordinary people understand how Michelangelo’s David was born from a block of stone.
On the surface, this looks like “make a webpage.” In reality, it tests multiple capabilities at once: research and narrative construction, 3D asset handling, interaction design, front-end engineering, visual aesthetics, and an understanding of the subject of carving itself. The result was not just a display page but a runnable, experienceable interactive piece.
1. Task Setup: From “Build a Page” to “Complete a Creation”
If you simply ask a model to “make a webpage introducing the David statue,” it will most likely return a static page with mixed text and images: a few pictures, a few paragraphs of introduction, some cards, and maybe a scroll animation. The key difference in this experiment was handing creative judgment over to the model.
The core requirements can be summarized as follows:
- Narrative first: After viewing the site, the audience should not merely remember a few historical facts—they should develop a new understanding of what carving actually is.
- Interaction serves the theme: The interaction should not be decoration; it should be part of the narrative.
- Technical path decided autonomously: The model must judge for itself whether to use 3D, how to use 3D, and whether to incorporate real scan data.
- A runnable deliverable is mandatory: No stopping at proposals, wireframes, or mockups.
This way of defining a task is actually closer to how product managers, designers, and engineers collaborate in real projects: clear goals, open execution path. Here, the generative model is no longer a “code generator” but an executor with a degree of judgment.
2. The Model’s Narrative Angle: David Is What Remains in the Stone
Michelangelo is often quoted as saying something like: the statue is already in the stone, and the sculptor simply removes the excess. This idea is not new, but it is extremely well suited to being turned into an interactive experience.
The narrative angle the model ultimately chose was: David was not “added” into being—he was “subtracted” into being.
This judgment matters. If the model had chosen a “shaping David from nothing” narrative, the interaction might have become assembly, stacking, or generation. But the “subtracting excess from stone” narrative naturally corresponds to actions like cutting, peeling, and chiseling. The interaction logic and the thematic logic are therefore highly consistent.
In the actual piece, opening the page reveals a dark room with a block of marble standing in the center. The user presses and holds a button to chisel, the stone peels away layer by layer, and David’s outline gradually emerges. This process simulates the basic logic of carving: you do not see the result all at once; you approach the form through repeated subtraction.
One detail is especially notable: the page offers an “undo” button, but when the user clicks it, the message reads “marble has no undo key.” This is one of the most powerful interaction designs in the entire piece. Instead of explaining the irreversibility of carving in a long paragraph, it uses a simple interaction feedback to let the audience feel directly: carving real material is different from operating in the digital world—a mistake is a mistake, and you can only keep going.
From a technical implementation perspective, this “layer-by-layer peeling” effect can generally be achieved in two ways:
- Voxel-based boolean operations: Represent the marble as a voxel grid, perform a boolean subtraction on a specific region with each “chisel,” then generate a new mesh through isosurface extraction.
- Shader-based fragment clipping: Use a hidden clipping volume or noise function to control whether fragments are discarded, creating a transition between the rough “not yet carved” surface and the smooth “already carved” surface.
Each approach has trade-offs. The former is closer to the geometric changes of real carving but is more computationally expensive. The latter renders more efficiently but requires careful design of the transition region to avoid harsh cut faces.
3. 3D Asset Selection: The Persuasiveness of Real Scan Data
For the narrative of “subtracting David from stone” to hold, a sufficiently credible David model is essential. The model did not build one from scratch; instead, it chose to use publicly available 3D scan data of the David statue. Such data is typically obtained through photogrammetry or laser scanning, is rich in geometric detail, and can noticeably raise the quality of the final piece.
Using real scan data brings another benefit: as the stone peels away layer by layer, what emerges is not some abstract human form but a statue section with real muscle contours, hair texture, and facial features. The visual credibility is higher, and it becomes easier for the audience to develop the illusion that “it really was inside the stone.”
However, real scan data usually comes with several problems:
- High mesh face count, which creates performance pressure when loaded directly on the web. Mesh simplification, retopology, or LOD processing is needed first.
- Inconsistent coordinate origin and scale, requiring normalization after import so it fits the proportion of the stone block in the scene.
- Possible holes or non-manifold edges, requiring mesh topology repair before boolean operations.
These processes are usually not done in real time in the browser but require an offline toolchain. In this stage, the generative model’s role is more about planning the processing pipeline, generating processing scripts, and deciding which level of model precision should ultimately be loaded on the web. If the model’s environment lacks suitable offline processing capability, it needs to recognize this and adjust its technical route—for example, by using a lower-precision model or compensating for detail with normal maps.
4. Comparing Two Different Paths: Immersive Experience vs. Exhibition Reader
Given the same task, different models produced completely different solutions.
One solution was an immersive dark-room experience. The page had almost no traditional “layout.” After entering, the user faced a space rather than an article. The interaction was focused and restrained: press and hold the button, and the stone peels away. All information was conveyed through the scene, subtitles, and a small number of prompts. The advantage of this approach is high experiential density—viewers easily enter the state. The disadvantage is limited narrative capacity: if the user lacks the patience to complete the entire peeling process, they may remain at a shallow level of experience.
The other solution was an exhibition-reader format. The page used a background closer to paper, divided the content into four acts, and let users drag a slider to observe the stone gradually shrink from a block to David. This approach has stronger information-carrying capacity; users can see corresponding explanations at different stages, and the narrative rhythm is more controllable. Its disadvantage is that the “bodily” sense of interaction is weaker than the first approach—it is closer to “watching a moving diagram” than “doing a carving.”
Neither solution is absolutely better. They correspond to different viewing scenarios and audience habits. The first is better at quickly grabbing attention; the second is better for deep reading. This comparison shows that generative models do not have only one standard answer when it comes to “creative judgment”—different technical preferences and narrative tendencies produce noticeably different forms of work.
5. From Website to Video: Cross-Media Extension of the Same Narrative
After the website was completed, the next task was to produce a 60-to-90-second Chinese short video so that viewers who never opened the website could still understand the core of the piece. This was effectively a cross-media re-expression: interactive narrative had to be converted into linear narrative.
The key judgment in video creation was: do not simply record the webpage and add subtitles. The “press and hold the button” action in the webpage does not exist in video, so the visual language needed to be redesigned. Possible approaches include:
- Using camera movement to simulate the user’s viewpoint approaching the stone;
- Using time acceleration to show the stone gradually peeling away;
- Turning “the undo button is unavailable” into a pause or subtitle node rather than a real click feedback;
- Reordering information, because video viewers cannot control the pace themselves.
If using a generative model’s video production capabilities, it is usually necessary to first export the 3D scene or key frames from the website, then combine them with narration, subtitles, and background music to complete the final cut. One important lesson: the code and assets from the website can be reused, but the narrative rhythm must be redesigned. A video generated by directly copying the webpage interaction flow often drags in pace or contains large amounts of ineffective footage.
6. Several Key Findings from Practice
1. There is a clear gap between a model “having ideas” and “being able to deliver”
In this experiment, the model showed strong judgment in narrative conception, interaction design, and scene construction. It did not deliver a mediocre text-and-image page but chose an expressive approach highly aligned with the theme. This suggests that generative models already have some capability in “creative direction” and “technical route selection.”
But in the final stage from “proposal” to “runnable work,” many problems remained. For example:
- When 3D model loading fails, the error is often not discovered during the generation stage;
- Interaction states may be inconsistent across browsers and mobile devices;
- Performance issues only surface after actual runtime;
- Some interaction details require repeated debugging to reach usable smoothness.
The common trait of these problems is that they are difficult to solve directly by “generating more code.” They require actual running, observation, localization, and then going back to modify. A pure text-generation pipeline can hardly cover this closed loop.
2. Cost and speed determine whether a model is suitable for long tasks
This kind of task involves multiple rounds of generation: searching for materials, designing the narrative, writing front-end code, processing 3D assets, and debugging the rendering pipeline. Each step can produce a large amount of intermediate output. If a model’s per-call cost is high or its response is slow, the entire process becomes very lengthy.
In actual experience, once model speed and cost improved, the feasibility of completing such long tasks increased markedly. Especially when intermediate errors require retries, lower per-call cost significantly reduces the pressure of trial and error. This also means that for complex creative tasks, model economics is not “nice to have”—it is a basic condition determining whether the task can be pushed forward continuously.
3. Environment capability boundaries determine the technical route
A generative model must judge “what can be done” in light of the actual environment. If the environment supports 3D rendering, it can take the immersive route. If not, it should fall back to lighter forms of expression, such as a layer-peeling animation drawn with Canvas, SVG overlays, or a video background. Forcing use of unstable capabilities in the environment often results in a work that cannot be delivered.
A more reliable approach is: probe environment capabilities first, then determine the technical route. For example, first test browser support for WebGL, check whether model files can be loaded, and confirm mobile refresh rate—then decide which “peeling” implementation to use. This process is not fundamentally different from technical selection in real development.
4. Copy quality directly affects the completeness of the work
In this kind of piece, copy is not auxiliary information—it is part of the narrative. Short lines like “marble has no undo key” carry extremely high information density and are more powerful than a long background introduction. A generative model needs to understand that in interactive narrative, the position, timing, and length of text all affect the viewer’s experience.
Good interactive copy often has two characteristics: short and precise. “Short” is to avoid interrupting the interaction flow; “precise” is to convey key information within a limited number of words. If the model outputs long paragraphs at every point, even if the content is accurate, it weakens the experience.
7. What This Kind of Practice Suggests for Creative Workflows
The most noteworthy aspect of this experiment is not that a generative model “made a website,” but that it demonstrated a possibility: creators can drive a complete digital production process with a more abstract goal description and delegate specific implementation judgments to the model.
In a traditional development workflow, a similar task would usually be split into requirements documents, interaction prototypes, visual design, front-end development, and 3D processing, completed collaboratively by different roles. Now these stages can be compressed into a continuous human-machine collaboration process—but that does not mean people are no longer needed.
People still need to do three things in this process:
- Define ambitious goals: The model can execute, but someone must provide a direction worth executing.
- Judge whether the work holds up: The model can generate, but it cannot necessarily perceive “what is wrong.”
- Cover the last mile: From openable to experienceable often requires real debugging and polishing.
Here, the generative model is more like a highly capable but guidance-dependent executor. It can propose ideas with vision and complete a large amount of implementation work, but the true level of completion still depends on how much patience a person is willing to invest in the final stage.
8. Conclusion
Turning the birth process of a classical sculpture into a modern web-based interactive narrative is an effective test of a generative model’s comprehensive capabilities. The model demonstrated judgment about narrative logic, choices about 3D expression, and sensitivity to “how interaction should serve the theme.”
But this practice also clearly shows: the model’s creative judgment is approaching the level of “being able to propose good solutions,” while engineering delivery still requires sustained human intervention and verification. For developers, the truly valuable way to use it is not to let the model replace the entire creative process, but to let it take on more “doable but repetitive” implementation work so that people can focus their energy on judgment, polishing, and the final experience.
As technical routes become easier to generate, what determines the quality of a work is still the creator’s depth of understanding of the subject and persistence with details. This has not changed, no matter how the tools evolve.
