關於博客更新頻率低下，是因爲平時出的東西介於不好意思發和不能發之間
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爲平臺越後期一定會越苦逼。
隨想，記之。