上一篇知道如何制作threejs地球之后,就正式coding了,当然还是使用最心爱的Vue。本篇会有一些代码,但是都是十几行的独立片段,相信你不用担心。
布局
在进入本篇主题前,要简单看一下xplan中的自适应解决方案,即如何在不同尺寸设备中,都保证地球最合适的大小和位置,并且与其配套的一些图片(虚线的椭圆轨道、正中心白色的圆环等)都不会显示的错位。
xplan用的方式简单直接,固定大小内作布局,然后针对不同的设备尺寸进行缩放。
固定画布大小(375 * 600),所有和地球相关的元素都可以在这个范围内绝对定位,之后scale一下,保证在设备实际尺寸中是被包含(contain)的。这种方式比REM等其他的自适应方式更适合这个项目,毕竟threejs中不能使用REM单位。
感谢Vue,我得以将上面这个自行缩放的逻辑写成一个Page组件,之后再也不用操心布局问题了。
动画
xplan中的动画是最吸引我的地方,特别是地球放大,穿越云层的那一刻,想想还有点小激动。
其实之前看到过一些项目有做从外太空俯冲进地球表面的动画,但是那些基本都是纯图片制作的SpriteSheet Animation,动画的前进后退控制都很容易。但xplan项目中则不同,动画过程中需要控制多个动画对象,还要配合其他资源(音频和视频)。
分析
xplan中动画的逻辑是,在地球自转过程中,长按按钮,会依次发生:
地球旋转到目的坐标
地球放大(相机推进)到该坐标
到足够近的时候,播放云层穿越动画
云层穿越结束后,展示对应坐标的视频内容
任何时刻松开长按按钮,动画都会回退到地球自转的状态
为了方便讨论,将上面分析到的动画阶段命名一下:
地球自转过程:idle阶段
地球转动到指定坐标的过程:rotating阶段
地球距离被拉近拉远的过程:zooming阶段
穿越云层的过程:diving阶段
云层过后的视频展示:presenting阶段
具体分析几个过程:
在idle阶段,只要touchstart,就算你只长按了0.1s,那么rotating的动画就会完整的触发,然后状态跳回idle(rotating没有反向旋转)。如上示意图。
如果长按至了zooming阶段,松开手指之后,zooming动画会立刻反向播放,直至回到idle阶段。如上示意图。
如果zooming过程松开手指后,但是在离开zooming阶段前再次按下去,那么zooming动画会再一次正向播放。如上示意图。
diving阶段貌似又回到了和rotating类似的行为,就算中途结束,也会完成当前阶段的动画。但是和rotating不一样的是,diving阶段是有反向动画的。因此可以看到上面的示意图。
我在考虑的过程中,阴差阳错的误以为还有一个条件:即除了rotating阶段外,其他动画过程都可以随时进和退(上面的GIF就是我最终完成的动画控制)。这个给自己添加额外的难度,困扰了我很久。
分步实现:地球
我创建了一个Earth类,负责3D地球(包括光线,光晕,地表的云,浮动坐标点等)的创建和渲染,同时向外提供几个public方法:
setCameraPosition()
getCameraPosition()
startAutoRotation()
stopAutoRotation()
地球旋转到指定坐标点,其实就是设置camera的position来完成了。要有流畅动画的感觉,就使用tween去做position的更新。
new TWEEN.Tween(
earth.getCameraPosition()
).to(
targetCameraPosition,
1000
).onUpdate(function () {
earth.setCameraPosition(this.x, this.y, this.z)
})
关于tween和threejs动画,这里有教程。
其实最开始,这个Earth类没有这么纯粹,我在里面加了targetLocation
代表当前要转到的目标地点;还将tween的逻辑写在了这个类里面,让earth知道自己的目的地,控制自己的旋转动画。但后面发现对于这个项目中动画可控制的灵活性,这样封装在内部的动画逻辑,将很难写成清晰的代码,让其能和后面的云层动画统一来控制起来。
分步实现:云层
决定使用SpriteSheet Animation类似的方法做云层动画。其实有这样的库,比如Film(这个好像也是qq下面的团队做的),但是我还是更想从npm中install一个,由于没有找到合适的,就索性自己写一个好了,于是就发布了一个小工具——image-sprite。
操作由ImageSprite类创建云层对象,只用到了两个public方法,主要控制播放前一帧和后一帧:
imageSprite.next()
imageSprite.prev()
其实应该使用自动播放(play)和暂停(pause)应该也能完成,anyway
云层动画功能单一,想把它写的不纯粹也难。个人觉得coding的艺术就在于如何去划分这个纯粹。
第一印象
上面两个关键动画对象都实现了,用户的行为也很简单,只有touchstart和touchend,那么用一个touchDown
标志位记录一下就可以了。所以可以有一个中控器(controller),根据用户产生的状态,来调用不同的动画对象播放动画。
最先开始,脑子里面第一印象是下面这样的解决方案:
function handleTouchDown () {
touchDown = true
if (currentState is idle) {
playRotatingForwardAnimation(handleAnimationComplete)
} else if (currentState is rotating) {
playZoomingForwardAnimation(handleAnimationComplete)
} else if (currentState is zooming) {
playDivingForwardAnimation(handleAnimationComplete)
} else if (currentState is diving) {
playPresentingForwardAnimation(handleAnimationComplete)
} else if (currentState is presenting) {
// nothing to do
}
}
function handleTouchEnd () {
touchDown = false
}
function handleAnimationComplete () {
if (touchDown) {
// 找到下一个阶段,正向播放动画
findNextState()
play<nextstate>ForwardAnimation(handleAnimationComplete)
} else {
// 找到上一个阶段,反向播放动画
findPrevState()
play<prevstate>BackwardAnimation(handleAnimationComplete)
}
}
这样的方案能解决动画的大方向,即动画阶段之间的前进和后退,无法控制阶段内的每一帧的方向。而且也能看到,上面有太多的if判断,handleTouchDown
函数中的那种if情况,一定要避免,否则大项目中代码很难维护。这样的情况使用有限状态机模式或者策略模式都是很容易解决的。
第一印象告诉我:
要使用状态机设计模式
要从帧级别去做控制
状态机
写代码过程中肯定会遇到状态,最常见的状态会被记录成布尔值或者字符串常量,然后在做某个行为的时候对状态变量进行if-else判断。如果只有2个状态,还行,但是状态如果会变多,那么这样的代码就很难维护,将在主体中引入越来越多的if-else,越来越多的与特定状态相关的变量和逻辑。
个人非常喜欢状态机模式或者策略模式,它们本质都一样,都是使用组合代替继承,完成统一接口下的行为的多样性。最开心的是,这个模式将混杂在主体中的状态量和行为抽离出来,单独封装,让主体变的清清爽爽;还有,在JS中,你甚至连接口类都不用写!
举个简单的例子,上一篇中谈到的ImageSprite,用来将一系列图片进行播放,本质上就是绘制图片而已。但是我这里提供两种模式,一种绘制在canvas里,一种绘制在dom里(即image展示)。
不使用模式,可以简单的写成这样:
class ImageSprite {
constructor () {
this.renderMode = 'canvas'
this.context = null
this.imageElement = null
this.images = []
}
drawImage () {
if (this.renderMode === 'canvas') {
this.context.drawImage()
} else if (this.rendererMode === 'dom') {
this.imageElement.src = '...'
}
}
}
使用了状态机模式(这里的场景来看,叫策略模式更贴切,渲染策略不同):
class ImageSprite {
constructor () {
this.renderer = new CanvasRenderer(this)
this.images = []
}
drawImage () {
this.renderer.drawImage()
}
}
class CanvasRenderer {
constructor (imageSprite) {
this.imageSprite = imageSprite
this.context = null
}
drawImage () {
this.context.drawImage()
}
}
class DomRenderer {
constructor (imageSprite) {
this.imageSprite = imageSprite
this.imageElement = null
}
drawImage () {
this.imageElement.src = '...'
}
}
可以看到使用了模式之后,context
和imageElement
这样的和状态相关的变量,还有绘制canvas图片和绘制dom图片的不同代码,都从主体ImageSprite中抽离出去,单独的封装到了不同的状态对象中去了。
想想一下如果有第三种渲染模式,比如渲染在webgl中去,在不使用模式的代码中,要添加变量,要修改drawImage
函数;但是在使用了模式的代码中,现有代码都不用改变,只需要添加一个新类WebglRenderer
就可以了。这就是代码的可扩展性和可维护性的体现。(在Java中,还能省去代码的重新编译的过程)
整合
回到xplan的动画中去。在前面分析动画阶段的时候,其实就得到了每个状态,这些状态的统一接口就是向前帧动画(forward)和向后帧动画(backward)。
先不管每个state中逻辑该怎样,有了约定的接口,就可以把我们的中控器(Controller)写个基本框架了:
class Controller {
constructor (earth, cloud) {
this.earth = earth
this.cloud = cloud
this.touchDown = false
this.state = new IdleState(this) // 初始状态为IdleState
this._init()
}
_loop () {
requestAnimationFrame(this._loop.bind(this))
if (this.touchDown) { // 如果touchDown,则向前一帧
this.state.forward()
} else { // 否则,向后一帧
this.state.backward()
}
handleTouchStart () {
this.touchDown = true
}
handleTouchEnd () {
this.touchDown = false
}
// ...
}
因为要做到帧级别的控制,因此这里用到requestAnimationFrame来制作渲染循环。代码是不是很清晰简单!在渲染循环中,根本不在乎动画逻辑怎么执行,只知道touchDown了,就做向前动画,否则做向后动画,其他的都在各自的状态类里去实现。
下面拿两个状态类举例,其他的请移步这里。
IdleState
class IdleState {
constructor (controller) {
this.controller = controller
}
forward () {
this.controller.state = new RotatingState(this.controller)
}
backward () {
// do nothing
}
}
这里IdleState没有向后的动画,因此backward()
里面是空的;而该状态下的touchDown都会让earth开始旋转到指定坐标,而这个过程我们知道是RotatingState该做的,所以在RotatingState的‘forward()`里会去实现旋转控制。
DivingState
class DivingState {
constructor (controller) {
this.controller = controller
}
forward () {
let cloud = this.controller.cloud
if (cloud.currentFrame is last frame) { // 最后一帧时,进入下一个状态
this.controller.state = new PresentingState(this.controller)
} else {
cloud.next() // 播放下一帧
}
}
backward () {
let cloud = this.controller.cloud
if (cloud.currentFrame is first frame) { // 回退到第一帧时,进入上一个状态
this.controller.state = new ZoomingState(this.controller)
} else {
cloud.prev() // 播放前一帧
}
}
}
还记得么,diving是指穿越云层的那个过程。因此它往前(forward)是presenting,往后(backward)是zooming。而什么时候切换到下一个或者前一个状态,和往前或者往后的每一帧动画该如何执行,都只有这个DivingState知道,完美的逻辑封装。
完整的动画逻辑里,还包含着一些音频和视频的控制逻辑。比如地球自转时播放背景音乐,动画一旦开始则停止;穿越云层后播放视频,其他时候视频是停止的。这些逻辑,能够很容易的添加到上面的状态中去。比如在IdleState的contructor中播放音乐,在RotatingState的contructor中停止播放音乐;在PresentingState的constructor中播放视频,在DivingState的contructor中停止视频。
所以,一旦逻辑清晰了,代码清晰了,添加功能时显得很容易。
意外收获
完成上面的所有动画状态之后,我发现地球其实还有一个动画,那就是开场的逆向旋转并放大的入场动画。在上面做动画分析的时候,是把这个开场动画分开来设想的,但是上面的controller用上状态机之后,意外的发现这个入场动画可以以另外一个state放进来。
入场动画状态类:
class EnteringState {
constructor (controller) {
this.controller = controller
this.tween = new TWEEN.Tween({
// 起点位置
}).to({
// 终点位置
}, 1600).onUpdate(function () {
// 设置earth的缩放和旋转
}).onComplete(function () {
this.controller.state = new IdleState(this.controller) // 完成后进入IdleState
}).easing(TWEEN.Easing.Cubic.Out).start()
}
forward () {
TWEEN.update()
}
backward () {
// do nothing
}
}
最后将Controller初始化时的第一个state赋值改为EnteringState
即可。这真算是一个意外的收获,本来是打算单独(在controller之外)去实现的。
小结
到这里就差不多了,xplan主要的东西都讲到了,高(shan)仿(zhai)的过程还不错,了解了three,顺便还publish了几个小的工具库;有不足、也有超越。这个h5看似复杂,但是技术也没有多高深,主要还是创意,还是要给xplan点个赞!
最后,个人接h5,有没有个人或者公司啊,不要不好意思联系我~
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。