ProcFunc: Function-Oriented 3D Generation

• ProcFunc is a Python library for Blender-based procedural 3D generation using explicit, function-oriented abstractions for clear and composable workflows.
• It organizes operations into a three-layer system—a primitives API, a module composition framework, and prebuilt generators—to enhance control, composition, and scalability.
• The library supports AI-assisted editing and static program tracing, enabling efficient synthetic data generation through integrated tools like the indoor-room generator.

Searching arXiv for ProcFunc and closely related procedural 3D generation work to ground the article in papers. arxiv_search query="ProcFunc Function-Oriented Abstractions for Procedural 3D Generation in Python" max_results=5 ProcFunc is a Python library for Blender-based procedural 3D generation built around function-oriented abstractions: simple, atomic Python functions whose inputs and outputs are explicit, type-annotated, and easier to compose, inspect, and execute than Blender’s GUI-shaped, stateful, multi-step workflows. It is organized into three layers—a primitives API, a module composition framework, and a library of prebuilt generators—and is presented as a system for creating, combining, analyzing, and executing procedural generation code, with particular emphasis on large-scale diverse training data, compositional procedural materials, AI-assisted editing, and an indoor-room generator for synthetic 3D data generation (Raistrick et al., 29 Apr 2026).

1. Motivation and problem setting

ProcFunc was introduced in response to limitations in existing procedural programming interfaces, especially Blender’s native Python API and Infinigen’s wrappers. In the account given by the paper, these interfaces remain strongly tied to global UI state, dynamic socket names, hidden dependencies, and multi-step gadget manipulation. This makes them difficult to use for Python-centric development, difficult to combine reliably, and brittle for large-scale generation, randomization, and AI-assisted editing.

The motivating claim is not that procedural generation lacks expressive power, but that its interfaces impede the practical use of three properties that procedural methods already possess: Control, Composition, and Scalability. Control refers to precise tuning of shape, texture, layout, and appearance; composition refers to recombining modules into large families of outputs; scalability refers to generating unlimited diverse assets and datasets. ProcFunc therefore reframes procedural graphics as ordinary software composition rather than manipulation of hidden application state. The paper explicitly presents this as an attempt to make procedural generation easier to write, easier to compose, easier to inspect or trace, easier to randomize reproducibly, and easier for VLMs/LLMs to edit (Raistrick et al., 29 Apr 2026).

2. Function-oriented API design

At the primitive layer, ProcFunc defines 497 Python functions covering common Blender procedural operations, including shader and material node operations, geometry nodes, mesh and curve operations, object-level transformations, and animation-related operations. The guiding rule is that each primitive corresponds to one Blender operation, all dependencies are explicit function arguments, outputs are returned as normal Python values, types are annotated, and runtime assertions are used when appropriate.

This design deliberately departs from Blender’s usual workflow. Instead of selecting an object or node and then applying actions that depend on hidden state, ProcFunc turns each operation into an atomic function with explicit inputs. The paper notes that some Blender operations are split into multiple ProcFunc functions when this is necessary to keep arguments static and clean. It gives the general pattern that, rather than exposing one catch-all “Math” or “Noise” function, ProcFunc provides multiple more specific functions.

A closely related API choice is automatic datatype inference. ProcFunc removes many manual data_type settings by inferring the correct type from inputs; when the result is ambiguous, the user can cast explicitly with .astype(). The same principle extends to arithmetic, so that operators such as + - * / // resolve to the appropriate shader or numeric operation when types can be inferred. For mesh operations on subsets of vertices, edges, or faces, the library automates conversion of masks to and from NumPy arrays. The paper treats this as a way to reduce boilerplate while retaining enough explicit structure for static analysis (Raistrick et al., 29 Apr 2026).

3. Composition framework, standardized interfaces, and tracing

The second layer of ProcFunc is a module composition framework in which higher-level generators are standardized as simple callable functions that directly produce useful assets. The paper defines standardized interfaces for categories including Masks, Materials, Objects, and Scenes. These interfaces guarantee expected inputs and outputs; materials, for example, expose outputs such as surface, displacement, and volume, and take a coordinate input such as vector. The purpose of this standardization is to allow modules to be swapped and combined without probing Blender internals. The paper contrasts this with the complexity of implementing a compositional material in Infinigen, where one example required about 400 lines of new code.

A central architectural distinction is the separation between deterministic generators and random samplers. Deterministic generators provide exact control through input arguments, whereas stochastic behavior is isolated into random samplers that sample all needed parameters. Every random function requires an explicit np.random.Generator input. As described in the paper, this makes randomness explicit, reproducible from a seed, and unavailable as a hidden side effect inside deterministic generators. The paper further notes that these random samplers often behave like a context-free grammar, selecting subcomponents and then recursively sampling parameters, but doing so in inline Python code.

ProcFunc also provides static analysis with program tracing. Because primitives have explicit inputs and outputs, the tracer can capture a program’s compute graph without executing expensive geometry or material operations. This enables analysis of parameters, composition structure, control flow, and dataset distributions before large-scale generation. The paper distinguishes two graph types: Instance-level graphs, which record only the path taken for a particular seed, and Distribution-level graphs, which represent all possible paths and modules that could appear across the full randomized distribution. It also states a restriction: tracing works best when the control flow of random samplers is expressed through ProcFunc primitives, often with constant-weight random branching, so that the tracer can determine seed-specific paths or enumerate possible paths efficiently via memoization and by skipping expensive internal execution (Raistrick et al., 29 Apr 2026).

4. Compositional materials and diversity analysis

