Evaluating LLM Front-End 3D Generation: From First Impression to Constraint Fulfillment

Why Use a “Single-File 3D Scene” to Test Large Language Models

Among the wide variety of programming evaluation tasks, “implementing an interactive 3D scene in a single offline HTML file” is one of the most information-dense. It has three characteristics at once:

1. Broad technical-stack coverage. A “bay tide” scene looks simple, but it actually exercises HTML skeleton organization, shader authoring, coordinate transforms and projection math, animation state machines, and parameter-system design. Any weak link will be exposed in the final product.

2. Nowhere to hide. Once the requirements explicitly demand a single file, native WebGL2, and zero external dependencies, the model cannot take shortcuts with ready-made libraries or texture assets. Every line of the rendering pipeline must be written from scratch.

3. Dual-channel verifiability. This kind of task has both an intuitive visual result that can be “seen” and complete source code that can be “audited.” The perceptual and engineering channels can cross-validate each other, avoiding the trap of being misled by a single screenshot.

For prompt design, a “establish the static first, then constrain the dynamic” structure is recommended:

Task: Generate an offline, runnable single-file HTML using native WebGL2,
      with no dependency on any external library, image, or model file.
Scene: A terraced bay city, with a giant ring-shaped water gate spanning
       the main channel, accompanied by beacon towers and tiered residences.
Requirements:
1. Composition first: under the default camera, the main subject should be
   the visual focus, with clear layering between the buildings on both banks
   and the central plaza;
2. Distinguishable materials: oxidized copper and stone should present
   distinguishable cool and warm textures;
3. Dynamic coupling: the tide must not merely raise and lower a blue plane—
   boat draft, shoreline water marks, and the submerged state of the plaza
   steps must all change in sync;
4. Self-consistent parameters: the highest tide level must be consistent with
   the step geometry; at full tide, "most of the stone steps are submerged."

Requirements 3 and 4 are the crux: dynamic coupling and parameter self-consistency are specifically designed to distinguish between “can draw a good-looking image” and “truly understands the geometry and physical logic behind the scene.”

Dimension One: Composition Organization Under the Default Camera—The Model’s “First Impression”

The first watershed in 3D generation tasks is often not detail precision, but how the default camera organizes scene hierarchy. The same set of geometric elements, organized differently, can look worlds apart.

There are two typical failure modes:

• Subject squeezed by the environment: the ring-shaped water gate itself is properly sized, but the hills on both sides take up more of the frame. A large portion of the first screen is filled with foreground slopes and distant mountains, while the core structure shrinks deep in the bay—viewers have to “work hard to identify” where the protagonist is;
• Objects placed孤立 on the terrain: the giant ring stands in the center of the frame, with no narrative connection among the city, harbor, and channel. The whole thing looks like a display item on a stand rather than a “complete world.”

A better performance usually has three characteristics:

• Coherent landscape: building clusters spread along both banks, with bridge arches, beacon towers, and tiered residences forming organic connections;
• Clear layering: the central plaza presents concentric stepped spatial progression, with foreground, midground, and background each playing their role;
• Distinguishable materials: the cool green of oxidized copper and the warm gray of stone can be distinguished on the first screen, indicating that the model actively planned material definitions and lighting design rather than applying random smears.

Evaluation suggestion: capture the default first screen without any additional interaction, and score around three questions—is the subject the visual focus? Is the environment serving the subject? Are materials distinguishable at a glance?

Dimension Two: Depth of Rendering Mechanism—Similar Looks, Potentially an Order-of-Magnitude Difference in Implementation

Two screenshots may look similar while the underlying mechanisms are completely different. Take water reflections as an example; there are two common approaches in the industry:

Approach one: analytic approximation. Use sky gradients, sun highlights, and light trails to “suggest” reflection. This is cheap to implement and performance-friendly, but the reflection is “painted”—the buildings on shore have no real mirrored source in the water.

Approach two: planar reflection (mirror camera). Mirror the scene about the water plane, use a mirror camera to redraw the city and boats, output to a reflection texture, and sample by screen coordinates when shading the water. This way, every building and every boat’s reflection has a real spatial source—a generational difference at the implementation-mechanism level.

// Three key steps of planar reflection (pseudocode)
// 1) Build a mirror view matrix about the water plane
mat4 mirrorView = reflectMatrix(waterPlane) * cameraView;
// 2) Redraw the scene into the reflection texture using the mirror view and clip plane
renderSceneToTexture(reflectionFBO, mirrorView, clipPlane);
// 3) When shading the water, sample by screen coordinates, adding normal perturbation and Fresnel term
vec3 refl = texture(reflectionTex, screenUV + n.xz * distortion).rgb;

