Houdini节点分类与参数翻译

前言

众所周知Houdini是一款很强大的三维软件，在很多影视大片里都能见到它的身影。官方SideFX把它定位在3D Procedural Software for Film,TV,&Gamedev，其实Houdini本身的程序节点流与众多集成的CV功能早已超出了电影、电视、游戏领域范畴，就如UE4一样也不仅仅只是一款游戏制作工具。这一点官方SideFX已经认识到了，但是具体什么原因没有果断转型升级，我们也不清楚。就个人观点来看，如果SideFX再不拓展领域，开放开源的话，很可能会被UE5、Blender甚至Nuke等软件把流媒体、科研教育、AI等新兴市场给瓜分掉，从而让自己彻底沦落为一个插件公司。
其实从Houdini17.5开始,PDG的Top流以及CSV和Python3的格式开放，包括最近18.5对实时动补的大力支持，这些看似对传统特效制作没什么大提升的功能，其实是Houdini对新型市场的尝试与跟进，也是如今的发展趋势。对我个人而言，Houdini是一个很好的三维数据模拟与生成工具，对三维数据分析与处理有非常大的帮助。现在比较火的CV领域，有matplotlib和OpenCV，都是业界不成文的标准，虽然两者都有三维计算效果，但是专业可视化的三维数据软件全球还没一个大的统一。当然要成为这种软件前提必须是开源开放的，Blender或者UE5可能有机会，Houdini我不知道。(吐槽完毕)
为什么讲节点分类

用过Houdini的朋友都知道，每当Houdini跨0.5的版本升级后，都会有较大的改动，大家也经常吐槽Houdini每次更新后就得重学一遍。其实Houdini本身的设计架构决定了它的每次新功能嵌入都将会是一次大换血。因为Houdini所有模块之间的数据都是相通的，而且是以节点流的形式相连，这就好比人的经络，数据就如血液一般在其中有序循环，当新增一项功能，打个比方要给人加上一对翅膀，你整个骨骼与经络都得重新换一套，形成循环系统，以保证大脑的血液能流入翅膀。而Maya,Max的功能主要以插件的形式来增加，相当于给人穿衣服，每加一个功能就多穿一件衣服，穿多穿少不会影响整个人的身材，所以FumeFX里的数据不能直接作用在Yeti上。
Houdini这套循环闭合的经络系统，它的好处就是数据流通性，坏处也正是因为它数据一体化不好区分，容易导致眉毛胡子一把抓，不知从哪断到哪。Houdini是一个节点流软件，要使用Houdini模拟三维数据之前，必须得了解它的功能模块与节点构成。这是入门Houdini的第一步，很多人认为Houdini难学，其实第一步就迈错了方向，导致后面越学越懵逼。
Houdini的模块与节点类型

说到Houdini的模块有哪些，节点有哪些，估计有很多人都回答上来，包括一些老手。因为随着Houdini版本与功能的升级，它本身的模块与节点类型也在发生变化，所以它并非一成不变的。
Houdini18.5的功能模块

功能模块
上图就是Houdini的功能模块，我发现有很多人经常将模块功能与节点类型、节点功能混在一起来划分和描述Houdini。其实这是不科学的，也是比较混乱的。举个例子，SOP是干什么的，这个问题估计每个使用Houdini的人都会问到。然而在功能模块里我们并没看见SOP，甚至我们把Houdini所有节点找一遍，除了个叫Sop network的根本就没看见Sop。从一些老师口中或者网上查寻得到的答案往往是surface operator,What?表面操作?那这又是什么意思？更加蒙蔽。所以说仅从字义功能上去描述Houdini，是根本描述不通的，就像用"鲁棒性"去描述算法一样，不仅会让人觉得懵逼甚至还略带一丝好笑。 那为什么直白的字义就无法描述Houdini各模块功能呢？正是因为Houdini的功能在不断拓展，现有的功能已经超出了最原先的含义。surface operator是Houdini很早很早之前的版本所使用的功能描述，当时的功能估计也就停留在对物体的基本属性、形状上的一些操作，有点类似Maya物体的Shape，当然这也是我的个人推断，毕竟Houdini的那些老版本我也没用过。
Houdini官方是按节点类型而非模块的方式来划分描述的。在帮助首页里就有：
官方帮助页节点分类

