LLMs Directly Writing 3D Modeling Scripts: How Code Capabilities Expand into the Creator Circle

1. Shifting Evaluation Focus: From Conversational Q&A to Verifiable Production Tasks

Over the past two years, the focus of LLM evaluation has shifted significantly. Early benchmarks dominated by general Q&A and commonsense reasoning are making way for three types of “verifiable” task-oriented benchmarks:

• Terminal-level coding: Models independently configure environments, install dependencies, modify multiple files, and execute test validations within real command-line environments.
• Scripted 3D creation: Models directly generate scripts executable by professional modeling software to perform modeling, layout, and material adjustments.
• Complex document reasoning: Using real financial documents to assess retrieval, cross-document verification, and multi-step numerical reasoning.

The common characteristic of these benchmarks is “automated scoring based on results”: a task either passes test cases, renders the correct geometry, or calculates the precise numerical value. Consequently, they reflect a model’s true productivity better than subjective scoring and align closely with the core question enterprises and developers care about: Can the model replace a portion of deterministic work? Public evaluation trends indicate that the gap between top open-source models and the strongest closed-source models in these three areas has narrowed to single digits, opening a window for models that are both affordable and highly capable.

2. Terminal-Level Coding: The First Crucible for Agent Capabilities

2.1 What Do These Benchmarks Actually Evaluate?

A typical terminal task benchmark provides a model with a fresh container environment and a natural language engineering requirement, allowing it to operate autonomously via the command line—inspecting files, installing dependencies, modifying code, and running tests, with success measured by task completion rate. It does not test “code line completion” but an entire capability chain:

1. Environment awareness: Reading project structures, identifying build systems, and interpreting dependency declarations.
2. Planning and decomposition: Breaking down vague requirements into executable command sequences.
3. Execution and feedback: Dynamically correcting paths based on command outputs (error stacks, test failure info).
4. Verification loop: Using test passage as the termination condition, rather than the model simply “assuming it is done.”

2.2 Cost: The Easily Overlooked Second Variable

Public information shows that top open-source models are approaching the completion rates of the strongest closed-source models on terminal tasks, but the cost per task can vary by multiples. Some lightweight models boast low unit prices but have significantly lower completion rates, leading to increased retry attempts and higher overall costs. The takeaway for developers is that model selection should evaluate both completion rate and unit task cost. It is highly recommended to build a small-scale evaluation set using real task samples from your own business rather than relying solely on public leaderboards.

3. Direct 3D Script Generation: A Key Paradigm Shift

3.1 The Difference Between Old and New Paths

Previously, the mainstream approach for integrating LLMs into 3D creation was “intermediate representation + tool invocation”: Natural Language → Structured Description (JSON/DSL) → Dedicated Plugin or External Tool Protocol Parsing → Modeling Software API Call → Rendered Result. The drawbacks of this pipeline are obvious: maintaining a separate plugin adapter for every modeling software introduced; limited expressiveness in intermediate representations, causing complex geometry and materials to be lost during conversion; and difficulty in pinpointing whether errors originate from the model, the protocol, or the plugin.

The “direct script generation” approach instructs the model to output scripts natively supported by the modeling software (typically Python) to be executed by the software’s embedded interpreter. This offers three main benefits: First, scripting languages offer far greater expressiveness than structured descriptions, allowing the direct use of loops, functions, random numbers, and mathematical operations. Second, it eliminates the extra protocol layer, enabling direct debugging via the script and execution logs. Third, the script itself is a versionable, reusable digital asset.

3.2 Three Core Capabilities Required by the Model

• Spatial reasoning: Understanding 3D coordinate systems, object hierarchies, parent-child relationships, and geometric constraints. For example, “arrange twelve trees evenly along an arc with random tilts” requires the model to internally construct parametric equations.
• API memory and composition: The scripting interfaces of modeling software are vast. The model must accurately master the attribute names and method signatures of common objects and correctly compose their invocations.
• Iterative refinement: Real creation is a multi-round process of “build → observe → adjust layout → replace material → refine geometry.” The model must be able to make incremental modifications based on the previous version of the script rather than starting from scratch each time.

3.3 Illustrative Code

The following pseudo-code demonstrates the script skeleton for an “indoor forest” scene (interface names are illustrative; refer to the target modeling software’s official API documentation for actual usage):

import math
import random
import scene_api as sa   # Illustrative interface
# 1. Initialize scene
sa.scene.clear()
# 2. Floor material
floor = sa.mesh.add_plane(size=(20, 12))
floor.material = sa.material.load("wood_walnut")
# 3. Place trees along an arc with random disturbances
for i in range(12):
    theta = i / 12 * math.pi
    x, y = 8 * math.cos(theta), 5 * math.sin(theta)
    tree = sa.collection.instantiate("banyan", location=(x, y, 0))
    tree.rotation_z = random.uniform(-5, 5)
    tree.scale = random.uniform(0.9, 1.2)
