3D Scene Generation in LLMs: Composition, Water Rendering, and Physical Consistency Under Test

Benchmark scores only indicate “baseline performance,” not “actual experience.” For generative models, front-end 3D visualization tasks serve as an excellent touchstone: they simultaneously test long-horizon code planning, spatial imagination, physical common sense, and adherence to engineering constraints. More importantly, the results are visible, comparable, and traceable—open the file and you can see the gap; read the source code and you can find the cause.

The industry has recently shown a clear divergence in strategy: some models emphasize low-cost, high-throughput lightweight versions, pursuing a “volume and satiety” popularization path; others continue pushing toward frontier capabilities, concentrating post-training investment on high-value directions such as long-horizon programming, 3D creation, and vertical research. For the latter category, what truly deserves attention is not benchmark scores but the generational progress—and even localized regressions—on specific tasks. To this end, we designed a unified 3D scene generation test, driving two generations of models with the same set of prompts, comparing them layer by layer from visual impression to source code, and distilling a reusable evaluation methodology.

Note: Tests were conducted under the same client, same inference mode, and same default parameters; prompts were frozen before testing, each generation of models generated once, with no manual multi-round corrections; the test window was kept as close as possible to model availability to reduce version drift interference.

1. Test Case Design: Leaving Shortcomings “Nowhere to Hide”

The task requirements are summarized as follows:

• Deliver an offline HTML file implementing a scene with a “giant ring-shaped lock + terraced sea city + raisable/lowerable tide”;
• Use native WebGL2, with no external images, model files, or third-party libraries;
• Composition, architecture, and materials must stand firmly first;
• The tide cannot be merely “a blue plane rising and falling”: boats, waterlines, and plaza submersion states must be linked.

This design has four considerations:

1. The single-file constraint eliminates the possibility of “asset搬运” (asset transfer). All geometry, materials, and lighting must be generated line by line by the model, with no way to cheat by referencing ready-made resources;
2. The native API constraint tests low-level fundamentals. It examines the model’s understanding of the graphics interface itself, not its memory of a particular framework template;
3. “Linked tide” is a typical physical consistency trap. The easiest implementation is to move a water surface mesh, but the correct implementation requires abstracting water level as a global parameter driving buoyancy, submersion determination, and waterline textures;
4. “Composition stands first” directly points to spatial planning ability, which is the largest source of visual impression gaps.

Illustrative prompt (excerpt):

Please generate an offline runnable HTML file (single file, native WebGL2, no external resources or third-party libraries):
1. Scene: a giant ring-shaped lock spans the bay, with terraced sea cities on both banks and a central plaza with concentric steps;
2. Materials: distinguish PBR look between oxidized copper (cold green rust color) and stone (warm gray);
3. Tide: water level can rise and fall; during flood and ebb, boats rise and fall with the water surface, dock waterlines move,
   and plaza stone steps are submerged sequentially by height; it is forbidden to simulate with a separate blue plane simply rising and falling;
4. The default camera must ensure the main subjects (ring lock and sea city) occupy a reasonable frame in the first screen, with clear primary-secondary distinction.

2. Dimension One: First-Screen Composition—Scene Planning Ability Behind “First Impression”

Both outputs met the engineering baseline: single file, native WebGL2, no external dependencies, runnable on open. What truly拉开 the visual impression gap is how the default camera organizes scene hierarchy.

Problems with the previous-generation model: The giant ring itself is large, but the mountains on both sides occupy more of the frame. A large area of the first screen is filled with nearby slopes and distant mountains, the city shrinks deep in the bay, and the building clusters and plaza have weak recognizability. The main subject stands in the center of the frame, but the supporting cast steals the show.

Performance of the new-generation model: It organizes the giant ring, bridge arches, beacon towers, and stacked residences into a coherent landscape; building clusters spread along both banks; the central plaza has clear concentric step layers; and the cold-warm textures of oxidized copper and stone are easier to distinguish—closer to the “complete world” required by the prompt, rather than “placing a ring-shaped object on terrain.”

Abstracted into technical language, this tests the model’s ability to plan a “scene graph” before writing code:

• Selection of initial camera pose and look-at point;
• Size and distance ratios of landmark elements (i.e., visual weight allocation);
• Number of foreground, midground, and background layers and their occlusion relationships;
• Overall design of the material palette (cold-warm contrast, brightness gradient).

A common symptom of weak models is “element-list-style generation”: instantiating each noun in the prompt one by one and placing them on terrain, with no spatial narrative between elements. Strong models first complete composition design “in their head,” then translate it into camera parameters and layout code.

Quantifiable observation metrics include: pixel proportion of landmark elements in the first screen, number of distinguishable building clusters, foreground occlusion rate, and material category distinguishability. It is recommended to score first-screen screenshots by region rather than concluding from overall impression.

3. Dimension Two: Water Rendering—From “Looks Like” to “Implemented Correctly”

Water is the “touchstone material” of a 3D sea city scene and most easily exposes implementation depth.

The previous-generation model uses analytical approximation: simulating reflection with analytical sky color, sun highlights, and light trails. This approach is low-cost and small in code size, with acceptable static appearance, but there is no strict geometric correspondence between reflections and the actual scene; when the viewpoint changes, it easily produces the telltale “reflection doesn’t look like this scene.”

The new-generation model introduces a mirror camera (planar reflection) mechanism: redrawing the city and boats with a mirror transform, rendering to a texture, then sampling it during water surface shading. This is the classic path for realistic water reflection implementation:

// Core idea of planar reflection (pseudocode)
// 1. Construct a mirror camera using the water surface as the mirror plane
mirrorView = reflectionMatrix(waterPlane) * mainView;
// 2. Redraw the scene to an offscreen texture with the mirror camera
bindFramebuffer(reflectionFBO);
renderScene(withClipPlane(waterPlane));
// 3. Projective sampling during water surface shading
vec3 refl = textureProj(reflectionTex, projectiveCoords);
finalColor = mix(waterBase, refl, fresnel);

Why the mechanism upgrade matters: mirror reflection gives reflections of onshore buildings a real spatial source, correct parallax, and synchronous movement of boats and reflections; analytical approximation is essentially “drawn to look like reflection,” not “computed reflection.” Evaluation should not stop at screenshot comparison but read the implementation: is it moving a fake reflection, or is there truly an extra scene-drawing pass? This directly reflects the model’s depth of mastery of graphics mechanisms and explains the obvious difference in robustness between the two versions during camera movement.

4. Dimension Three: Physical Consistency—Source-Level Inspection Catches “Advanced Tell-Tale Failures”

The visually prettier version is not necessarily semantically more correct. This is the most important finding of this test.

When checking the maximum tide level setting, we calculated based on the step heights and maximum water level in the source code: for the new-generation model’s nine-level plaza steps at full tide, only the lowest four levels are below average water level, failing to fulfill the prompt requirement that “most stone steps are submerged”; instead, the previous-generation model, which did not lead in first-screen composition, covered the outermost steps with its maximum water level range.

In other words: the new-generation model wins in visual impression and implementation mechanisms but has an oversight in parameter self-consistency; the previous-generation model has mediocre visual impression but its physical settings fit the requirements better. Such problems cannot be seen from screenshots; you must read the code and calculate the values.

The engineering approach is to add “numerical assertions” to 3D generation tasks:

# Validation script idea (illustrative)
steps = parse_step_heights(scene_code)        # Parse Y coordinates of nine-level steps
max_tide = parse_constant(scene_code, "MAX_TIDE")
submerged = [h for h in steps if h < max_tide]
assert len(submerged) / len(steps) >= 0.6, \
    "Proportion of submerged steps at full tide does not meet standard"

By distilling such assertions into the evaluation pipeline, deviations between “prompt promises vs. scene parameters” can be identified in bulk and automatically. This is especially critical in production environments: when model-generated 3D configurations, digital twin scenes, or visualization dashboards are used in real business, parameter consistency errors are far more costly than visual flaws.

5. From Case to Methodology: A 3D Generation Evaluation Checklist

Synthesizing the above comparisons, it is recommended to evaluate large-model 3D generation capability in four layers:

1. Does it run (engineering layer): Single file runnable? No external dependencies? No console errors?
2. Does it look right (art layer): First-screen composition, material distinguishability, lighting atmosphere, visual flow;
3. Is it correct (mechanism layer): Is reflection approximate or a real mechanism? Is interaction (e.g., tide) driven by global parameters or local fake motion?
4. Is it stable (consistency layer): Do source constants align with prompt requirements? How large is variance across multiple samples?

Supporting prompt engineering recommendations:

• Write “acceptance criteria” into prompts, e.g., “at full tide at least sixty percent of stone steps are below water level,” rather than vague “mostly submerged”;
• Require the model to first output a scene plan (composition description, parameter table), then output code, facilitating pre-review;
• Require key physical quantities to be centrally defined as constants, prohibiting magic numbers scattered everywhere, leaving interfaces for subsequent automated validation.

6. Industry Observations: Selection and Deployment in an Era of Divergence

This test also reflects the overall state of the current large-model industry. The lightweight fast path trades high throughput and low cost for scale popularization, suitable for high-frequency, short-task scenarios; models that continue pushing the frontier concentrate capability improvements on “delivering a complete complex artifact”—long-horizon programming and tool-assisted task performance have improved markedly, but fluctuations and regressions in detail self-consistency may still occur. As training paradigms evolve and distillation gain structures change, this “single-item leap, localized regression” divergence may persist for a long time.

Two implications for developers:

First, “first impression” capability and “backend reliability” must be evaluated separately. Progress in front-end visual impression is most easily perceived and most easily wins recognition in demos; but production environments truly test long-horizon task stability, tool-calling coordination, and parameter consistency—the former determines demo效果, the latter determines whether it can go live.

Second, establish continuous evaluation rather than one-off evaluation. Connect the layered checklist and numerical assertions in this article to a continuous integration pipeline, paired with general cloud infrastructure—object storage archiving each output, logging services recording the sampling process, monitoring and alerting tracking metric regressions—to quickly discover capability regressions during model version iterations. Taking model services and supporting toolchains provided by platforms such as Baidu AI Cloud as an example, developers can containerize evaluation scripts and run them on schedule, upgrading “evaluation” from manual experience to sustainable engineering practice.

Conclusion

The conclusion of this hands-on test can be summarized in one sentence: new-generation models are better at shaping “first impressions”—composition is more methodical, and implementation mechanisms are closer to the correct solution; but what determines whether they can complete the “last mile” is parameter consistency, physical self-consistency, and long-horizon reliability—the invisible parts. Evaluation is like this, selection is like this, and deployment is like this. Visual impression is only the opening; the real test is in the backend.