对比上面两张图，可以发现这不是一一对应的关系，即模块分类 !=节点分类。但是乍看一眼，两者貌似又有重合的地方，这也是第一个让人比较迷惑的地方。而且我们还是不清楚SOP是干什么的。
第二个让人迷惑的地方就是：官方帮助里的节点分类其实本身并不是完整的。不是说官方节点分类不完整，而是说帮助文档里所显示的节点分类不完整。甚至因为历史遗留原因导致一些节点类型的名称与其底层代码类上的名称是没有一一对应的。Houdini真实的节点类型如下图所示(这里使用Houdini18.5版本)：
Houdini18.5节点分类

其实从节点类型上去学Houdini那将会是最轻松的方式，而且能随着Houdini的功能拓展而进行增量学习。尤其对于开发人员来说，能更好的理解各个模块之间的联系。话虽如此，但本来模块分类与官方帮助页的分类已经够绕了，现在又多了一些，会不会更复杂了？没有，很简单。我们只需要从节点层级上就能识别出节点类型，Houdini自身就是这么来划分的，而且每种节点类型从其外观上就有一定的特征。
认清Houdini节点类型

在之前，我们先用一个小脚本来获取我们所选择的节点类型与节点类型名称。
import hou  sn=hou.selectedNodes() for n in sn: print(n.type(),n.type().name())
各节点类型功能

1.Director

字面上意思是导演，其实就是唯一的root根节点hou.node("/"),在该节点下才会有ch,obj,img等功能模块节点。该节点是没有实体节点形状的，从程序角度理解就是每个工程的节点根路径。
2.Manager

管理节点，也就是各模块节点，能包含其他节点的容器节点.跟Director一样，它们也是没有具体节点形状的。但比Director要直观一点的地方就是，你可以认为节点面板里的每个分页就是它们。

Houdini中的Manager节点有:
hou.node("/ch")hou.node("/img") hou.node("/mat") hou.node("/obj")hou.node("/out") hou.node("/shop") hou.node("/stage") hou.node("/tasks")
3.Chop

数据通道节点，针对Houdini所有数据通道处理的节点，可以实现数据图形化。所有chop network下的第一层节点都是Chop类型。注意是 "所有"、"第一层"。下面图2中，即使里面有chopnet2,sopnet2这些网络容器，但是它们都是Chop类型，打印这2个节点的类型与类型名称,如下：
chopnet     #节点类型为Chop  节点类型名称为chopnet  sopnet
所谓"第一层"即当前网络层级，在图2sopnet1里面的节点，就不是Chop节点类型了。

图1

图2
chopnet  sopnet  vopnet  chopnet  image
4.ChopNet

所有带Net结尾的节点类型都是该类节点的网络容器节点。所谓网络容器节点，就是可以包含很多其他节点的节点，且该容器里创建的所有节点都是同一类节点。这里的ChopNet就是在/ch下创建的Chop network网络容器节点，有且仅有这么一个。
注意，在其他模块节点下创建的Chop network就不是ChopNet类型，参考Chop中的图2

  
5.Cop2

合成类节点，Houdini针对图像合成处理的节点，功能类似Nuke。凡是Img network网络容器节点下创建的节点，都是Cop2节点。合成节点很好辨识，一般都带缩略图的。

file  color
6.CopNet

在/img下创建的Img network网络容器节点，仅这么一个。

img
7.Object

物体节点，在/obj下创建的所有节点以及Object network网络容器节点里创建的节点都是Object节点类型，下图都是Object节点。注意Object network网络容器节点本身的类型则取决于它的父节点。

dopnet  subnet  chopnet  vopnet  cam  geo  hlight::2.0  agentcam
8.Sop