The cost of this mechanism upgrade is one extra scene draw, with draw calls and VRAM overhead rising accordingly. Engineering-wise, details such as the clip plane, reflection texture resolution, and perturbation strength must also be handled. During evaluation, it is worth asking directly: is the reflection “sampled” or “redrawn”? This question alone often reveals the gap in implementation depth.

Dimension Three: Constraint Fulfillment Rate—Between “Good-Looking” and “Correct” Lies a Source-Code Audit

The easiest place for visual evaluation to fail is this: the model may use visual appeal to mask parameter errors. This is especially true for tide-related constraints—the water surface is indeed moving and the boats are indeed floating, but quantitative requirements like “most stone steps are submerged at full tide” can only be verified by going back to the source code and checking the geometric parameters.

The audit method is straightforward: extract the height sequence of the steps relative to the baseline and the maximum water level setting from the source code, and write a few lines of validation script:

# Validate: does the number of submerged step layers at full tide satisfy "most stone steps are submerged"
step_heights = [0.5, 1.0, 1.5, 2.0, 2.5, 3.0, 3.5, 4.0, 4.5]  # nine step layers
max_tide = 2.2  # maximum water level setting in the source code
submerged = sum(1 for h in step_heights if h < max_tide)
print(f"Submerged steps at full tide: {submerged}/{len(step_heights)} layers")
# Output 4/9 — not past half; the "mostly submerged" constraint is not fulfilled

In actual version-comparison evaluations, this kind of divergence is not rare: some versions do not excel in first-screen appeal, but the maximum water level covers the outermost steps and the constraint is fully fulfilled; other versions look more refined, yet at full tide only the lowest four of nine step layers are below the water level, and the quantitative requirement falls short.

It is therefore recommended to introduce a constraint fulfillment rate metric: list all quantifiable, verifiable constraints in the prompt and validate them one by one at the source-code level. Visual appeal determines the first impression; constraint fulfillment rate determines whether the output can be called an “engineering deliverable.”

Dimension Four: Differential Evaluation Across Versions—Both Progress and “Regressions” Are Signals

Single-point evaluation can only answer “is this model good or not”; differential evaluation can answer “where exactly has this generation improved over the last.” The specific approach: fix the prompt, fix the inference mode, fix the time window, run the same task with old and new model versions, and record progress points and regression points dimension by dimension. Note that model services may be dynamically adjusted over time, so comparison conclusions spanning too long a period should be treated with caution.

From an industry perspective, two trends in the recent iteration cycle are worth noting: first, as the distillation gains from high-quality data show diminishing marginal returns, the weight of investment in the post-training stage has risen markedly—whatever tasks the training focus is directed toward, the model’s capability distribution will tilt toward those tasks; second, some teams pour resources into lightweight, fast models with large volumes to gain invocation scale, while others choose to continue pushing the frontier—the performance paths of the two on complex generation tasks are beginning to diverge noticeably.

Therefore, “regressions” in evaluation should not be simply regarded as backward steps; they often expose capability trade-offs in post-training: a version may, in order to make visual appeal and mechanism more refined, have oversights in “no-error” dimensions such as parameter self-consistency. Only by looking at progress and regressions together can we infer the evolution direction of the next generation of models.

A Reusable Evaluation Workflow

String the above dimensions into an executable workflow, ready to apply directly:

1. Fix conditions: complete all sampling with the same client or interface, the same inference mode, and within the same time window, to avoid environmental noise;
2. Multiple samples: run the same prompt at least 3 times, recording stability rather than keeping only the best one;
3. Screenshot comparison: place default first screens side by side horizontally, and score by the three composition questions;
4. Source-code audit: check for zero external dependencies, shader correctness, and reflection implementation mechanism;
5. Parameter validation: extract key geometric and physical parameters, and use scripts to verify the constraint fulfillment rate;
6. Aggregate scoring: composition 30%, mechanism 25%, constraint fulfillment 30%, stability 15%, forming quantifiable conclusions that can be compared horizontally.

This kind of evaluation can be done in a local scripting environment, or executed and recorded in batches with the help of mainstream large-model service platforms (for example, the model services and related toolchains provided by Baidu AI Cloud), turning manual audits into rerunnable automated pipelines.

Conclusion: After the First Impression, the Real Test Is on the Back End

Front-end 3D generation tests the model’s “expressiveness”—composition, materials, and mechanism, none can be missing; but its limitations are equally obvious: clear task boundaries and a short verification loop. The next leg of large-model programming capability lies in the “back-end battlefield” of long-horizon tasks, multi-file projects, and tool collaboration: there, no single screenshot can serve as a safety net—only task chains lasting hours and constraints accumulating layer by layer.

The advice for developers can be condensed into one sentence: do not let the first-screen screenshot set the rhythm. Use mechanism questioning and source-code audits to verify the “first impression,” then use the constraint fulfillment rate to test engineering quality—this methodology is more long-lasting than any single evaluation conclusion.