定位弹幕旋转的bug

[m13253]

关于这个问题本身（而不是具体实现）的讨论，请移步 https://github.com/jabbany/CommentCoreLibrary/issues/5

[m13253]

Bilibili已修复 5eff4eb19cbf283930bd5d4c48c925610cb7fa4a e49b2e1bb76acf47f1cffc60b2fe9ae67f1121c1 。 Acfun正在修复。

[m13253]

Acfun已修复 03434aa1547b34bcfd844680f98434eecf82f533 。

[m13253]

我哭了…… @jabbany

[jabbany]

3D太诡异了。。。

[jabbany]

卧槽这个视频还有代码弹幕。。。。真是绝妙的测试。。。。

[jabbany]

顺便，目前CCL确实能比较好的还原，所以你的计算是完全正确的：

http://jabbany.github.io/CommentCoreLibrary/experimental/scripting/ccl.htm 原来的代码自己不回收图形，目前我这个播放器还不能自动回收图形所以第二个截图就有残存图。。。

[m13253]

但是这个视频没有Y轴旋转和Z轴旋转同时不为0的情况。代码弹幕也只有canvas操作。 找代码弹幕建议去找2012年的第一届弹幕大赛。

[jabbany]

我这个目前只能支持到canvas弹幕水平。在高级的话有一个重大的设计区别。就是（因为安全考虑）我不能共享代码弹幕的命名空间，而B站播放器可以。

[jabbany]

顺便，代码弹幕强度测试最新的 av734560 是最牛的。尤其是后面。。。直接PV水平。。。里面用到的API我也就还原了不到 45%。。。。

[m13253]

命名空间和少括号的解析问题我已经从你的blog中了解到了。 用一个js解析js的库现实么？一般来说代码弹幕的代码本身不需要太重视优化。完全可以实现一个新解析器啊。 或者用跨域iframe把js访问的范围限定住。 另外，我觉得CCL如果打算做二次开发的话、可以考虑实现自己对CSS友好的弹幕，比如X轴旋转，做到弹幕中去可以有翻日历的效果嘛。 还有Google上对于sandbox javascript的相关文章是用什么解决方案？

[jabbany]

试过解析器、太慢，一点小code就得几秒几十秒。 现在 worker 模式就跟跨域 iframe 一样，速度还快一点因为在另一个线程里面跑。sandbox应该是没什么别的办法了，除非如果新的API出来。

嘛CCL二次开发就留给+☆的大家吧。。。光是实现还原就已经精一杯了。。。

[m13253]

Worker我了解一点，但是DOM操作要代理嘛…… 二次开发我的意思是说开发者利用这个库开发一个弹幕站。难道不可以考虑把X轴旋转也加入进去吗（而且用欧拉角来转而不是那奇怪的转法）。 Bilibili的XML格式扩展性太低，把 normal top bottom 写成 1 5 6 本来就是降低扩展性，XML里再套JSON更恶心。唉，先不说A站的JSON套JSON导致引号三转义的问题了。 我打算设计一个新的XML格式（不用JSON因为不能边下边解析），如果成功了就放出来。 如果将来封装成库的话，考虑一下ShadowDOM吧。不过Chrome里调试shadow让我很恼火，找了半天才找到打开shadow调试的选择框。

[jabbany]

嗯。可以。不过就得加一个新的mode。能直接给我 rotate3d的每个角度，和直接告诉我perspective或者再定义一个默认的，渲染会很方便。

B站那个我也不是很支持，但是历史遗留能怎么办。我这边正在开发基于JSON的格式当 CCL-Native（因为更加短小，适合传输）。不过mode用数字表示这个也无可厚非，从 padplayer 那个年代就有的东西。。。当年JSON还不是很流行呢，传输数据的大小，和比对 string 和 uint 的时间都是开发者考虑的。现在大可不必了。

shadow dom各种还不够靠谱的支持呢，稳定了我再去看看。

[m13253]

B站那个我也不是很支持，但是历史遗留能怎么办。我这边正在开发基于JSON的格式当 CCL-Native（因为更加短小，适合传输）。不过mode用数字表示这个也无可厚非，从 padplayer 那个年代就有的东西。。。当年JSON还不是很流行呢，传输数据的大小，和比对 string 和 uint 的时间都是开发者考虑的。现在大可不必了。

如果 JSON 可以像 XML 一样载入一半就开始解析我也会用 JSON 的。 B 站超过 8MB 的弹幕多了去了。 虽然 B 站自己也没有实现流式加载。 但是制定标准的时候为什么不考虑呢？ 而且现在的 HTTP 压缩也能把 XML 压得相当小。

[jabbany]

JSON也可以载入一半解析，有很多三方库都支持。效果跟 XML的局部解析一样，token模式读字段。

[jabbany]

JSON的缺点是没法定义规范协议，xml的话可以link到xmlns，然后用namespace里面定义允许的标签。这个JSON没有但是JSON也有支持schema，通过第三方库，不过我觉得这就未必要强制了，当个检测工具就可以了。

[m13253]

JSON决定。

[m13253]

Flash的旋转矩阵：

[ cos(rotY)*cos(rotZ)  cos(rotY)*sin(rotZ)  sin(rotY)
  -sin(rotZ)           cos(rotZ)            0
  -sin(rotY)*cos(rotZ) -sin(rotY)*sin(rotZ) cos(rotY) ]

ASS的旋转矩阵： 乘起来结果等于：

P.S. 终于知道如何用Wolfram|Alpha算矩阵了，手工算累死我了……

下一步应该是反解出对应的角度。有点困难，我试试吧。

[m13253]

Flash旋转试验 http://jsfiddle.net/m13253/m5m4r/ ASS旋转试验 http://jsfiddle.net/m13253/m9bFp/

[m13253]

试验算法 f95697edd84aefe8db3ad2e02364466253bc4218

[m13253]

我有了新的想法。 为了让透视更真实，我想用ASS自带的透视，可能ASS的透视和Flash的透视的FOV不同，但是比用shear来模拟透视好得多。

由于ASS的透视中心和旋转中心是一个点，所以我打算先做一些平移，把透视中心平移到旋转中心上再旋转。

大概流程是：

Flash: RotY * RotZ * Translate(X, Y) * Persp(FOV)
ASS: Transform(X-W/2, Y-H/2) * RotZ * RotX * RotY * Translate(W/2, H/2) * Persp(FOV)

算法未实践，等几天吧，6月考试月到了，要复习迎考。

[m13253]

啊哦，算错了……

trX, trY表示Flash输入的XY平移量，trx, try, trz表示ASS输出的XYZ平移量，Z轴平移用scale来模拟。

wxMaxima全过程在这里：https://gist.github.com/m13253/4a9d5b5d3dd4e7050f87 请导入到wxMaxima中帮找错。

[m13253]

又发现算错了。 Maxima工式的14行改成 matrix([1,0,0,0],[0,1,0,0],[0,0,1,0],[trx-W/2,try-H/2,0,1])。

[m13253]

修正公式到：

trX = (X*math.cos(rotZ)+Y*math.sin(rotZ))/math.cos(rotY)+(1-math.cos(rotZ)/math.cos(rotY))*width/2-math.sin(rotZ)/math.cos(rotY)*height/2
trY = Y*math.cos(rotZ)-X*math.sin(rotZ)+math.sin(rotZ)*width/2+(1-math.cos(rotZ))*height/2
trZ = (trX-width/2)*math.sin(rotY)
FOV = width*math.tan(2*math.pi/9.0)/2
scaleXY = FOV/(FOV+trZ)

[m13253]

Fixed in 7b185020c791c717dee1d170dde58305b346231c