终于来了Sop。Object节点里除去所有是network网络容器的第一层节点，都是Sop节点，因为network网络容器节点里创建的都是它本身独特类型而非Sop类型，所以要除去。这也是官方对Sop的定义，虽然帮助文档上的描述也不全面，但这是唯一正确描述Sop的方式。因为Sop节点和功能太多，尤其Houdini17.5过后，Sop的功能界限越来越模糊，比如一些Sop节点本身会带有动力学解算，所以是无法从节点功能上去描述划分它的，而所有模块节点即Manager节点里创建的也不是Sop节点，所以也不能从模块上去描述它，只能以节点类型去描述。
下图是geo1里的节点，都是Sop节点。

chopnet  attribvop  dopnet  matnet
9.Dop

动力学节点，Houdini专门处理动力学解算的节点。所有Dop network网络容器节点里的第一层节点都是Dop节点。

popobject  popadvectbyfilaments  popsolver::2.0  output
10.Driver

渲染、输出节点。这个其实就是官方帮助页上说的ROP节点,以前可能只是为了渲染Render所以叫ROP,其真实节点类型名称叫Driver,可以理解为驱动程序，就是带复杂计算过程的节点。不难理解，因为Houdini现在的运算与输出已经不仅仅是渲染的内容了，比如CSV还有其他USD格式的输出，等等这些都超出了渲染范畴，所以用Driver更合理。所有/out以及Rop network网络容器节点下创建的第一层节点都是Driver节点。

agent  usdrender  ifd  sopnet
11.Lop

为USD流程操作的节点。所有/stage与LOP network网络容器节点下创建的第一层节点都是Lop节点,/stage是manager节点。同样，LOP network网络节点类型取决于它的父节点。

sceneimport  attribvop  dopnet  camera
12.Shop

材质shader节点。也是历史遗留下的节点，现在基本成为了外部渲染插件的材质存放根据地。所有/shop与Shop network网络容器节点下创建的第一层节点都是Shop节点。Shop network节点类型取决于它的父节点。

matnet  vopcvex  v_fluffy  v_ambient
13.Top

任务流节点，Houdini17.5新增的强大功能，PDG就是其主要核心功能，能进行多线程，多变量批量计算，可以认为是平行宇宙吧。所有/tasks与Top network下创建的第一层节点都是Top节点。Top network网络容器节点类型取决于它的父节点。

localscheduler  genericgenerator  geometryimport  waitforall  csvoutput
14.TopNet

在/tasks里创建的Top network网络容器节点，也是唯一一个。

topnet
15.VopNet类型

这也是Houdini历史遗留下的网络容器节点，用来计算vex的地方，也是可视化编程的地方。注意，在Vop network里创建的所有节点都是VopNet节点，不是Vop节点。

16.Vop

vex程序运行节点，这里的V是vex的意思，vex是houdini自身软件的语言，是仿着C++的阉割版C，为提升软件计算效率用的。官方帮助页里说它是Shader Nodes这也是让人迷惑的地方。因为以前vex就是主要执行shader的，而现在vex的功能已经被Houdini拓展到了全局。也有人会把V理解为view当做可视化编程来理解，其实算是歪打正着吧，毕竟Houdini是为艺术家而不是程序员设计的一款软件，其大部分程序功能确实是可以通过可视化编程节点进行实现的，就现阶段而言，要识别Vop节点通过判断它是不是可视化编程节点确实是一种非常直观又准确的办法。
所有/mat以及Vop network,Mat network网络容器节点里创建的第一层节点都是Vop节点。所以Attribute VOP与Mat network里的节点其实都是Vop节点。Vop节点有个很明显的一个视图特征就是横向节点流，如下图

geometryvopglobal::2.0  normalize  geometryvopoutput  snippet
到此，Houdini18.5的所有节点类型都讲完了。所以“为什么ROP network与/out一样，/stage与LOP network一样”，这类由于Houdini将节点功能与模块功能混在一起的风骚迷惑操作，大家应该理解了吧。
获取Houdini的各类节点

知道Houdini的节点类型，是玩Houdini的基本前提。Houdini本身还是一款应用工具软件，我们既不能无视它的功能也不能神化它的存在，它和其他DCC软件其实跟电脑里的计算器还有手机里的小程序一样，需要的时候就用，能解决一些问题就可以了，认清你想要的，你才不会迷惑。
Houdini18.5里每种节点类型下有多少个节点，到底哪类节点重要一些呢？我统计了一下。