# 4. Lighting and rendering
sa.light.add_area(location=(0, 0, 9), energy=800)
sa.render.output("indoor_forest.png")

The value of such scripts lies in their parametric reusability once generated—turning the number of trees and the arc radius into variables allows for the mass production of scene variations. This is the essence of Procedural Content Generation (PCG), and LLMs are lowering the barrier for “writing PCG scripts” from skilled technical artists to all creators.

3.4 Practical Impact on the Creator Circle

• Lowered barrier: Individuals without modeling expertise can use natural language to rapidly produce usable scene prototypes for typical tasks like interior landscaping, mechanical assembly construction, or printable consumer product models.
• Efficiency boost: Experienced modelers can delegate repetitive structural setup to scripts, focusing their energy on creativity and detail polishing.
• Asset accumulation: Every generated script is a reusable, modifiable programmatic asset, offering greater long-term value than a one-off model file.
• Extended delivery: Some platforms have productized these capabilities into online previews and editing. Generated models can be directly exported as print files or rendered into short videos and dynamic images for easy sharing, forming a closed loop of “creation—delivery—distribution.”

However, a reality check is necessary: for complex character modeling, high-precision industrial parts, and physical simulations, direct script generation is still difficult to fully replace professional workflows. A more realistic positioning is “rapid prototyping and procedural assistance” rather than replacing professional modeling artists.

4. Financial Document Reasoning: Retrieval, Verification, and Hallucination Control

4.1 Why Finance is a High-Value Crucible

Financial documents are naturally “tricky” test sets: nested tables, mixed units (thousands/millions), inconsistent reporting standards (consolidated/parent company), and numerous cross-document references. To answer a single question correctly, a model must complete a full chain of “locating the source text → extracting values → standardizing metrics → multi-step calculation → cross-verification.” An error at any step will cause the final numerical value to deviate. Furthermore, benchmarks covering a complete investment workflow of “target screening → data collation → profitability analysis” assess the model’s planning and stability over long-chain tasks. Therefore, strong performance in the financial domain often indicates that comprehensive capabilities in retrieval, table understanding, and numerical reasoning can be directly transferred to enterprise scenarios like audit assistance, research report summarization, and contract verification.

4.2 Hallucination Control: From “Fabricating Less” to “Verifiable”

Financial scenarios have near-zero tolerance for hallucinations. Common industry practices include:

• Traceability constraints: Requiring the model to annotate the source document and page number for every numerical value, and refusing to answer if no source exists.
• Externalized computation: Delegating numerical operations to deterministic spreadsheet or formula engines, while the model focuses on understanding and orchestration.
• Stress testing: Constructing highly confusing question sets with interfering data specifically to measure the “fabrication rate” rather than the “accuracy rate.”

Public information indicates that new-generation models can suppress error rates to single-digit percentages under such stress tests, showing that the alignment strategy of “understand first, then answer, and admit if unable to answer” is taking effect. Developers applying these models can adopt similar system designs: rather than expecting the model to “know everything,” it is better to enforce citation and validation at the engineering level.

5. Cost and Selection: Translating Benchmark Scores into Engineering Decisions

Here are three actionable recommendations for developers:

1. Build your own evaluation set. Extract 50 to 200 task samples from real business operations (including error-prone cases) and run them with standardized scripts. This is far more persuasive than any public leaderboard.
2. Calculate cost as “price per successful execution”. A low unit price does not equate to a low total cost. Completion rate, retry attempts, and context length should all be factored into the calculation.
3. Leverage cloud capabilities to build pipelines. Cloud platforms like Baidu AI Cloud offer general-purpose capabilities including object storage, container platforms, model services, and monitoring. These can be combined to create an automated pipeline of “task queue — model invocation — result validation — artifact storage,” allowing model capabilities to be deeply embedded into business systems rather than remaining confined to web chat interfaces.

6. Conclusion

Terminal-level coding, direct 3D script generation, and financial reasoning represent three main trajectories for LLMs transitioning from “language capabilities” to “productivity capabilities.” For developers, rather than obsessing over which model wins a specific version update, it is more productive to focus on two essential questions: What “verifiable deterministic tasks” exist in my business? And do I possess the engineering infrastructure to hand these tasks over to a model? The clearer the answers, the more effectively benchmark scores can be translated into tangible efficiency gains.