Houdini 破碎 & Unreal

Doris232

未完待更，忙，进度较慢哈
最近所学备忘和分享
主要记录如何将Houdini的破碎落地到手游项目中。
移动端对包体，性能限制较大，致使引擎的破碎插件并不能用。
那怎么才能以性能为出发点来达到破坏效果呢？Houdini试试看行不行。
说干咱就干：
1    -    锁定需求
对比Real-Time Physics & Pre-Simulated Enevts的优缺点以及落地的可能性
Physics,Niagara,Chaos & FBX,Alembic,VAT
“性能”是三种实时解算插件或系统不能被项目用的主要原因之一
Chaos还是Beta版，Niagara特效同学也没人会用且没有在项目里被用到，Physics就成了我主要尝试的插件，得出结论：简单易用不可控，当然最主要的还是性能
预烘培相对实时结算性能方面倒是友好的多，但会有三个指标来筛选出到底倾向哪种传输格式
性能、数据大小、流程难易度
性能无疑VAT是最好的，但流程麻烦点，T-Pose和位移、旋转图
FBX，Alembic都因为数据大小等原因不太受待见，这一块随后会出一个详细的描述
说到这里如果你对VAT是啥还不太清楚的话可以看看这位"YivanLee"超级大佬的文章
以下两篇足够：


后又和好友"iiif"（这货也是位超级大佬）沟通后更加确认这个方案应该是有一定空间能落地的


2    -    量化过程
我本身影视行业（Houdini菜鸡）出身，各种稀奇古怪的效果倒还不陌生
什么烟火爆炸小光效，龙卷风把房子卷了，大漩涡小河流灭霸毁世界，都还能试上一试
当然所谓艺术就萝卜白菜了 -_-##
吹远了..
需求明朗后就着手开始跑VAT流程，对未知的紧张自然是少不了，当然问题更多...
官方提供的一些组件或者工具有时候或者说大多数时候是有问题的，想要彻底解决问题还是要吃透工具的核心原理
Qualcomm官方其实并不推荐vertex shader重读取动画贴图
GPU clocks & Memory Bandwidth的测试结果喜忧参半，只是忧倒是有办法解决
更具体的优化方案以后再细说
这一块随后也详细说一下
3    -    出图装13
主要用来和项目组领导聊落地的事，所以效果要骚。

Doris232

的确手游限制太多了，做法非常新颖。学到了。