ProcFunc

一句话抓住这篇论文

ProcFunc 的核心不是训练一个新的图像到材质模型，而是重新设计 Blender procedural generation 的程序表示。 作者把 GUI 导向、依赖隐式全局状态的 Blender 操作，重构成 497 个显式输入输出的 Python 原子函数， 再用标准化 module interface、可复现随机采样和静态 program tracing， 把材质、几何和场景都变成更适合人类与 VLM 读写、组合、分析和优化的程序。

研究动机：真正的瓶颈可能是程序接口

这篇论文的一个重要观点是，程序表示会直接决定 AI agent 的可用性。如果一段 node graph 转成 Python 后充满 UI key、全局状态和样板代码，即便模型有很强视觉推理能力，也会浪费大量推理预算在 Blender 的偶然复杂性上。

表示设计：把 procedural generator 当作函数系统

1. 原子操作

作者将每个 graphics operation 表示为一个 Python function。函数的依赖全部显式写入参数，所有效果通过返回值暴露。运行时自动进行 datatype inference，并允许算术 operator 根据输入类型映射到 shader 或其它算术操作。

可以把一个 deterministic generator 抽象为：

其中 \(\theta\) 是公开的 procedural parameters，\(c\) 是 coordinate、geometry 或上游 module 输出。对 material module，论文规定一个重要的标准接口：输入包含 vector 坐标，输出包含 surface、displacement 和 volume。

2. 随机 generator 与 deterministic generator 分离

随机版本显式接收 np.random.Generator。因此随机 generator 可以写成：

其中 \(r\) 是显式 RNG state。这个设计同时保证 seed reproducibility，并阻止 deterministic module 在不可见位置偷偷引入随机性。

3. Nodegraph transpiler

论文提供 Blender Nodegraph 到 ProcFunc Python code 的 transpiler。它会进行 expression inlining、operator overload、HSV color 后处理和 example parameter interpolation。因此已有 GUI nodegraph 可以被转成适合 LLM 编辑的 Python representation，而不是要求模型从零理解 Blender 的 UI state。

Tracer：这可能是整篇论文最值得 PMG 借鉴的部分

随机 procedural generator 的参数通常藏在函数内部，所以“代码可执行”不代表“参数空间可分析”。ProcFunc 引入类似 JAX tracing 与 torch.fx 的 tracer，在特殊 execution context 中运行程序，但不执行昂贵 graphics computation，而是记录 compute graph。

三类 trace 语义

如果把 generator 的完整随机程序记为 \(\mathcal{P}\)，control trace 可以看成提取：

其中 \(V\) 是函数与参数节点，\(E\) 是数据依赖，\(\mathcal{B}\) 是离散 control branches，\(\mathcal{D}\) 是连续或离散随机分布。某个 seed 对应的 instance trace 则是这个 distribution graph 中的一条具体可执行路径。

材质系统：不是一堆独立 preset，而是组合式生成空间

作者提供 35 个新 procedural material components。核心类别如下。

真正的贡献不是组件数量，而是 compositional interface。Base、shape 与 overlay 可以任意组合，形成成千上万甚至数万种语义上有效的组合。作者还构造了“maximum diversity composition”，展示从 Base 到 Base + Shapes，再到 Base + Shapes + Overlay 后，参数数量和组合数量快速增长。

Figure 40 无法在线加载。请检索论文 Figure 40：Maximum Diversity Composition。

计算图层面的多样性

连续参数在计算 entropy 时被离散为 3 bits。这里的数字不能直接理解为视觉 diversity 的绝对尺度，但它非常适合比较同一 generator family 在引入 composition 前后的搜索空间扩展。

Surface detail

材质不仅修改 shader，还可以组合 per vertex displacement。作者用局部 normal variation 描述表面几何细节：

其中 \(N(i)\) 为以 pixel \(i\) 为中心的 \(15\times15\) neighborhood。统计来自每个数据集 500 张图的有效 pixels。这个指标说明 ProcFunc 的 material representation 可以产生真实几何细节，而不仅是 flat color texture。

VLM 实验：API 本身能否影响材质生成能力

实验 A：已有程序的参数编辑

模型获得当前代码、当前 render 和 goal render。每轮需要先判断最明显的视觉差异，再定位最可能负责该差异的 numeric fields，然后修改参数。总共进行 4 轮 sequential editing and rendering。

评价指标沿用 BlenderGym：

Geometry task 另外使用 10,000 point point clouds 计算 Chamfer Distance。PL、NCLIP 和 CD 在论文表格中按 BlenderGym 约定缩放 \(10^2\)。

