Psyop不用多加介绍，喜欢Motion的应该都知道这家公司。最近他们在Vimeo上放了很多作品和幕后的高清版本（请自备楼梯）。
我最喜欢下面这段《Rewind》，展示了这一令人羡慕的团队的幕后工作的整个过程。项目中break和项目后庆祝的一幕很平实，却让我很感动，很久没有好好体会这样的激情了。
update：由于Psyop的要求，我删除了优库上的转载，喜欢的朋友请自行上Vimeo。http://vimeo.com/6717553
update2：Psyop开设了优库频道，近期就会上传，请被墙住的爱好者们保持关注。http://u.youku.com/user_show/uid_psyop
1. Mindmaping & Sketch
某一天突然来了灵感，于是用Mindmap工具记录下来。后来还是改用纸笔画，因为可以随意画些东西，比较顺手。最初的概念是配合文字设置几个场景，最后因为时间的关系只简化为一个。
2. Making Markers and Tee
More...
view Barcinski & Jeanjean Website (Part1)
view Barcinski & Jeanjean Website (Part2)
另一个让人头疼的问题来了：文件量。搞一个高端的用户体验，在精度上总不能太寒碜，但是又怕用户等不了，怎么办？一开始加载的时候，他们为大家准备了一个 3D 弹球游戏，在一定程度上减弱了用户等待的焦虑感。但是网站内里太大太慢也是不行的，真功夫还是要拿出来的。
问题是背景，该用图片序列还是视频？一般经验告诉我们，像这种全景的东西，顺放倒放的，肯定都是用序列：flv倒放会卡。比如经典的IKEA网站用的就是图片序列。但是，这是过去的经验了。Barcinski & Jeanjean 告诉我们：jpg效率低，用 flv 才是高效，而且文件量小。How could it be?
OK，不知道大家是否有注意，在编码 flv 的时候可以设置关键帧距离。下图是AE里截的，Flash自带的编码器也可以设置。
![SNAG-000[2]](http://kevincao.com/wp-content/uploads/2008/11/snag0002.png "keyframe")
一般我们都用自动方式，所以没太注意。但是如果将这个值设为1，那么就等于每一帧都编码为关键帧。由于播放器在解码非关键帧的时候需要在这一帧之前的关键帧数据，所以顺放和倒放的区别就在于：当前帧依赖的关键帧是否已经读取到内存中。那么如果每一帧都是关键帧，那顺放和倒放并没有区别！这样的设置无疑会增加 flv 的大小，但是还是比 jpg 序列小很多。而且在执行效率上，解码 flv 比 解码 jpg 速度快！感谢技术的进步，我们终于可以和臃肿的 jpg 序列说拜拜了！
过去还有个经验是：先载小图，再载大图盖上去。但是在这个网站里并没有这种做法，对此他们的解释是：无法忍受freeze。因为大图片的解码过程会让 Flash Player卡住，通常情况下，用户不会注意到这瞬间的停顿。但是这里场景中结合了Papervision3D制作的纸，具有动态的物理效果，这样的停顿 就会很明显。因此他们采用直接加载最终精度的flv的办法。
还记得IKEA网站中独特的加载方式吗？那是一种将序列重新组织的方法。可以让用户边下载边体验，没加载到的部分是过不去的。Barcinski & Jeanjean 面临同样的难题：即便用了flv压缩，主文件还是有16m之大。他们想了个天才的解决方法，在这篇文章里他们画了一个圆饼图表述了他们的思路。我总结一下：首先是在这个网站里达到平滑顺畅的全景体验需要144帧，如果我们隔一帧就抽掉一帧，就能省掉一半的文件量。此时播放的原始帧序号为“1,3,5,7,9,11,...”。如果我们再重复一次上一步的抽帧操作，那就只剩1/4的文件量了，已经降到的3M左右可以接受的范围。经过两次抽帧的文件只剩下36帧，此时播放的原始帧序号为“1,5,9,13,...”。抽帧后的视频仍然是一个完整的全景循环，只是不够平滑而已。
方法出来了：我们先提供经过抽帧两次的视频，用户加载完这个文件已经可以正常的浏览网站。然后在后台继续加载第二次操作中抽去的那部分，当这个文件加载结束后，就已经还原了1/2的帧数。最后再把剩下的1/2——也就是所有的偶数帧组成的视频文件加载进来。
More...
Sea Orchestra: The Making Of on Vimeo
详尽幕后制作资料，相当值得学习。总结一下其中的执行流程：
然后就是一次两次的测试出片。看看我们的工作中缺少了什么，也就明白我们与精品之间的距离在哪里！
view Barcinski & Jeanjean Website (Part1)
接下来进入 Papervision3D 部分。他们开发了一个 AnaglyphView 类用于绘制立体效果。这个类包含了两个 Viewport3D（Viewport3D 是 Papervision3D 中绘制所有 DisplayObject3D 的对象，可以说是主渲染层，它是一个 Sprite 子类）。这两个对象分别用于渲染左右摄像机中看到的图像。
那是否也应该包含两个摄像机（Camera3D对象）呢？答案是不用，既然在成像原理中描述的摄像机位置是并排的，那么在程序中，只需要一个真正的 Camera3D，然后在每帧更新时，向左偏移渲一下，再向右偏移渲一下。如此得到的两个 Viewport3D 再用 ColorTransform 分别抽出需要的颜色通道，最后用 Screen 模式叠加在一起。
视频背景是分别加到两个 Viewport3D 的显示层级里的，对 Viewport3D 的颜色变换和叠加操作也能对其产生影响。
请注意：渲染的次数实际上增加了一倍，再加上层叠加运算，这种效果其实相当的占资源。所以不能用太复杂的3D对象，他们还将在 Blog 上继续分享优化方面的经验，一起期待吧。
在网站优化上，他们也有非常酷的Tips。注意到这样一个细节：主界面上环绕两人的纸是有前后遮挡关系的。虽然知道人像是抠像出来的，但是如何和 Papervision3D 中的对象产生遮挡呢？这是一个很有技术难度的问题。一般我们肯定会想视频要分两层，前景人像带通道。但是这是高分辨率的视频，带通道的话相当占资源。
点子来了：视频不能分层，那就把前景人像用矢量勾出来做遮罩。其实我们通常在做 media 遇到文件量限制的时候也用这种做法，关键是能减少文件量。在这里还能起到减去视频通道叠加造成的CPU运算增加的好处。方法是有了，可是144张图像要挖出来也是要吐口小血的。聪明人自然有聪明的做法：Flash 不是有 Trace Bitmap 自动转矢量的功能吗，只是勾个黑白图还是相当胜任的。他们还开发一个jsfl命令自动操作。点两下鼠标，喝两口咖啡的时间就可以搞定了，轻松惬意。遮罩问题解决，还有个遮挡问题。方法是把遮罩mc加入 Papervision3D 层级，设置它的z属性。前后关系就算出来了。接下来注意设置层叠加方式为 Erase，意思就是擦除，很明显了吧，遮挡就出来了。Erase 和 Alpha 叠加模式很有用，大家可以到 Flash 里面去试一下。
下一篇我将和大家分享一下该网站在文件量优化上的神来之笔。
