关于博客更新频率低下，是因为平时出的东西介于不好意思发和不能发之间
Katana到目前位置不能看到VDB，所以灯光师打光靠蒙，或者efx出的时候得额外出一遍pointcloud，Katana中写到proxy中，但终归时间空间都有浪费。于是撸了一个可以在Katana中可视化VDB的Op。
对此我想先表达两点：
- VDB真让我感觉到了什么叫“High Level”，不只是汉语中的“高级牛逼上档次”，而是操作起来更加“高层”，都给封装好了，用这个库的时候不用去管底层的东西。而且并没有丢失执行效率。
- 上午处理杂事，基本就是下午和晚上排除吃饭锻炼时间，昨天还对Katana Op和OpenVDB的API都停留在草草读过Overview阶段，今天同时看着Katana和OpenVDB的文档撸出来了，我好牛逼啊。
明天优化。
关于Katana，一年之前对这玩意儿我是很抵触的，当时认为K能实现的Maya都能实现，Houdini就更不用说了，而且Katana甚至不能改模型，加上文档不完善和接口陌生，公司另外的一位同事在早期尤其也是痛苦不堪。但后来就是这位同事习惯了被Katana蹂躏后说了一句话瞬间让我觉得K是有必要的：“Katana作为一个灯光软件最大的优势就是不能改模型，不能做特效，这样灯光之外的环节出现问题时不用堆到后期解决，因为K中解决不了”。
确实，Katana和Maya、Houdini很不一样，K生来就是成为“平台”的，而往日因为RIG环节见长而成为平台的Maya要渐渐沦为“制作工具”级别，到这一步可替代性就很高了。于此呼应的是Alembic的设计哲学，没有骨骼、不能reference、没有材质信息，从功能上讲和obj、fbx相比是一种倒退，但从流程角度将这才是做了“模型数据传递”真正该做的事。于此相比Pixar花里胡哨的USD功能非常多，但注定不能再像往日的Renderman一样成为行业标准。
而且到了开发层面，现在的Katana对TD简直太友好（比如加点只需要加P属性即可）所有的东西都是location+attribute，达到了非常强的可检查性。查错效率和Houdini一个级别，整个场景在用户眼里都是透明清澈干净见底的，比maya不知道高到哪里去了，maya中你需要在意莫名其妙又看不见的属性（连操作法线都很困难，更不用说点速度）、属性连接（也因为这个原因渲染层时常悲剧）。而和Houdini相比又有LiveGroup（类似Maya Reference，houdini不能参考，组间并行协作是个问题）、场景中有层级这个概念（Houdini的不方便，不同层级相当于根本就不在一个场景），而且Houdini能做的事情太多了，如果以Houdini为平台越后期一定会越苦逼。
随想，记之。