专业的影视特效与合成师或团队是如何组织管理如 houdini、Nuke 软件下的大 ...

如题，当制作环节出现大量节点时，为了其他特效与合成师或其他环节的工作人员查看方便，配合软件的一些整理功能，有没有一些科学的整理方式？最好请举例，谢谢~
--
本题来自知乎圆桌 »动画电影动画人，欢迎关注讨论。

【1080p】《天谕》云垂正史CG首曝 多文明共襄盛世，这个片子的制作过程简直就是从头到尾在梳理修改替换大量节点.片子除了刚开始入画，后面根本就是一镜到底。
因为这个片子的正片是把所有模型贴图导入nuke，然后在nuke里调材质、打灯光、做特效、并直接合成输出的。
光片子里的每个画面的模型节点都好几百个，每个篇章都有5~·10个小效果，每个效果都用了几个到几十个不等的节点。做大最后汇成了一个庞大的nuke文件的节点网络。
在做之前我们先是按画面先后给节点分区域用Network Box上色从左向右排列，每个区域的贴图动态处理节点按效果从上到下排列再上Network Box..最后所有的连到一个scenes节点上渲染出来,再在渲染出来的后面按镜头从上往下排列添加渲染后的节点,
来填坑了

先放一张全景图，摊子铺的实在太大，导致Network Box里面500px大的文字标签也缩的看不清了。

这个是其中第二三幅画的节点图，首先里面有两条竖着的主干分别是sh02和sh03的模型节点。然后围绕着这两个主干添加效果，每个效果一个Network Box病添加文字注释。最后连到一个scenes节点上。

然后所有镜头的scenes再连接到一个最终的scenes上。

最终的所有的模型贴图在三维视图中的效果。(内存君每次顶多撑半天就爆了，求教怎么释放nuke 的内存)

这个是sh01的节点图，竖着的那条是给这一镜所有模型依次上材质的节点。这个是从maya中读取信息用python生成的。

上面那些黑线三角的尽头就是贴图，比如这个。

连好后在三维中的效果。

整个场景的烟雾都集中在左边这个列了。然后再依镜头从上到下排列Network Box
每一个烟雾面片的节点都是按照再画面中的上下左右排列的。

把所有灯光集中在一起。这里的灯光主要是为了给飘动的旗子和披风加上立体感。

所有烟雾来个合影（到这里内存君快爆了）
最后来个反例

这个是我同事摆的飞船上喷出来的烟，完全不知道哪个是哪个。迫于周期实在太紧，后来也只能这样了。不过后面动画每次修改，都要他自己来改，哈哈。（基本都是周末或者晚上）
之所以这样首先是因为工期实在太短了根本来不及渲染。而且所有环节是并行的。当初在试用katana的时候发现的这种流程感觉非常适合这个项目，但是katana又用不起来只有在nuke里做了。况且也没有人家那么土豪，所以渲染也定在了nuke里。
一直到最后几天模型贴图动画还一直在修改中。在传统渲染中一帧要几十分钟到几个小时，况且这个项目里又大量的透明贴图，试了用ar渲染在后来的烟雾和水的合成中各种黑边。
这些在nuke中都比较容易解决，而且渲染时间是1到10分钟不等。还能实时更新模型材质动画。

管理节点其实各个软件都差不多。我来讲讲Houdini中的一些经验。按 LZ 的意思分两个方面。

1.制定规则

2.通过工具管理

规则：
没有一成不变的规则，根据不同情况，不同公司，不同流程，不同项目。规则都可以是不同的。一般是要通过 pipeline 来制定命名和管理的规则。方便程序化的操作节点。

不管是什么样的规则，都有一定的原则。那就是节点图的可读性和可程序化。说到可读性，一般比较规范的命名规则是这样的，保留原节点名，后面加描述如图，这样即使只看图片也能明白节点的意图。

可以利用节点颜色来加强可读性，比如输出的节点都用绿色，输入的节点都用黄色。

利用Network Box 对节点分组。

一组节点如果功能是独立的并且会反复会利用，就可以做成一个数字资产（houdini digital assets） （.hda） 可以储存在 OTL里（Operator type libraries）
这里有一个误解，有些人喜欢用subnet把节点打包，而且包中有包，处处是包。节点树看起来变得很少很整齐很高端，但这样会严重降低节点树的可读性。举个例子，如果你看到一个参数上写着这样一个表达式：ch("../../../../../../subnet1/subnet3/subnet1/geo1/point1/tx")，酸爽么？除非是可以做成hda的情况，不然不建议这么做。

用工具管理节点：
一般大公司都会制作很多shelftool去程序化的管理节点。
比如说载入资产的节点组，导入导出的节点组，根据制作内容自定义的节点组。批量制作任务时候，删除创建节点组，解算，发任务，都可以通过python 或 Hscript 制作shelftool 去操作。甚至一些简单任务可以用工具来创建空文件，节点，执行任务，删除文件。整个过程只有一个python 文件，和得到的结果。这样做的好处是，不依赖Houdini的版本。不用跟着软件更新而更新编辑好的文件模版，或hda。另外还可以通过工具快速导航 ch("../../../../../../subnet1/subnet3/subnet1/geo1/point1/tx") 这样的表达式。特效师之间相互发送节点等等。

Houdini中管理大量节点的3个法宝：Network Box，subnet 和 otl
通常一组节点的目的是完成一个功能，这时可以用 netwrok box和subnet，我更喜欢用subnet，因为命名、移动和修改都非常方便，缺点是只提供一个输出，并且增加了一个层级。
当这组节点会需要被重复在多个地方使用时，subnet会更好些，上面也说了，它复制和移动比较方便；而当这组节点要在不同的文件中重复使用时，或者在相同文件中调用超过4次，我推荐用OTL，otl相当于编程中的函数，可以在程序多处调用，维护和更新也很方便，并且支持python module脚本编写，可以拓展其功能。

大公司都有专门工具的，而且有Qt下的python同时连接管理不同软件

从制作人员的角度讲，最重要的一点，也最容易随手做到的，就是要合理摆放工程节点，尤其是同一窗口下会出现极大量节点的nk工程。即便每个人摆放的方式都会依据个人原因和工程需要而不同，但是调理一定要清晰。每个工程都有其内在的逻辑关系，节点摆放的清楚，顺序明确也方便制作人员在一段时间之后重新打开之前的工程文件时能够通过分析节点理清工程制作的顺序。相比Nuke，H还多了层级概念，也是一个辨别逻辑主次、运算顺序等节点之间的关系可以。见过有的公司有时还会有节点的固定摆放和连接要求，保证如果其他人接手上一个人的工作，能够有效读懂上一个人要干什么。
H和Nuke都可以以自定义的方式把一群节点选择在一个便签里，便于集体管理，同时如有特殊说明还可以写贴士，具体说明这个区的节点作用。
还可以通过给节点命名，标注其在此工程里的具体特别功用。
所以总的来说，制作的时候做好标记、注释和有条理的摆放，都可以帮助有效管理大量节点。