Testing Large Model 3D Generation: Visual Quality vs. Physical Consistency in the Backend

Introduction: From “Able to Generate” to “Generating Correctly”

Recent iterations of frontier large models show a clear divergence in design priorities. Some models pursue lightweight, high-throughput architectures to serve general-purpose scenarios with fast responses. Others continue pushing the limits of parameter scale and context length, concentrating post-training resources on high-difficulty tasks such as coding, 3D creation, and financial research.

For developers, comparing leaderboard scores alone is no longer sufficient to determine whether a model fits a production pipeline. A more useful perspective is this: during the training cycle of a new generation of models, the external technical environment changes significantly, and the marginal gains from distillation are diminishing. As a result, the magnitude of improvement between versions—and even occasional regression in specific capabilities—can reveal where a model is heading next.

This article uses a typical generative 3D task as an entry point, comparing outputs from two adjacent model versions under the same prompt, and analyzes capability differences in both front-end rendering and back-end physical logic. Note that this article does not recommend any specific vendor or product; it discusses only general technical issues.

Test Design: A Verifiable 3D Scene Task

Task Definition

The test requires the model to output a fully offline single-file HTML that implements the following elements:

• A massive annular water gate structure;
• Tiered sea-city architectural clusters;
• A tidal system with rising and falling water.

The prompt specifies three layers of constraints:

1. Composition layer: establish the composition, architecture, and material relationships first;
2. Mechanism layer: the tide must not be simulated merely by moving a blue plane up and down;
3. Interaction layer: boats, waterlines, and plaza submersion states must all change with water level.

These three layers form a natural evaluation framework—the first two test the model’s “first impression” capability, while the third directly exposes the consistency of back-end logic.

Observation Dimensions

We define the following dimensions for comparison:

Dimension	Observation Point
Rendering architecture	Whether native WebGL2 is used; whether external dependencies exist
Scene organization	Primary-secondary relationships, building recognizability, material differentiation
Water surface mechanism	Reflection implementation method; whether there is a real spatial source
Physical consistency	Whether water-level parameters strictly correspond to geometry
Prompt fulfillment	Whether key constraints are fully executed

Front-End Performance: The Source of First-Screen Visual Differences

Single-File and Zero-Dependency as the Baseline

Both model versions delivered native WebGL2 single-file outputs with no external images, models, or third-party library dependencies. This is commendable: for 3D display scenarios that need to be embedded into existing pages, zero dependencies mean lower integration costs and more controllable loading behavior.

But zero dependency is merely a passing grade. The real gap in visual quality lies in how the default camera organizes the primary and secondary elements of the scene.

Composition: From “Sculpture Placement” to “World-Building”

In the older model version, the ring structure was large, but the mountains on both sides occupied more of the frame. Much of the first screen was filled with nearby slopes and distant peaks, while the city was tucked deep inside the bay, making the architectural cluster and plaza difficult to recognize. The result: the ring stood at the center of the frame, but the sea city required effort to identify.

The newer version organized the ring, bridge arches, navigation towers, and terraced residential blocks into a coherent landscape. Buildings spread along both banks, the central plaza had clear concentric stepped layers, and the warm-cool contrast between copper oxide and stone materials was easier to distinguish.

The essence of this difference is scene organization capability:

• Older version: places a ring-shaped object “on top of” terrain;
• Newer version: builds a complete scene with spatial logic.

The former is geometric stacking; the latter is landscape design.

Water Surface Rendering: From Simulation to Real Sampling

The water surface is where rendering mechanism differences show most clearly.

The older version primarily used analytic sky, sun specular highlights, and light trails to simulate reflection. This approach is computationally cheap, but it causes obvious distortion in scenes with shoreline building reflections—the reflection has no spatial correspondence with the actual building.

The newer version additionally introduces a mirror camera: the city and boats are redrawn and then sampled onto the water surface. This gives the reflections of shoreline buildings a real spatial source—an upgrade in implementation mechanism.

The difference can be represented in pseudocode:

// Approach A: analytic reflection simulation
vec3 reflectedColor = skyColor + sunGlint + lightTrail;
// Approach B: mirror camera sampling
mat4 mirrorView = reflectMatrix(cameraView, waterPlane);
vec3 reflectedColor = texture(renderTarget, project(mirrorView, worldPos)).rgb;

Approach B costs one additional scene render, but the gain in visual credibility is significant.

Back-End Logic: Reconciling Water-Level Parameters with Geometry

Front-end visual quality can be improved quickly through rendering techniques, but consistency in back-end physical logic cannot be hidden by “looking right.” This is the most noteworthy part of the test.

The Problem: Tier Submersion Range Does Not Match at High Tide

Based on the step heights and maximum water level specified in the source code, the newer model version’s nine-tier plaza steps—at full tide—only have the lowest four tiers below the average water level. This fails to fulfill the prompt’s requirement that “most stone steps are submerged.”

In contrast, the older version—less impressive in first-screen visuals—covered the outermost steps with the highest water level.

Analysis: The “Last Mile” in Parametric Modeling

The root cause lies in insufficient coupling between parameter settings and geometry generation. In procedural generation, the common workflow is:

1. Define the water-level parameter waterLevel;
2. Generate the step geometry steps[];
3. At runtime, determine which steps are submerged based on waterLevel.

If steps 1 and 2 lack constraint validation, it is easy to end up with “water level is set but doesn’t actually cover anything”:

// Pseudocode: parameter setting without validation
const waterLevel = 0.8;          // maximum water level
const stepHeight = 0.1;
const stepCount = 9;
// Actual maximum water level covers only 0.8 / 0.1 = 8 tiers? No, only 4 tiers
// because offsets from step base plane and plaza elevation are not accounted for

This “off by a little” problem may be masked by camera angles in a demo scene, but the moment a user drags the timeline to full tide, it becomes immediately visible.

Implications: A General Method for Evaluating Generative 3D

This case shows that evaluating generative 3D capability cannot rely solely on first-screen screenshots. The following workflow is recommended:

1. Multi-angle inspection: drag the camera to different angles; check whether scene organization remains stable;
2. Extreme parameter testing: push water level, lighting, time, and other parameters to boundary values; check whether logic still holds;
3. Source code audit: reconcile key parameters against geometry generation logic; confirm constraints are actually enforced;
4. Linked validation: check whether derived objects such as boats, waterlines, and submersion states change synchronously with the primary parameter.

Conclusion: After the First Impression, the Real Test Begins

From this test, it is clear that progress in 3D generation by large models is real: scene organization is more coherent, material differentiation is clearer, and water reflection has moved from simulation to actual sampling. These improvements make the “first impression” notably better.

But back-end physical consistency remains a weak point. The water-level and step reconciliation problem shows that generative models still have room to improve in constraint propagation during parametric modeling. For developers, this means:

• In prototypes and demo scenes, the front-end rendering capability of models can be leveraged to produce results quickly;
• In production-grade applications, generated results must undergo back-end logic audits—especially for physical rules, numeric boundaries, and linked relationships.

The next stage of competition will not be about “whose first screen looks better,” but “whose logic holds up under scrutiny.” For teams integrating generative 3D into actual pipelines, the recommendation is to shift evaluation focus from visual screenshots to verifiable physical consistency—this is the key metric that determines whether a model can truly go into production.