Front-End World Model Evaluation for Long-Horizon Generation Tasks

1. Evaluation Background: From Parameter Races to Deliverable Quality

The iteration pace of multimodal large models has accelerated noticeably. One approach continues to push down parameter scale, targeting lightweight scenarios with high concurrency and low latency. Another keeps investing in frontier capabilities, allocating resources toward longer context windows, more complex tool-calling chains, and higher-fidelity generation tasks. This evaluation focuses on a new-generation model from the latter path: a model with a trillion-level parameter scale and support for context windows up to one million tokens, with post-training efforts concentrated on coding, 3D creation, and financial research.

For developers, leaderboard scores alone are no longer sufficient for model selection. The more relevant question is: when a task moves from “write a function” to “build a complete interactive scene,” can the model maintain structural and physical consistency across long-range dependencies? And in which observable dimensions do the improvements between old and new generation models actually appear?

This article uses an offline single-file 3D scene generation task to break down the practical differences between two generations of models in front-end world model tasks.

2. Test Setup: Single File, No Dependencies, Fully Offline

The test was conducted on a desktop, with both models running in their advanced modes. The task required generating an offline HTML file containing three elements:

• A giant ring-shaped water gate
• A terraced coastal city
• A tide system with adjustable water levels

The prompt specified several hard constraints:

1. Composition, architecture, and materials needed to be established first, conveying the feel of a complete world.
2. Tidal changes could not be simulated by simply raising and lowering a blue plane.
3. Ships, waterlines, and plaza flooding states needed to change in coordination with tide levels.

Both outputs were native WebGL2 single files with no external images, no external models, and no third-party library dependencies. This means the generated results had to organize the rendering pipeline, geometry structure, and state-linkage logic entirely from scratch with zero external resources, which itself imposes a strong constraint on the model’s long-range code organization ability.

3. First Impression: A Generational Gap in Scene Organization

The first key difference between the two models was how the primary and secondary elements were arranged under the default camera.

The previous generation produced an enormous ring structure, but the surrounding mountains occupied more of the frame. Much of the initial viewport was filled by nearby slopes and distant peaks. The city was compressed deep into the bay, with buildings and plazas lacking visual clarity. The ring structure held up, but the coastal city was hard to identify.

The new-generation model organized the ring-shaped water gate, bridge openings, beacon towers, and layered residential buildings into a coherent landscape. Buildings spread along both shores, the central plaza showed clear concentric terrace levels, and the warm-cool contrast between oxidized copper and stone materials was easier to distinguish. The result was much closer to the “complete world” requested in the prompt, rather than the collage-like feel of a single ring object placed on terrain.

This difference fundamentally reflects the model’s spatial planning ability under global composition constraints. The former tended to satisfy the most prominent geometric feature first, while the latter could simultaneously balance the relative positions and visual weight of multiple semantic units.

4. Rendering Mechanism: From “Looks Right” to “Has a Spatial Source”

Water surface rendering was the most technically revealing divergence point in this test.

• Previous generation: simulated reflections primarily by parsing the sky, sun highlights, and light trails. This approach is cheap, but the reflections lack real spatial correspondence.
• New generation: additionally introduced a mirror camera, redrawing the city and ships before sampling them onto the water surface. Building reflections on the shore thus gained a real, spatially corresponding source.

This is a substantive upgrade in implementation mechanism rather than parameter tuning. The mirror camera approach means the model understood that “water reflections require a world that can be reflected,” rather than simply faking it with highlight textures. For front-end engineers, this is the difference between “visual approximation” and “structural correctness.”

5. Physical Consistency: The New Model’s Hidden Regression

However, a better first impression does not equal victory across all dimensions. At the highest tide level setting, the new-generation model exposed a notable oversight.

According to the step heights and maximum water level in the source code, only the lowest four of the nine plaza terrace levels were below the average water level at full tide. This failed to fulfill the prompt’s requirement that “most stone steps be submerged.” By contrast, the previous-generation model, despite its weaker initial visual presentation, extended the highest water level to cover the outermost terrace level.

This points to a real issue: when a model allocates more attention to visual organization and rendering mechanisms, numeric consistency constraints that are unobtrusive but verifiable may be weakened. The linked physical relationship among tide level, step height, and flooding range is a typical “computable constraint.” It does not depend on aesthetic judgment, only on arithmetic correctness.

6. Developer Perspective: How to Evaluate These Models

Based on the above observations, a practical checklist for long-horizon generation tasks can be distilled:

1. Structural completeness: Is the generated result self-contained, without relying on external resources?
2. Spatial consistency: Do the relative positions of multiple semantic objects match the prompt description?
3. Mechanism plausibility: Do key visual effects have explainable implementation paths rather than surface-level approximations?
4. Numeric verifiability: When dimensions, water levels, layer counts, or other parameters are involved, can they be verified through source code analysis?
5. Cross-version regression: Does a new version regress on items where the old version already performed adequately?

Item 4 is especially easy to overlook. Visually stunning generated results often distract from numeric-level deviations. But for production scenarios requiring precise control, failing to fulfill a “mostly submerged” constraint may mean the entire logic chain is unusable.

7. Conclusion and Outlook

This evaluation highlights several noteworthy trends:

• First impressions are being systematically optimized: the new-generation model showed clear progress in composition organization, material differentiation, and spatial coherence.
• Rendering mechanisms are moving from approximation toward structure: approaches like mirror cameras indicate the model is beginning to understand the causes behind visual effects.
• Physical and numeric consistency remains a weakness: while visual capabilities improve, the fulfillment rate of verifiable constraints has not risen at the same pace.
• Approach divergence continues: while lightweight models compete on throughput, the frontier path continues to invest in deliverable quality for complex tasks.

For developers, it is unwise to select a model based solely on initial visual output. A more reliable approach is to first lock down hard constraints through structured prompts, then verify numeric consistency through source code analysis, and only finally evaluate visual performance. After all, generating a beautiful world is only the starting point. Keeping that world valid under changing parameters is the real test.