Large Model Hands-On Test: From "Can Generate" to "Can Express" — How Scene Construction Capabilities Take a Key Step Forward

Recently, a cloud provider released the latest member of its flagship large-model series. Official materials describe a model with a three-trillion-parameter scale and a context window supporting up to one million tokens. Building on its predecessor, it significantly increased investment in the post-training stage, with emphasis on three vertical domains: code generation, 3D content creation, and financial research. The model has been fully integrated into the company’s chat product, collaborative office platform, intelligent coding assistant, and public API.

Initial evaluation results show that the model’s highlights cluster around long-horizon coding tasks and tool-assisted tasks. However, its performance across different task types exhibits clear capability divergence. Notably, the domestic large-model market is currently riding a wave of competition around “lightweight, high-capacity” models, yet this new model has not followed that trend — it continues to push the performance ceiling instead.

For developers, therefore, the more valuable lens is not its absolute scores but how far it has advanced relative to the previous generation. During the months of model training, the industry environment changed significantly — the marginal returns from knowledge distillation are diminishing. From this generation’s performance gains and even the “rollback” in certain capability dimensions, we can glimpse the likely technical evolution paths for these frontier models.

Below is our comparative hands-on test based on real development scenarios.

Hands-On: Generational Differences Between Two Models in 3D Scene Generation

All tests were conducted in the desktop client, with the interface displaying the previous generation and the new version respectively, both set to “advanced reasoning” mode. Per industry convention, reasoning capabilities may be adjusted two weeks after a new model’s release, and service quality for the older version may also change once the new version ships; however, all comparisons here were completed within the same time window to keep conditions as fair as possible.

Test 1: Visual Storytelling in a Front-End 3D Scene

Our first test asked the model to build, using a single offline HTML file, a 3D scene containing a giant ring-shaped water gate, a terraced sea city, and dynamically rising and falling tides. The prompt explicitly required: first establish composition, architectural style, and material logic, and specifically emphasized that “the rise and fall of the tide must not be achieved merely by raising and lowering a blue plane — boats, waterlines, and the flooding state of the plaza must all change in sync.”

Both versions delivered native WebGL2 single-file implementations with no dependency on external images, 3D models, or third-party libraries. On this baseline technical requirement, both met the bar.

What truly separated the experience, however, was the ability to organize foreground-background relationships under the default camera. The previous generation’s giant ring structure was massive in scale, but the mountains on both sides occupied too much of the frame. A large portion of the first screen was filled by nearby slopes and distant peaks, while the sea city was compressed deep into the bay, leaving the buildings and plaza noticeably weak in recognizability. Although the giant ring stood at the center of the frame, users had to strain to make out the overall silhouette of the sea city.

The new version demonstrated a markedly different capacity for spatial organization. It arranged the giant ring, bridge arches, beacon towers, and tiered housing into a coherent visual landscape. Buildings spread along both shores, the central plaza had clear concentric circular step layers, and the cool green of oxidized copper versus the warm gray of stone was easier to distinguish. It came closer to the “complete world” the prompt demanded, shedding the previous generation’s patchwork feel of “a single ring object awkwardly placed on terrain.”

This difference essentially reflects differing depths of scene semantic understanding. The previous generation tended to instantiate each element in the prompt independently, whereas the new version has learned spatial occlusion, scale contrast, and visual guidance relationships among elements — an outcome of reinforcement learning on aesthetic prior data during post-training.

Test 2: Technical Upgrade of the Water Reflection Mechanism

Water rendering is another dimension that reveals generational differences. The previous generation mainly approximated reflections through an analytic sky algorithm, simulated solar highlights, and light trails. This approach is acceptable in static frames, but once the viewpoint rotates or the tide rises and falls, the “fakeness” of the water surface is exposed.

The new version introduced a key implementation upgrade: a mirror camera. It re-renders the city and boats every frame, then samples the rendered result as a reflection texture onto the water surface. This means reflections of shoreline buildings have a real corresponding spatial source, and the deformation, distortion, and perspective changes of reflections are physically consistent. This approach incurs greater GPU overhead but delivers an order-of-magnitude improvement in visual realism.

For front-end developers, this detail has practical reference value: it shows the model understood not only the surface requirement that “water needs reflections” but also the underlying implementation principle that “reflections must be based on real geometry rather than texture-based fakery.” This suggests that when describing requirements to the model, providing implementation-level constraints (e.g., “use a mirror camera rather than planar reflection approximation”) can lead the model to produce higher-quality engineering implementations.

Test 3: Shortfalls in Physical Parameter Fidelity Persist

At the highest tide level parameter setting, however, the new version was not flawless. Calculating from the step heights and maximum water level parameters in the source code, the new version’s nine-level plaza steps had only the lowest four levels below average water level at full tide — failing to fulfill the prompt’s explicit requirement that “most stone steps be submerged.” It was the previous generation, visually weaker on the first screen, that extended the maximum water level to cover the outermost steps.

This is a detail worth pondering. It shows that current models still favor visual aesthetics over physical simulation when weighing the two. The model may have learned the visual prior of “what a spectacular full-tide scene should look like,” but lacks a strict logical reasoning chain for precise numerical conversion (step heights, water level gauges, buoyancy relationships). This further confirms the industry consensus: large models still have a significant capability gap in converting qualitative descriptions into quantitative constraints.

Reading Technical Evolution Directions from Capability Divergence

Combining the test results across the three dimensions above, we can distill the following observations:

First, the leap in visual storytelling is a direct return on the shift in post-training strategy. The new version’s progress in scene composition, material differentiation, and spatial relationships far exceeds what parameter scale growth alone could explain. This most likely stems from the introduction of large volumes of high-quality 3D scene description data and human aesthetic feedback during post-training, rather than relying solely on the base model’s knowledge reserves.

Second, physical simulation accuracy remains the bottleneck constraining models from moving into professional applications. When a task requires both visual presentation and physical correctness, the model tends to satisfy the former first. Developers using such models to generate simulation scenes or digital twin prototypes must retain a manual verification step for physical parameters and cannot blindly trust all model output.

Third, with diminishing distillation returns, model differentiation competition is intensifying. Over the past six months, the industry has widely compressed large-model capabilities into smaller-parameter models via knowledge distillation to reduce costs. But as distillation gains approach saturation, leading models are refocusing on capability dimensions that are hard to compress, such as “deep thinking” and “complex tool invocation.” The new version’s choice to increase post-training investment rather than pursue a lightweight路线 is a microcosm of this industry trend.

Practical Recommendations for Developers

Based on this hands-on test, we offer the following recommendations for developers using or planning to use large models for scene generation:

• Explicitly state implementation mechanisms in prompts: For example, explicitly require “use a mirror camera for water reflections,” and the model will follow that constraint to produce a more expected implementation rather than defaulting to a more compute-efficient approximation.
• Independently verify physical parameters: Do not rely on model-output values for water levels, heights, velocities, etc., as final references. After generation, batch-validate key physical quantities via scripts.
• Distinguish “visual completeness” from “logical correctness”: Current models excel at the former, but the latter still requires engineering safeguards. Project schedules should reserve time for fixing logic issues.

The capability boundary of large models is moving fast, but a considerable distance remains between “can generate” and “can express.” This hands-on test showed us substantial progress at the perceptual level (aesthetics, composition) and also reminded us that progress at the reasoning level (physics, mathematics) lags relatively. For technical decision-makers, positioning the model as an “efficient prototype generator” rather than a “reliable simulation engine” may be the most pragmatic consideration today.