Unity多媒体展示项目经验分享-ImageEffect+动态绑定+网络通信
<ignore_js_op>
“海尔科技展墙”是去年年初我们为上海家电博览会制作的一个多媒体展项，有限的工期以及对画面的高标准要求为我们的制作带来很大压力，现在来看不得不庆幸当时选对了工具——Unity“简单易用、所见即所得”的特点让我们感受颇深，并且受益匪浅，在此分享一些经验。首先看视频：叠加Unity自带的ImageEffects短暂的开发周期迫使我们需要在有限的时间调试出漂亮的视觉效果，而Unity也确实足够快——通过叠加组合Unity自带的一系列ImageEffect（全屏Shader特效），没有编写一行Shader代码，我们顺利调试出了带有足够科技感的视觉画面，通过下图可以清楚地看到一幅平淡无奇的字符流画面如何被一层层ImageEffect装饰成最终的效果：
<ignore_js_op>
其中特别值得一提的是Fish Eye特效在这里发挥了非常神奇的功效——扭曲的画面创造出一种曲线字符流的错觉，但实际上所有的字符流在场景中都是平行直线移动的（见图1），省去了编写曲线运动程序的时间。
最后一个Sun Shafts特效是由音频控制的，随着节奏跳跃的光芒是在测试时一边听着音乐一边左右拖动参数滑竿而找到的灵感——所见即所得、实时调试不仅仅是快，而且能够让人发现更多可能性。
最后加入运动模糊特效，不仅增强动态，而且可以用来强调静态的前景：
<ignore_js_op>
灵活组合Unity自带的一系列ImageEffects可以带来意想不到的结果，而且关键是这个过程够快、够直观，对于周期普遍较短的商业项目而言非常实用。
除此之外Color Correction等颜色调校ImageEffect还可以用来在展会现场的设备上进行色彩调试，让画面色彩不再因为设备质量问题而产生过大偏差。
变色，而且不破坏Dynamic Batching画面中所有的字符流都是通过Unity的三维文字（TextMesh）来实现的，其支持动态绑定（Dynamic Batching），使得数万的Draw Call可以被减少到几百——但前提是大家共享同一材质。科技展墙中我们设计了两版主题颜色（绿色科技）和（VI配色），如下图：
<ignore_js_op>
两个配色之间需要平滑过渡，当每一个字符都调用renderer.material.color来改变颜色的时候，Draw Call迅速上升至几万，FPS惨不忍睹——因为renderer.material在调用时会自动创建一个副本，造成每个字符之间的材质不再相同，动态绑定无法执行。而renderer.sharedmaterial虽然不创建副本，直接改变共享材质的属性——但是“牵一发而动全局”导致我们失去了对每一个字符的单独控制能力。
为了解决动态绑定和独立颜色控制间的矛盾，我们不再通过修改材质颜色来变色，而是通过为文字设置不同颜色的材质来实现变色的效果，具体如下：
- 为渐变过程中每一个颜色创建一个对应的材质并缓存起来（30个）
- 渐变时根据渐变的进度来为文字设置其中某一个材质。
如此一来场景中最多同时存在的材质实例也只有30个，这使我们在色彩切换时也可以把Draw Call控制在3000左右，在高清画面下实现60FPS已经足够了。
Unity与其他程序进行网络通信这个项目中有两件事不是Unity做的：
当时Unity还没有能够读取Kinect画面的Plugin，我们需要通过来读取Kinect画面，处理完毕后再回传给Unity。首先想到的解决方案是osc，因为此前osc已经用过多次——但显然osc不是为这种不间断、大量原始数据传输而设计的，不是慢的问题，而是丢数据。于是换用UDP，轻松胜任，分享接收UDP数据的脚本： <ignore_js_op>
(724 Bytes, 下载次数: 57)
音乐播放Unity虽然可以，但是频谱分析不了，所以还是请OpenFrameworks代劳。由于回传的数据只是声音强度（一个整数足以），osc是不二之选，分享当时Unity端使用的OSC脚本： <ignore_js_op>
(7.89 KB, 下载次数: 38) 综上，Unity的Plugin功能已经使得它的可扩展性达到极高的水平，但网络仍然不失为一种很好的数据传输方式，毕竟开发Plugin的时间一般会更长，而且将程序功能分开在后期的调试中也更容易一些。
原文地址：
本项目更多图片和介绍：