结果可以看出Vop最多，Sop其次，然后是Dop，这三个占了绝大部分。怎么获取所有节点呢？方式如下:
import hounode_types=hou.nodeTypeCategories()   #获取节点各类型all_nodes=[]counts={}for nc,nt in node_types.items():    all_types=nt.nodeTypes()    #获取各大类下的所有节点(字典)    all_node_names=list(all_types.keys())   #所有节点名称    counts[nc]=len(all_node_names)    for name in all_node_names:        all_nodes.append(name) print(counts)print(len(all_nodes))
需要注意的是Director与Manager节点类型无法通过node.Types()来获取,它返回的是空{}，很神奇。
Houdini节点参数翻译

先上个效果图

怎么实现的呢？
思路是：
1.先获取所有节点类型
2.再获取每个类型下的所有节点
3.然后获取每个节点的参数名称，参数标签
4.将所有标签翻译为中文
5.将数据存入工具架
6.通过工具架对选中节点进行复制,替换新复制出的节点上的所有参数标签，得到翻译后的节点.
主要脚本操作如下:
收集节点参数信息get_data.py

import numpy as npimport pandas as pdnode_types=hou.nodeTypeCategories()  #返回的一个字典'''{'Chop': , 'ChopNet': , 'Cop2': , 'CopNet': , 'Director': , 'Dop': , 'Driver': , 'Lop': , 'Manager': , 'Object': , 'Shop': , 'Sop': , 'Top': , 'TopNet': , 'Vop': , 'VopNet': }'''all_nodes=[]   #所有节点名称parm_names =[]data_list=[]for nc,nt in node_types.items():    #nc为Categories各大类名称,nt为各大类的脚本类型    node_types=nt.nodeTypes() #获取各大类下的所有节点(字典)    node_names=list(node_types.keys()) #该节点类型下所有节点名称    for name in node_names:        all_nodes.append(name)  # 记录所有节点        node=hou.nodeType(nt,name)        plg=node.parmTemplateGroup()        f_parms=[p for p in plg.entries()] #获取每个最高层级参数        i_parms=[u for u in plg.entriesWithoutFolders()]  #获取非目录参数        f_parms.extend(i_parms)        parms=list(set(f_parms))                for i in parms:               p_name =i.name()  #参数名称            p_label=i.label() if i.label() else p_name  #当不存在标签时，就用参数名称            if p_name not in parm_names:                parm_names.append(p_name)                per_list=[p_name,p_label,name,nc]                data_list.append(per_list)                               print('all_nodes:',len(all_nodes))print('parm_names:',len(parm_names))data=np.array(data_list)df=pd.DataFrame(data,columns=['parm_name','parm_label','nodename','category'])save_path=os.path.join(hou.getenv('HIP'),'node_info.csv')df.to_csv(save_path)
输出的节点数据node_info.csv 结构如下

节点翻译 translate_node.py

translate_node.py
工具地址:
gitee:https://gitee.com/cgai/chinese-corpus-of-houdini.git
百度云:https://pan.baidu.com/s/1O4wVF4rOWfg5zRV6JpcifQ 提取码:t1iu
这个功能其实就是将节点上的参数翻译一遍，实现也不难，对制作与学习基本上也什么用，我做这个的主要原因是因为我一直没有找到CG专业术语的中文语料。Houdini是一个可控性很强的DCC软件，如果只是针对专业人员来操作，那么所有DCC软件用其本身的英语是最好的，但，假如不是呢？或者说如果我们要对DCC软件进行外部的交互式操作，比如手势、声控、语音这些，这个时候我们会发现，还得需要一套标准的专业语料，否则根本就不好识别命令意图。所以我把Houdini18.5里的所有节点的参数名称以及参数标签都导成一个csv，然后用百度翻译接口把所有标签机翻为中文，存为一个大Json也放在gitee里，机翻的肯定有很多不对，我稍微修改了几个，个人能力有限，还希望有兴趣的朋友来一起完善。哈哈，加油。