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 View full article »
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——也就是所有的偶数帧组成的视频文件加载进来。 View full article »
