1.3 Houdini 架构组件 Contexts

1.3 Houdini 架构组件 Contexts

本节摘要：Houdini 按数据类型把节点网络划分成多个 Context：OBJ 管场景变换，SOP 管几何，DOP 管模拟，ROP 管输出，LOP 管 USD 场景，TOP 管任务调度。本节用一次"让山体网络被模拟、再被渲染"的流程实验，走一遍数据跨 Context 的流转路径。

实验：同一个山，穿过三个车间

接着用 1.1 的网络做一次全流程：

1. 在 obj 层，你的 geo 容器就是 OBJ Context 的一个节点——它只关心"这坨东西在世界的哪里"（translate/rotate/scale）；
2. 双击进去，Grid/Mountain/Scatter 活在 SOP Context——几何的加工车间；
3. 在 obj 层再放一个 ROP Geometry Output（或直接用顶部的 Render 菜单走 Mantra/Karma），把结果写盘——那是 ROP Context 的事。

也就是说：形状在 SOP 定型，位置在 OBJ 决定，落盘由 ROP 负责。每个车间只对自己的数据负责，这就是 Context 分治。

图 1.3-1 六大 Context 分工图

数据怎么跨车间流动

三个常用的跨 Context 通道，实验里都点一下：

• OBJ → SOP：geo 容器是天然边界，SOP 里用 Object Merge 把别的物体的几何拉进来（注意默认拉进来的是世界空间结果）；
• SOP → DOP：模拟需要几何做碰撞体与发射源，DOP 里的 Sop Import / Static Object 负责搬运；解算完再用 Dop Import 把每帧结果带回 SOP 层做后处理；
• SOP → LOP/TOP/ROP：SOP Geometry 节点把几何挂进 USD 舞台；TOP 的 ROP Fetch 把整段网络当成一个可调度任务。

形状(SOP) → 演化(DOP) → 后处理(SOP) → 编排(LOP) → 批量/落盘(TOP/ROP)
​

分治带来的两个实际好处

第一，复杂度隔离。调灯光不用关心山的噪声算法，跑批量不用打开灯光网络——每个车间内部再乱也不污染别人。第二，学习路径可分段。新手只要 SOP 就能做完第 1–4 章的全部实验；DOP/TOP/LOP 各自到对应章节再拆封。

⚠️ 常见坑：把大量变换逻辑放在 OBJ 层的 translate/rotate 上做动画，又在 SOP 内部依赖世界坐标做散布——两边空间不一致导致散布结果"漂"。约定俗成的做法是：形态逻辑留在 SOP 内部，OBJ 层只做最终摆放。

💡 关键直觉：Context 划分的依据是数据的时间性质——静态形状（SOP）、随时间演化的状态（DOP）、一次性的落盘任务（ROP）、可并行的批量任务（TOP）。

本节要点回顾

• 六层车间：OBJ 变换 / SOP 几何 / DOP 模拟 / LOP USD / TOP 调度 / ROP 输出；
• 跨层数据流：Object Merge、Sop Import/Dop Import、SOP Geometry、ROP Fetch 是主要桥梁；
• 形态逻辑留 SOP，摆放留 OBJ：空间职责分清，避免漂移 bug；
• 学习可以按 Context 分段解锁，先吃透 SOP 再横向扩。

下一节进入最小观察单位：点、线、面、属性——网络里流动的"数据库"。

延伸：一次跨 Context 的资产之旅

Contexts 的分工用一条"岩石资产"的旅程理解最直观：SOP 生成岩石几何并导出变形属性，DOP 用刚体解算它的坠落，LOP 把结果组装进 USD 场景，ROP/COP 收尾输出。关键在交接处的属性设计：

// SOP 阶段: 给岩石写入解算与渲染要用的元数据
s@asset_id = sprintf("rock_%04d", @ptnum / 100);
i@ fracture_level = chi("detail_level");       // 碎裂层级进入 DOP 读取
f@mass_density = fit01(rand(@ptnum), 0.8, 1.4); // 密度随机分布
​

跨 Context 传递的不是几何本身而是"几何+属性约定"——@mass_density 在 DOP 的 RBD 解算器里被读取为质量分布，在 LOP 里又被映射为 USD primvar。约定先于流程：先写好属性字典，再谈各阶段衔接，这是多人协作的程序化项目最重要的隐形规范。

延伸：Context 选择决策树

[该进哪个 Context]
要改几何本身 -> SOP (99%的程序化建模在此)
要时间演化/物理 -> DOP (或 SOP 内的 Solver, 轻量演化)
要灯光/材质/场景装配 -> LOP (Solaris)
要编排批量任务/农场调度 -> TOP (PDG)
要处理像素 -> COP; 要输出/渲染 -> ROP
反模式: 用 DOP 做静态分布(应 SOP+scatter),
        用 TOP 做单次计算(普通网络即可)
​

再补一条新手最实用的切换心法：不要试图一次性规划全流程的 Context 路线。正确节奏是永远从 SOP 开始（一切几何工作的默认故乡），只在撞到明确的墙时迁移——需要时间演化时进 DOP 或启用 SOP 内的 Solver，需要场景装配与灯光时进 LOP，需要批量时进 TOP。每次迁移都问一句"这堵墙是真的吗"，因为相当比例的"需要动力学"其实是几行 Solver VEX 就能解决的，"需要 PDG"其实只是三个 ROP 任务。Context 是为问题服务的行政区划，先有问题再谈区划，反过来的项目几乎必然过度设计。

再交代一个跨 Context 数据交接的实务细节：交接物除了属性，还要交接"解释责任"。SOP 写出 @mass_density 只完成了数据移交，DOP 端如何解释它（作为密度还是质量、是否乘体积）必须有双方都认可的文档——大型项目中多数"跨阶段玄学 bug"，事后追查都是解释责任的失焦：上游以为下游会归一化，下游以为上游已经归一化。属性字典若不包含语义解释与单位，它就只是拼写表而非契约；把"解释责任写给谁"写进字典，是数据观一章的规范在这里的又一次回声。