Sprite Animation Editor输入框精简

[nantas]

看图：

[jwu]

Preview Speed 并不是无中生有的产物，当初在雨血项目中，他们调节好了Speed以后，希望能够调节在原动作速度调节下，加入 Time.scale 等动作的慢镜效果，而频繁改动原动作速度在实际工作中反而不太理想。(Unity的 Animation Preview Window 里也提供了 Preview Speed 的选项)

Length 和 Speed 提供了两种输入的可能性，为何不提供给用户更多的选择呢？这当中的换算由工具来承担，并没有影响。无论length还是speed其实都是第一版里用户的需求。

Frame Rate 还是有必要的，Unity之所以把Frame Rate 屏蔽掉，原因是这个选项是由Raw Animation 的制作工具勾选生成的。

[jwu]

ScrollBar 确实有加入的必要。

[nantas]

第一，preview的速度不保存，所以跟你在editor里先把速度改慢调节，然后再改回正常速度是一样的，而且Speed的问题在于改了以后也不能在editor里预览，所以完全不实用。

第二，Length的问题也在于不能预览，如果改了以后能直接在editor里看到区别，那么留着也无所谓。

第三，Frame Rate必要在哪？为什么不能通过改Speed来达到同样效果？还有，我们做的项目里有哪个是需要改Frame Rate的么，如果要改，为什么不能用global参数来改而是每个clip单独？

其实总的说来就是太多属性修改以后在editor里看不到效果，所以用户会比较迷惑。建议减少让用户迷惑的点，体验会好很多。

[jwu]

前面两个问题争议太大，需要在仔细想想。

关于 Frame Rate，他是一个精度值。Frame Rate 关系到你一帧所占用的秒数。所以他关系到你 Event 插入的精度，以及一张Sprite Animation 占用的播放时长。

这是一个提供给 Advance User 的调节参数，一般默认为 60.0f。当你设计的游戏确认是 30 fps 时， Frame Rate 高于 30.0f 就失去了意义。所以对于那些设计了 30fps 的游戏，会将 Frame Rate 下调到 30.0f。

关于 Frame Rate 对效率的影响，就目前版本来说上调下调都没有影响，还需要在思考是否可以利用 Frame Rate 来做 Event 和 Sprite 切换的优化。毕竟他也关系到 Sample Rate。

我觉得如果对于有困惑的参数，可以将它归入到 Advance 栏目中，这样普通用户自然就会忽略这些选项。

[jareguo]

（我的建议是优化编辑选项。把PreviewSpeed放到PreviewScale旁边。把Length和FrameRate以及Frame放在同一行。把Speed放在别处）

确切来说，帧动画和帧事件都取决于FrameRate，因此FrameRate对效率会有很微小的影响。 具体计算的方式是，frame = (int) (time * clip.frameRate); frame如果改变，动画和事件就会重新计算。所以frameRate越大，frame改变的就越频繁，潜在的CPU消耗就会有很小的增加。

但关键是，FrameRate就应该对应于设计师做的动画的帧数。否则拖到animation editor后，同一张动作会显示成好几帧，编辑动画和插入事件就会很让人困扰。例如羊跑步本来15FPS就够了，那拖到editor后，如果FPS设成60，就需要手动给每一帧复制四份出来，才能看上去保持不变的速度。

而且不论app的fps多高，每个动画的帧率都可以是不一样的。简单的动画10FPS就够了，幅度较大的可以增加到30FPS，因此分开设置是有必要的。

[nantas]

Jare说的不成立，第一如果改FrameRate，也没必要把同一动作显示成好几帧，我们有Frame[i]这个数组控制不同的贴图，不会因为改帧率就改变数组的大小。至于简单和幅度较大的动画完全可以通过控制每一张贴图的帧数来达到，改FrameRate只会很乱。

总的说来，参数越多，用户收到的反馈就越不直观，出错的可能性也越大。