Testing Large Parameter Models in Frontend Rendering: Balancing First-Screen Composition and Water Level Logic

1. Evaluation Background: When Model Competition Shifts to Post-Training Quality

Recent iterations of large parameter models show a clear divergence in development routes: one category pursues lightweight, high-speed models focusing on inference cost and throughput; the other continues to push capability frontiers, leveraging expanded post-training investments to raise the ceiling for complex tasks. The subject of this evaluation belongs to the latter—a model version with trillions of parameters and support for up to a million tokens of context. Its official positioning emphasizes enhanced coding, 3D creation, and financial research capabilities, provided via APIs and desktop clients.

The significance of conducting a generational comparison at this stage lies not in determining whether the new version is comprehensively stronger, but in observing where improvements occur and where regressions appear. As the diminishing returns from training data distillation narrow the space for universal gains, marginal improvements in model capabilities are no longer evenly distributed but concentrated in specific sub-capabilities. Frontend 3D rendering serves as an excellent benchmark to separately evaluate “aesthetic organization capability” and “engineering rigor.”

To ensure comparability, this test was conducted within the same desktop client, switching between the old and new versions. Both used the “Advanced” mode. The task required generating a single-file offline HTML without referencing external images, models, or third-party libraries; the rendering had to be based entirely on native WebGL2. This constraint is critical: it eliminates interference from material quality and library wrappers, isolating differences down to the “code organization and spatial imagination” layer.

2. Test Task Design: A Composite 3D Scene

The test prompt required constructing a scene containing three main elements:

• Giant Ring Water Gate: Serving as the visual mainstay, it must anchor the composition.
• Terraced Sea City: Tiered buildings spreading along both shores with a central plaza.
• Adjustable Tide: Not a simple translation of a blue plane, but a system where boats, waterlines, and the submerged state of the plaza must change in coordination.

This task was designed to apply “dual pressure”: on one hand, testing whether the model can organize a complete world with clear primary and secondary focal points under the default camera; on the other, testing if it can implement the tidal dynamic system as self-consistent rule logic rather than mere visual decoration.

Both model versions delivered runnable native WebGL2 single files, indicating they are on the same tier regarding basic engineering capabilities. The real disparities emerged in two areas: spatial organization for first-screen composition and the implementation mechanism of water surface rendering. Conversely, in a third area—the numerical consistency between maximum tide level and building geometry—the new version exposed a notable weakness.

3. Dimension One: First-Screen Composition and Scene Priority

Under the default camera, the visual difference between the two versions is immediately apparent.

The older version’s approach was “placing the giant ring on the terrain”: the ring itself was massive, but the mountains on both sides occupied more of the frame. A large portion of the first screen was filled with near slopes and distant mountains, compressing the city deep into the bay. The ring stood in the center, while the sea city, plaza, and buildings required effort to distinguish—the relationship between the main subject and the background was disjointed.

The new version improved by organizing isolated objects into a cohesive landscape: the giant ring, bridge arches, beacon towers, and tiered residences were connected into a visual flow. The building complex spread along both shores, the central plaza displayed clear concentric steps, and the warm and cool tones of oxidized copper and stone materials were easier to distinguish. In short, it was much closer to the “complete world” required by the prompt, rather than “a ring object placed on terrain.”

This difference is not simply an “aesthetic preference” but reflects the model’s capability to model the scene graph hierarchy: whether it can plan the hierarchy, proportions, and occlusion relationships of “main subject - supporting elements - background” during the generation phase, instead of stacking objects one by one and relying on camera luck.

4. Dimension Two: Implementation Mechanism of Water Reflection

The water surface is the part that best illustrates the “implementation mechanism upgrade” in this test.

The older version primarily relied on analytical sky, sun highlights, and light dragging to simulate reflections. This is an approximation approach: the water color is directly calculated by the lighting formula, and shore buildings do not actually appear in the reflection. Visually acceptable, but there is no spatial correspondence between the reflection and the entity.

The new version additionally introduced a mirror camera: it redraws the city and boats from the reflection perspective and then samples them onto the water surface. This means the reflections of shore buildings have a true spatial source, the reflections shift correctly with perspective changes, and the relative positions of boats and buildings align properly.

From an engineering perspective, this is an upgrade from “shading approximation” to “geometric reprojection.” The cost is doubled rendering overhead (requiring additional render passes and texture sampling). For a single-file offline scene, this trade-off is reasonable; however, in a production environment with high real-time requirements, it would need optimization methods like resolution scaling and reflection layer culling. This also reminds us: whether the solution provided by the model is “engineering-feasible” is often more worthy of attention than whether it “looks good visually.”

5. Dimension Three: Numerical Self-Consistency of Tidal Logic

The third dimension is the most alarming part of this evaluation: the consistency between prompt intent and geometric parameters.

The prompt explicitly required “most stone steps to be submerged.” Although the new version excelled in visual organization, it fell short in setting the maximum tide level parameters. Calculating based on the step height and maximum water level in the source code, only the lowest four layers of its nine-layer plaza steps were below the average water level at high tide, failing to fulfill the “most steps submerged” requirement. Surprisingly, the older version, which had a weaker first-screen impression, covered the outermost steps with its maximum water level range.

This contrast is highly representative. It indicates that during the generation process, “narrative description” and “numerical constraints” are two chains that easily disconnect: the model can fluently write comments and variable names about “tide submerging the plaza,” yet fails to establish a verifiable constraint relationship among the water level constant, step height, and number of layers. Expressed in pseudocode, an ideal self-consistent relationship should look like this:

stepHeight = totalHeight / stepCount
maxWaterLevel >= stepHeight * submergeTargetCount

In actual generation, however, these values are often independently guessed without cross-validation. This is not an issue unique to a specific model but a common shortcoming of current large parameter models in long-form programming tasks: they can write structurally complete code but lack the “verification” awareness for internal quantitative relationships.

6. Conclusion: Beyond the First Impression, the Real Test Lies in Backend Rigor

Looking at these three dimensions together yields a clear judgment:

1. First-screen expressiveness has genuinely improved: Scene organization shifted from “object stacking” to “landscape orchestration,” and the reflection mechanism shifted from shading approximation to geometric reprojection. Both are capability-level advancements, not mere visual fluctuations from parameter tuning.
2. Rule rigor has not kept pace: The numerical inconsistency between water level and steps indicates that the model still has a significant gap in “translating natural language constraints into verifiable geometric/numerical constraints.”
3. Evaluation methodology itself needs layering: If one only looks at the first-screen screenshot, it is easy to conclude a “comprehensive upgrade.” Only by deconstructing the rendering mechanism, parameter self-consistency, and boundary conditions item by item can the true distribution of improvements and regressions be observed.

For developers, this provides two practical recommendations. First, when using such models to generate visualization or simulation code, separate “visual acceptance” from “logical acceptance”: the former relies on screenshots, while the latter must regress to constant tables, boundary conditions, and unit tests. Second, explicitly providing verifiable constraint expressions in the prompt (e.g., “max water level = step height × target submerged step count”) is more likely to yield verifiable results than simply describing “mostly submerged.”

Regarding the trajectory of model evolution, this comparison offers a window of observation: as the universal gains from distillation weaken, capability growth will increasingly concentrate on the “expression layer”—composition, materials, narrative fluency. Meanwhile, the “constraint layer”—numerical consistency, boundary handling, cross-module state synchronization—will require stronger reasoning and self-check mechanisms to bridge the gap. The improvement in first impressions is a visible progress, but what determines whether such models can enter production-grade graphics and simulation pipelines remains the backend rigor that is not easily captured in screenshots.