参数编辑中 ProcFunc 的材料视觉指标更好，但 error rate 并没有统一更低。作者也强调这个 setting 其实不完全发挥 ProcFunc 的优势，因为任务只修改已经存在的数值参数，不需要新增结构。

实验 B：从零生成 procedural material

这是与你当前方向更接近的实验。作者去掉 starter material code，只提供 goal render，允许模型添加 nodes 并从零构造程序。为了提高难度下的稳定性，进行 8 轮交互，并额外提供 API documentation 和 5 个完成的 in context examples。

Prompt 设计

Appendix C 给出了完整 prompt templates。Parameter editing prompt 强制模型只修改 parameters，并先回答“当前 render 与目标最明显的一个视觉差异是什么”，再定位相关 numeric variables。From scratch prompt 则明确要求关注 base color、patterns、textures 和 details，并限定只使用 ProcFunc API。

概念化流程
输入：goal render + 当前 code 或最小 starter
1. 识别最显著视觉误差
2. 定位相关参数或结构
3. 输出完整可运行 Python
4. Blender 执行并渲染
5. 下一轮继续比较

程序化场景效率、合成数据与可扩展性

ProcFunc 不只提供材料 API，还用这些 components 搭建了新的 indoor room generator。作者比较 Infinigen Indoors 与自己的 scene pipeline，并分别测试是否加入 objects 和 high polygon detail。

资源使用图无法在线加载。请检索论文 Figure 4：Resource Usage。

Stereo dataset 验证

作者生成 50,000 对 stereo images。场景生成时间约 0.41 min，而参考 WMGStereo pipeline 约 13 min，约快 31 倍。随后用标准设置训练 RAFT Stereo 75k steps，使用 2 张 NVIDIA A6000。

作者没有宣称 stereo state of the art。这里的目的只是证明，一个相对简洁的 procedural generator 已经能够产生具有实际训练价值的 synthetic distribution。

Appendix 中对复现最重要的内容

Reviewer 视角

它与当前 Procedural Material Generation 研究怎样连接

对于“reference image → Substance Designer graph”的目标，ProcFunc 最值得借鉴的并不是把 Blender 换成 Python， 而是建立一层面向模型的程序 IR，并使这层 IR 同时支持生成、执行、trace、搜索和监督学习。

1. 把 SBS graph 分成三层表示

Canonical graph 负责最终兼容 Substance Designer。Agent friendly IR 负责降低 context complexity。Trace graph 负责回答“哪些 node、哪些参数、哪些 branch 实际影响了当前 render”。

2. Structured visual context 应该与 program context 对齐

你目前考虑的 macro、meso、micro visual decomposition 可以进一步对应到 graph module hierarchy。例如：

3. 这可以把 Context Optimization 从文字 prompt 变成程序级机制

如果当前 render 为 \(R(G)\)，reference 为 \(I^{\ast}\)，传统 agent 每轮可能把整个 graph \(G\) 和整个 image 都重新输入模型。ProcFunc 式 trace 允许先找到与当前 failure 相关的 active subgraph：

然后只构造局部 context：

其中 \(E_t\) 是结构化 evaluator feedback。下一轮 agent 只修改活跃子图：

4. 最值得新增的 baseline

这样可以把你的研究问题从“模型能不能生成 Substance Designer graph”提升成更一般的命题：复杂可执行视觉程序应该如何被表示、分解和动态放入 agent context，才能在有限 test time compute 下可靠优化。

最终判断

ProcFunc v2 是本批次最值得 Procedural Material Generation 方向重点关注的工作。 它没有提出新的视觉 backbone，也没有解决真实照片到材质 graph 的完整 inverse problem， 但它非常直接地证明了一个常被低估的事实：程序表示本身就是生成模型的一部分。 当 API 更显式、更短、更可组合、更可 trace 时，同一个 VLM 能更可靠地生成和修改 procedural materials。

对你当前的 Context Optimization + Agent 路线，我认为最值得立即吸收的是三点： 一是设计 Substance Designer 的 agent friendly IR； 二是建立 instance level 与 distribution level material traces； 三是让视觉 decomposition 与 active program subgraph retrieval 对齐。 这三点组合起来，比单纯增加 prompt 长度或增加 agent search rounds 更容易形成清晰、可消融、可发表的方法贡献。

原论文： arXiv abstract  ·  arXiv v2 HTML  ·  Official code

重点位置：Figure 1 Primitives API；Figure 2 compositional procedural generation；Figure 3 room generator； Table 1 parameter editing；Table 2 from scratch procedural material creation；Table 3 efficiency； Table 4 analytical diversity；Figure 5 surface detail；Table 5 stereo dataset； Appendix A material galleries and implementation examples；Appendix B tracer and room generator； Appendix C exact prompts and extended experiments。