A major use case for ProcFunc is the combinatorial composition of semantically meaningful material components. The paper defines 22 semantic classes of material components. These include Base Materials—Concrete, Ceramic, Metal, Fabric, Glass, Granite, Gravel, Marble, Paint, Plastic, Stone, Terrazzo, and Wood—together with Shapes such as Tile Shapes (10 variants), Bricks (4 variants), Masonry, and Planks, and Masks such as Cracks, Flakes, Smudges/Liquid Splats, Scratches, and Edge Wear. This structure is intended to support combinations such as cracked paint, scratched bricks, and dirty fabric.

The paper’s diversity claim is explicitly combinatorial. It states that these components can form tens of thousands of combinations, including pairwise combinations and larger compute graphs with 5000 or more unique combinations. The significance of this claim is that diversity is produced by recombination of semantic building blocks rather than by merely enlarging low-level parameter ranges.

ProcFunc’s tracer is used to quantify this diversity through compute-graph statistics, including counts of continuous parameters, discrete choices, cyclomatic/McCabe complexity, and entropy of the procedural distribution. The reported comparison is as follows (Raistrick et al., 29 Apr 2026):

Setting	Parameters	Complexity and entropy
Base Materials	25.5 continuous, 1.80 discrete	45 cyclomatic; 81.3 bits
Multi-level Composition	41.7 continuous, 3.71 discrete	448 cyclomatic; 134 bits

These values are presented to show that compositional layering substantially enlarges the procedural distribution. A plausible implication is that ProcFunc’s notion of diversity is not only visual but structural: the distribution-level graph itself becomes richer as semantic components are combined.

5. VLM editing and procedural code generation

The paper evaluates ProcFunc in AI-assisted code editing settings using BlenderGym-style material and geometry tasks, comparing ProcFunc-based code with Infinigen-style interfaces. The reported metrics include Photometric Loss (PL), Negative CLIP distance (N-CLIP), Chamfer Distance for geometry, Error Rate, and Cost. The stated qualitative conclusion is that ProcFunc is more concise and often slightly better on visual metrics, despite being at a disadvantage because the models were already more familiar with Infinigen from pretraining. The representation itself is shorter: ProcFunc uses 33% fewer code characters to represent each task.

The paper treats the stronger result as the from-scratch material creation experiment, where starter code is removed and models must generate new materials directly. In that setting, ProcFunc substantially reduces coding errors. The reported error rates are gemini-2.5-pro: Infinigen 30.3%, ProcFunc 4.9%; and gpt5.2: Infinigen 44.7%, ProcFunc 21.4%. The paper also states that ProcFunc improves visual metrics and lowers cost in both cases.

The explanation offered for these differences is architectural rather than model-specific. Blender and Infinigen interfaces depend on dynamic UI strings and hidden global context, whereas ProcFunc exposes atomic functions with explicit arguments. In the paper’s interpretation, this removes a class of mistakes involving wrong sockets, invalid dynamic names, and state-dependent failures, while making the procedural code more like standard Python and therefore easier for code-capable VLMs to produce correctly (Raistrick et al., 29 Apr 2026).

6. Indoor-room generator, performance, and scope

As an integrated example, the paper uses ProcFunc to build a procedural indoor-room generator. This generator combines new compositional materials with scene arrangement tools, collision checking, room geometry generation from scratch, window cutout tools, object placement tools, camera trajectory generation, and rendering and ground-truth extraction utilities. It also combines pre-generated small assets from Infinigen-Indoors with 15 larger/storage object generators that were refactored to use ProcFunc interfaces. Notable scene-arrangement components include object alignment tools, collision checking using Python-FCL, collider reuse for duplicate objects, efficient update when objects move, and uv-surface cutouts for windows that preserve quadrilateral topology for subdivision.

For synthetic-data workflows, the generator includes camera-generation primitives such as random circular cameras, random monocular or stereo cameras in a bounding box, RRT* camera trajectories for videos, and collision-aware trajectories. The paper evaluates the resulting system in terms of detail, runtime efficiency, diversity, and usefulness for synthetic data. To characterize geometric detail, it defines average normal variation for pixel $i$ as

$V_i = \sum_{j\in N(i)} \angle(n_i, n_j),$

where $N(i)$ is a $15 \times 15$ neighborhood and $n_i$ is the surface normal at pixel $i$. This measure is used to argue that the generated data has a more varied normal distribution than the baselines.

The runtime comparisons emphasize scene-generation cost. For detailed indoor scenes with objects and high poly, the reported values are: Infinigen Indoors: 278.98 min scene CPU, 15.94G memory, 4.39G storage; Ours: 1.1 min scene CPU, 4.743G memory, 0.43G storage. For high-poly scenes without objects, the paper reports Infinigen Indoors: 276 min; Ours: 0.02 min. The paper notes, however, that render time can be somewhat slower in some settings because of complex shader execution, and suggests that this could be improved by pre-evaluating shaders into textures. It also states that ProcFunc includes FFmpeg compression for lower storage cost and Eevee support alongside standard rendering.

The synthetic-data utility claim is deliberately qualified. Using stereo data generated by the room generator, the paper trains RAFT-Stereo and reports that ProcFunc-generated stereo data performs competitively with established synthetic datasets and can outperform several widely used ones, while explicitly avoiding a claim of a new state of the art. The paper also states several limitations: the room generator is still not complete coverage of all room/furniture types; VLM benchmarks are non-standard and simplified; tracing is only fully available for generators whose control flow is sufficiently structured and expressed through ProcFunc primitives; and some render-time overhead remains because of complex shaders. Within those limits, the paper identifies applications in synthetic dataset generation, procedural scene and material creation, AI-assisted editing of Blender code, controllable content creation, dataset optimization and analysis, inverse procedural generation, procedural supervision for machine learning, and reusable libraries of semantic 3D components (Raistrick et al., 29 Apr 2026).