鹿鸣人工桌面简要分析 | 您所在的位置:网站首页 › ndf板是什么 › 鹿鸣人工桌面简要分析 |
前言 前几天鹿鸣发布了N0va人工桌面的宣发视频: 这个视频00:28处有一个非常具有误导性的场景:将图标从屏幕左边拖到右边,鹿鸣的视线也随之移动。这个片段在给观众施加一个暗示,即你可以和一屏之隔的鹿鸣小姐姐进行非常有趣的互动。但是很可惜,至少截止本文写作的2020年8月6日,这个功能还没有实装,至于以后会不会实装,我认为可能性不大。为什么我能如此断言,且看下文分析。我们从人工桌面的资源文件夹入手。 N0vaDesktopCache在N0va人工桌面的默认设置中,资源存储路径位于C:/Program Files/N0vaDesktop/N0vaDesktopCache,那我们就来看看这个路径里有什么: N0vaDesktopCache的文件夹结构player就是播放器,看dist的文件夹结构像是个网页,结合N0vaDesktop文件夹里libcef.dll (Chromium Embedded Framework) 的存在,基本可以确定这个东西就是在桌面上贴了个迷你浏览器来播放视频。 N0vaDesktop文件夹里其他东西基本上都是些各种各样的dll文件,再结合“资源存储”这个名字,以及10M级别的大小,大概可以猜测那些ndf文件就是鹿鸣的视频片段了。做阅读理解的话,ndf可能就是n0va desktop file或者n0va data format之类的缩写。第一反应当然就是试着拿视频播放器打开,可惜potplayer提示无法打开,ffprobe也提示输入流不正确。至于怎么处理这个我们后面再说,我们先看看state_config.json这个文件。 state_config.json这个文件打开之后是这样的: state_config.json一个由dst, event, src三项构成的三元组的列表。根据一些约定俗成的缩写规则,dst是destination目的地,src是source出发地,event就是事件。 dst和src的结构基本上是一样的,key基本就是这项的关键词或者说名字,video项里面出现的ndf文件基本验证了之前的猜测,children和ext是空的,我们后面再分析。而event里面就只有ext和key两项。 如果还感觉不到这个文件在表达什么,注意player文件夹下的另一组文件——dp-fsm-v1.0.x.zip。在我的电脑上x有12,17和19,显然是小版本号了。这些压缩包的内容不是很重要,但是文件名很重要——fsm,finite state machine,有限状态机。有过编程或者动画制作经历的读者应该已经能够知道发生了什么了。 有限状态机(英语:finite-state machine,缩写:FSM)又称有限状态自动机(英语:finite-state automation,缩写:FSA),简称状态机,是表示有限个状态以及在这些状态之间的转移和动作等行为的数学计算模型。 ——Wikipedia 举一个简单的例子,在息屏状态下按下电源键会让你的手机“转移”到亮屏状态,输入密码/指纹识别/面部识别通过之后会“转移”到解锁状态,而输入密码错误次数过多会进入短暂锁定的状态,等等。这就构成了一个有限状态机。当然阿B的互动视频也是个FSM,通过不同的选项转移到不同的视频分P上。 再回过头看state_config.json的内容,基本就能知道这个文件在描述什么了:当鹿鸣处在src状态时,如果发生event对应的事件,就会转移到dst所在的状态。这个FSM就包含了整个人工桌面的转移逻辑。我们把这个fsm以状态转移图的形式表现出来: 鹿鸣人工桌面状态转移图其中每条边上的内容(如BOOT、DEFAULT)就对应event项的key,而括号里的a,b,c,d这些对应的是children项。 不难理解,BOOT事件在程序启动时触发,DEFAULT则是默认的跳转。 TIMER意思是计时器,我们在js文件里面搜索timer,有以下几个相关的函数:startTimerEvent、onTimerRandom和onTimerDefinite。 startTimerEventonTimerRandom & Definite变量名经过混淆,不过还是可以推测,startTimerEvent会启动一个延时,时长为time后的区间中的一个随机值,延时结束之后会根据type的值去调用相应的onTimer函数。如果是随机(Random)类型,则根据设定的概率(Probability)进行状态转移;如果是确定(Definite)类型,则直接跳转。 COVER是覆盖,WAKEUP是唤醒,虽然在js代码中没有找到相应的有意义的内容,但是实测之后发现,在鹿鸣的桌面上放一个最大化的窗口即可触发COVER事件,而把这个窗口移除或取消最大化则会触发WAKEUP事件,后面的参数应该和TIMER部分意义相同。 对children的处理代码我没有完全理解,从片段上拼出来的感觉是在各个children对应的素材之间随机切换播放。 经过以上分析我们可以把状态转移图整理成下面这样: 整理之后的转移图可以看到里面并没有能够追踪光标移动的部分,这也是为什么我在开头作出“误导”这一判断的原因。如果要加上视线追踪光标的功能,按这个框架,一种可能的实现方案是以鹿鸣的头部为原点,按角度对屏幕分区,然后计算光标所在的分区,分区切换时的过渡动画使用眨眼,同时对鼠标轨迹平滑+降采样,限制分区切换的频率等等。这么做会导致所需的素材数和状态数都增加很多(现在只有10个主状态16个素材,要是对屏幕分16个区那就直接翻倍了)。除非米哈游能有更好的实现方法,否则我觉得不太可能加上这个功能。 另外经过测试,对state_config.json目前没有任何校验措施,直接修改替换即可实现自定义的转移逻辑。 NDF文件前面提到ndf文件就是人工桌面的视频素材,但是用播放器打不开,那么我们用16进制编辑器看一下内容: 15963775541459_182.ndf重点关注蓝框的内容,ftyp isom iso2 avc1 mp41,基本可以确定这是个mp4格式的视频素材。为什么打不开呢?我们可以看看一个正常的mp4文件头是什么样的: 一个正常的mp4文件注意到在文件最开始的地方,ndf文件多了两个字节。我们把这两个字节删掉试试: 去StackOverflow上面抄个python脚本然后用potplayer打开可以播放了。 那么把上面的转移逻辑和ndf文件中拿到的视频素材组合起来,就能得到这样的一个互动视频: model.dd其实人工桌面的主体基本上已经分析完了,不过还有个model.dd文件没处理,我们打开看看: model.dd的开头一部分看着像一堆乱码,不过其实是base64编码的产物。我们解码看看: 站长工具base64编解码是个json文件。整理一下: video_groupssweet_conftriple_list分为video_groups、sweet_conf和triple_list三个部分,其中video_groups的内容名字对应鹿鸣已有的一些投稿,sweet_conf对应人工桌面的视频素材,而triple_list则和state_config.json的内容相同。猜测在后续版本中会在人工桌面中加入播放鹿鸣的投稿视频的功能,不过……说不定我们现在也可以呢?嘿嘿嘿。 结语本文从N0va人工桌面的素材文件夹入手,分析了N0va的控制跳转逻辑,获取了N0va的视频素材。N0va人工桌面保持了鹿鸣投稿视频中高超的建模、动作和渲染水准,同时使用FSM跳转播放预制视频素材的方法来赋予人工桌面一定的内容丰富度,避免使用者快速失去新鲜感。但这样的设计灵活性有限,如果要实现更高的互动性,可能会带来大幅的资源消耗和逻辑设计难度提升。期待后续版本的表现。 |
今日新闻 |
推荐新闻 |
专题文章 |
CopyRight 2018-2019 实验室设备网 版权所有 |