技术讨论 {构建} 一部术力口介绍音乐影像
9ma_P
2026年10月12日 00:57

作为专辑数字版发布的宣传,制作并投稿了如下的音乐影像「术另的59次描摹」DISC1:再造介绍。

同时,这也是我第一次采用大模型辅助编程、基于 Web 技术栈来实现音乐影像。

关于这部音乐影像

这部作品是作为歌声合成独立音乐投稿活动·术另 的“专辑再造介绍”来制作的。

什么是“再造介绍”?制作的原因?

术另 合专共包括59首歌,分为四枚 CD。

“再造介绍”是邀请参与活动的 读川_P 读川_P积雪云snowcumulus 积雪云snowcumulusZill温记 Zill温记三位创作者、再加上我自己,分别根据四枚 CD,把握每张碟片收录作品的整体性、细心体会收录在各张碟片中的大家的作品的独特表达,制作的四曲介绍音轨。

制作“再造介绍”音轨有如下五个方面的考虑:

  1. 达成创作者、创作间的交流与连结,传递尊重和真诚的回响;

  2. 合专的表达多种多样,虽然已经根据曲风和表达主题等,大致分为了四张 CD,但听众仍然可能难以真正进入一丛作品的群像。概览式地为每张碟片中的作品提供引入,以期帮助听众大致进入本张 CD 的氛围,有机会提供更好的收听体验、进一步增强整张合辑的整体性;

  3. 合专收录的曲数较多,即便采取多碟面设计、碟面拼图等美术上的“连结点”,合理排布乐曲顺序等方式,仍可能有部分乐曲无法被充分地收听。制作“再造介绍”音轨,可以延长内容的曝光、更充分地将这张四小时的音乐合辑摊平展现在听众面前;

  4. Dizzylab 平台目前仍然不支持分碟上传,但专辑在设计时,是以每张 CD 为单位设计收录顺序的。需要创造一条明显的界线区分各枚 CD,以实现和实体碟类似的段落式的收听体验;

  5. 作为数字特典发布,能够提高 Dizzylab 平台的兑换率和收听率。

“再造介绍”的音乐

我在制作 DISC1 的“再造介绍”音轨时,一个基本的想法仍然是制作类似“虚拟之声”的 Plunderphonics(掠夺采样) 音乐,全景式地从相关作品的音乐和文字中采样拼贴——用已有的声音创造新的声音、用被创造的概念创造新的概念。

因此,音乐的部分,从专辑中截取了部分采样作为素材。

我不太愿意全曲皆制作成配乐诗朗诵,一个原因是等到我需要自己来制作这条音轨时,另外三位创作者已经这么做了;我觉得不只有这样一种答案,因此仍然写作了部分人声旋律。但四份作品依然都比较贴近所谓 Folktronica 的感觉。

“再造介绍”的影像

概念设计

歌词、音乐均“采样”自 DISC1 的各首作品,充盈着每位创作者、每份创作的影子。

文字流动、采撷、折射反射、回响 是我最先想到的关键词。介绍音轨的歌词采样拼接自大家的音乐和文字带给我的概念、印象;影像的正中间,涌出从头到尾连续播放的大家作品的歌词;当出现被引入介绍音轨歌词的字时,取出并填充入介绍音轨的歌词展示;同时,对应的字成为新的玻璃砖,透视、折射、反射大家的文字,映出新的光线。

玻璃材质好像有形、却又只因为大家的表达才得以有形,又不断通过光的变化,创造着大家的表达的新的投影、而投影构筑了形体——这样的特性让我觉得很符合“再造介绍”的主题。

技术实现

实现影像的方式有很多种, 在 Blender / AE 等视效制作软件中,结合 3D 功能,也可以在一点点表达式的帮助下,完成上述的实现。

但该项目:

  1. 希望实现可交互性;

  2. 希望创造某种视觉呈现模板(因为还有另外三张音轨);

  3. 希望充分地保持参数性;

  4. 包括对歌词等的数据处理任务;

  5. 为了轻量、便捷地与大模型交互,以提高实现速度(仅仅用一个晚上制作音乐、影像的全部)。

因而选择采用某种编程方式。

用于交互式的数字媒体艺术的编程语言和相关工具链已经有很多选项,例如 Processing 等。然而,本项目最终选择的技术栈是 Web (JS+WebGPU) 技术栈,这是出于以下的考虑:

  1. 术另合专需要制作信息专页,而相关网页也需要视觉呈现,直接采用 Web 技术栈,能够实现设计实现的 可移植性。同样的代码直接运行在浏览器中,能直接作为可交互的视觉呈现;作为宣传视频,则由浏览器渲染并导出即可;

  2. Web 技术栈的 可操作性 便于引入、聚合更多的相关数据,如后续页面中听众提交的评论、浏览/收听统计等,皆可以方便地即时接入存储、分析和使用,进一步完善整个项目的呈现;

  3. WebGPU 作为网页端渲染近年成熟并推广的新技术,能够在大多数现代设备上提供性能足够的渲染体验,不会对上述概念设计构成实现上的阻碍;

  4. JS 运行时是我的专业,我想尝试技术辅助的艺术表达。

附录:和大模型一起“构建”这部影像

作为参照,此处附上交互历史。

框架

→ 建立一个空的nuxt项目,引入gpu-curtains依赖

已在当前目录创建空白 Nuxt 项目。

→ 增加tailwindcss依赖,选用zeoseven的ibm plex cjk可变字体

ZeoSeven 上 IBM Plex Sans 的可变版仅覆盖西文;CJK 可变版是其衍生字体。你希望采用哪一种?

  • 榫黑体:IBM Plex 衍生可变字体,覆盖简繁中文和日文(推荐)

  • 械黑:IBM Plex 衍生可变字体,覆盖简繁中文

  • IBM Plex 原版:西文可变字体搭配 CJK 固定字重字体

→ 榫黑体

已完成:

  • 安装 Tailwind CSS 4.3.3 并接入 Vite。

  • 按你的选择,通过 ZeoSeven 加载榫黑体可变字体,字重范围 100–700。

  • 已设为全局默认字体及 Tailwind font-sans。

  • npm run build 验证通过。

Demo

→ 在web页面中间实现一个正方形画布,接下来所有的渲染都在这里进行

已实现居中的正方形画布:

  • 随窗口缩放,四周至少保留 16px。

  • 黑色画布、深灰页面背景。

  • 分辨率适配屏幕像素比。

  • 后续统一在 #render-canvas 中渲染。

生产构建验证通过。

→ 接下来所有的参数变化都是摄像机的

明白,后续参数变化统一作用于摄像机,画布和场景对象保持固定。

→ 以画面中心为原点,鼠标的xy坐标决定了摄像机的x、y方向的速度分量。z速度保持一个常数。 摄像机每30帧在摄像机的位置,平行于xOy的平面上生成一个汉字,汉字的坐标即为当时摄像机的坐标。 汉字从三字经里依次选择。 摄像机一直在运动,因此每个字离摄像机的距离都在变动,离得越远,字的透明度越低,到一个阈值则消失。

已实现并通过浏览器运行验证:

  • 鼠标相对画面中心的位置控制摄像机 XY 速度。

  • 摄像机沿 +Z 匀速移动,朝向 −Z。

  • 每 30 帧在摄像机当时的位置生成一个汉字,按《三字经》顺序循环。

  • 汉字固定在平行于 xOy 的平面上,随距离增大淡出,距离达到 48 时移除。

生产构建通过,浏览器未发现运行时错误。

→ 运行测试服务器

测试服务器已启动:http://127.0.0.1:3000/,确认返回正常。

→ 离字的距离也决定字重,越来越重。

已实现:距离越远,字重从 100 逐渐增加到 700,同时透明度降低,到距离阈值时消失。

测试服务器已热更新,构建和浏览器运行验证通过。

→ 摄像机运动不要太靠边,也就是说限定在小范围内;白底黑字

已改为白底黑字。摄像机 XY 移动限制在 ±0.6 范围内,接近边界时减速,Z 保持匀速。

测试页面已热更新,构建和浏览器验证通过。

→ 字飞的快一些,这样可以拉开字间距,并且全部改用非常重的字重

已调整:

  • 摄像机 Z 速度从 4 提高到 10,字间距扩大至原来的 2.5 倍。

  • 所有汉字固定使用最重字重 700,距离仅控制淡出。

构建验证通过,测试页面已热更新。

→ 距离为零时透明度也变成100%,也就是说运动到一个合适的距离时才不透明,调整一下曲线,

已改为平滑的先淡入、后淡出曲线:

  • 距离 0:完全透明。

  • 距离 0–4:逐渐显现。

  • 距离 4–8:完全不透明。

  • 距离 8–48:逐渐淡出,最终移除。

构建通过,测试页面已热更新。

→ 让字错开

已让汉字上下左右错开:摄像机自动做小幅交错移动,整体仍限制在 XY ±0.6 内,鼠标可继续控制。

构建通过,测试页面已热更新。

→ 加上棱镜散射和色散的效果

已加入棱镜散射和 RGB 色散:黑色笔画边缘呈现彩色分离与柔和散射,各字方向略有不同。

测试页面已热更新,构建和浏览器渲染验证通过。

→ 字具有一定的和xOy平面的随机夹角

已加入:每个字与 xOy 平面具有 0°–25° 的随机夹角,倾斜方向随机,生成后保持不变。

构建通过,测试页面已热更新。

→ 字进一步远离中心分散避免重叠

已将交错幅度扩大到原来的 3 倍,让字更远离中心、减少重叠。摄像机 XY 范围相应调整为 ±1.4。

测试页面已热更新,构建和浏览器验证通过。

→ 不要摇晃摄像机了 让字自己错开即可

已取消摄像机自动摇晃,改为汉字生成时自行错开,位置随后固定。

摄像机仅响应鼠标的小范围 XY 移动,Z 保持匀速。构建和浏览器验证通过,页面已热更新。

→ 现在字仍占画面的较小部分,想办法占更多,使视觉上平衡

已调整画面占比:

  • 字形放大至原来的 2.5 倍。

  • 分布范围扩大至原来的 3 倍。

  • 延长清晰显示阶段,让远处小字更早淡出,减少中心堆积。

测试页面已热更新,构建和浏览器验证通过。

→ 交角不够大

倾角已从 0°–25° 增大到 30°–65°,每个字都有明显倾斜,方向随机。

构建通过,测试页面已热更新。

→ 交角太大了,0-40

已改为随机倾角 0°–40°,测试页面已热更新。

→ 实现圆形鱼眼镜头的畸变效果

已加入圆形鱼眼镜头效果:中心放大、边缘弯曲压缩,并带轻微暗角。现有文字倾斜、淡出和色散效果均保留。

测试页面已热更新,构建和浏览器渲染验证通过。

数据处理

→ reference里面有一张专辑的18首歌及顺序,表格中另附有相关信息收集表,从中按顺序提取所有歌的歌词原文(不需要翻译)

已按 18 首顺序整理歌词原文,未包含译文:

  • 歌词文档

  • JSON 数据

表格中找到 14 首。缺少《往生水族馆》《浴室少女》《失语》《深海》,已保留对应位置并标注缺失,需要补充这四首的原文。

→ 往生水族馆:漂浮着 陈旧的声与光...

已补入第 2 首《往生水族馆》,保留原文分行,并同步更新歌词文档和 JSON。

目前完成 15/18 首,还缺《浴室少女》《失语》《深海》。

→ 失语:反复揣测后发送...

已补入第 13 首《失语》,原文与分行均保留,文档和 JSON 已同步更新。

目前完成 16/18 首,还缺《浴室少女》《深海》。

→ 深海:漆黑的海洋...

已补入第 17 首《深海》,保留原文分行及括号内容,文档和 JSON 已同步更新。

目前完成 17/18 首,仅缺《浴室少女》。

→ 浴室少女:忍着 空虚的乏味...

已补入《浴室少女》,18/18 首歌词原文全部齐全,已核对曲目顺序,未加入翻译。

  • 歌词文档

  • JSON 数据

→ 歌词去掉标点符号,首尾相连,变成新的取代三字经的文库

已替换为专辑歌词文库:18 首按顺序无缝连接,去除标点、空格和换行,共 3851 个字符,保留各语言原文并循环取字。

测试页面已热更新,构建和浏览器验证通过。

实现

→ 鼠标对运动的影响目前太小

已增强鼠标控制:

  • XY 速度:3 → 7

  • 移动范围:±0.6 → ±2

  • 保留边界减速,Z 速度不变。

构建通过,测试页面已热更新。

→ 现在有一篇总结全部歌词意象的采样歌词,核查一下是否所有字都来自歌词库

已核查 采样歌词,并非所有字都来自歌词库。

共 49 字,其中以下 6 字未出现:

其余字均能在 18 首歌词原文中找到。比对未计入歌名、标点和空白。

→ 我现在需要在00:01:49:05(24fps)内播放完所有歌词库里的字,看看多少帧生成一个字合适

歌词库共 3851 字,00:01:49:05 @24fps 对应 2621 帧。

平均需要 每 0.681 帧生成一个字,即每秒约 35.26 字,因此每帧只生成一个字来不及。

建议均匀交替分配:

  • 1391 帧各生成 1 字。

  • 1230 帧各生成 2 字。

这样能在指定时长内生成全部字。若要求最后一个字也完成淡出,需要预留尾段时间,生成速度还应略快一些。

→ 先这么来;拉丁字母构成的单词一次生成一个词;标点符号不需要生成

已实现,标点、空格和换行均不生成。

拉丁单词整体生成,其余文字逐字生成,共 3511 个单位,在 00:01:49:05 @24fps 内均匀生成完毕,随后停止生成并自然淡出。

构建、时间分配检查和浏览器验证通过,测试页面已热更新。

→ 摄像机需要移动地快一些、透明度曲线需要拉陡一些,现在同时可以看得见的字太多了

已调整:

  • Z 速度从 10 提高到 18。

  • 距离 4–7 快速淡入,7–10 完全显示,10–18 淡出。

  • 歌词生成节奏不变,单字停留时间明显缩短。

测试页面已热更新,构建和浏览器验证通过。

→ 其实淡入应该慢些,或者说稍微离远更多一些再看得见

已调整为更远才显现、淡入更慢:

  • 距离 0–8:完全透明。

  • 8–14:缓慢淡入。

  • 14–15:完全显示。

  • 15–22:淡出并移除。

摄像机速度不变,构建通过,页面已热更新。

→ 字号应该变小,更分散

已试调:字号缩小约 33%,分布半径从 2.4–6 扩大到 3–8,减少重叠。

速度和透明度曲线保持不变。构建通过,测试页面已热更新。

→ 在中间正方形的两侧居中,实现一个填空一样的呈现。两侧各放一半summary-lyrics,预先只提供歌词库中缺少的字。歌词库中出现了对应的字时,将空逐个填上。为了让这个空相对均匀地填上,先查询每个字在歌词库中出现的时机,尽量分散。以使得直至接近播放完仍能有字需要填上。 字体采用较重字重,但小字稍微略大间距;库中缺少的字稍微减淡灰度,字号再放大可以略紧一些,不要使用连在一起的空

已调整:预填缺字改为浅灰,字号放大、字距略收紧,每个空格使用独立短横线。

两侧填空已与歌词生成同步,最后一个字在第 109 秒填入。构建及桌面、手机浏览器验证通过,测试页面已热更新。

→ 字号放很大、字距收紧,是为了16:9视觉比例下把两侧占70%左右空间而设计的;中间的不要改动;播放完之后,中间保持空白即可

已实现:播放结束后中央保持白色空白,两侧完整歌词保留。

中央画布已恢复原尺寸和位置。构建及完整播放流程验证通过,测试页面已热更新。

播放结束后中央空白

→ 始终有一个平面与摄像机隔一定z距离一起移动,出现填空的字时,在画面中心,渲染一个玻璃材质(类似棱镜、反射)的这个字;不需要淡出;淡入然后保持;直至下一个

已实现:填空出现新字时,中心同步显示玻璃棱镜字,淡入后保持,直到下一字替换。文字平面始终跟随摄像机并保持固定 Z 距离。

播放结束后中央仍恢复空白。构建和浏览器验证通过,页面已热更新。

→ 不是这种炫彩,是浅蓝色透明玻璃的感觉,你可以参考上层文件夹中的______里的镜子

已参考 ______ 的镜子材质,将中心字改为浅蓝透明玻璃,去掉彩虹边缘,保留背景折射、淡蓝切面和柔和高光。

淡入后保持至下一字替换。构建和浏览器验证通过,页面已热更新。

→ 不需要这么浅蓝;也不需要有明显的边缘;字重拉到最大

已确认字重为字体支持的最大值 700。玻璃字的蓝色和明显边缘也已弱化,保留通透折射与柔和反光。

构建和浏览器验证通过,页面已热更新。

→ 还不够大 想办法让它更粗

已在最大字重基础上进一步扩张中心玻璃字的笔画,让字身更粗,保持原有透明材质,不增加可见描边。

构建通过,页面已热更新。

→ 鼠标移动时,跟随摄像机移动的平面稍微具有xoy平面夹角,中心稍微对应偏移,以使得玻璃字稍微有移动。 因此也须加厚玻璃字的z轴厚度

已实现:玻璃字随鼠标轻微偏移、平滑倾斜,最大倾角约 12°;并增加了实际 Z 轴厚度,倾斜时能看到侧面。

保留淡入后持续显示、下一字替换的行为。构建和浏览器验证通过,页面已热更新。

→ 玻璃字似乎会抖动有残影,而且动的幅度太大了

已调整:

  • 最大倾角从 12° 降到 3°,位移缩到约五分之一。

  • 跟随更加平缓,减弱折射重影。

  • 修正计算精度和表面采样,减少抖动。

构建通过,浏览器无渲染错误。刷新即可查看。

→ 玻璃字并不透明,小字飞到它后面的时候,不会透过玻璃,产生折射、投射、色散等效果。

已修复:小字现在先绘入玻璃采样的背景,经过玻璃字时会透射、折射变形,并产生轻微色散;玻璃本身保持接近无色。

构建通过,浏览器无着色器错误。刷新即可查看。

→ 现在动得太小了,仍然会渲染错位导致抖动,恢复到不动吧。然后字150%大小,仍需保持类似字重

已将玻璃字固定在画面中心,取消鼠标偏移和倾斜,并改用相机空间投影,避免移动精度引起的抖动。

尺寸放大到原来的 150%,保持相同的粗重笔画比例和透射、折射效果。浏览器渲染检查通过。

→ 看着只像一块灰色的塑料,顶多有点透明,没有玻璃的折射、反射感;玻璃砖字也不够厚;面数太低 不如不倒角,就字从平面沿Z轴拉伸的玻璃砖

已去掉倒角,改成字形沿 Z 轴直接拉伸的玻璃砖:正面平整、侧壁垂直,保留加厚深度和折射、反射、轻微色散。

尺寸仍为 150%,固定居中。构建和浏览器渲染检查通过。

→ 仍然需要圆润 但面数不能那么低 连续光滑曲面;阴影效果太强了;想要的是液态玻璃一样的效果

已改成更接近液态玻璃的效果:圆润连续的曲面、平滑反光、背景折射变形,并明显减弱暗部。

曲面采用 1024 分辨率、16 位高度数据,减少分段和棱面感。保留 150% 大小、加厚体积与固定位置。构建和浏览器检查通过。

→ 左下角显示当前找到的字的来源和歌曲名小字。间距较小。注意对齐。 summary-lyrics两边分别向左和向右对齐

已完成:

  • 左下角显示当前填入字所在的原歌词和歌曲名,对应字加深显示,小字号、紧凑间距对齐。

  • 左侧 summary 左对齐,右侧右对齐。

构建及桌面、移动端检查通过,歌词播放时序保持不变。

→ 有没有一首歌没有被用来查字的

有,目前有 4 首歌没有用于两侧填空查字:

  • 《无限呢喃》

  • 《凋落せし春の標本》

  • 《告别part.Ⅱ》

  • 《I'll see you there》

其余 14 首均有被选中。这些未选中的歌仍参与中间飞字播放。

→ 有没有办法纳入进来

已重新分配,新增:

  • 《无限呢喃》提供“的”

  • 《凋落せし春の標本》提供“日”

现在覆盖 16 首,最后一次填空仍在 109 秒。

剩下《告别part.Ⅱ》和《I'll see you there》与当前 summary 没有共同字;要纳入这两首,需要在 summary 中加入它们原文里的字符或单词。

调整

→ 小黑字生成,现在不需要离中心太远,可以接近中心了

已将小黑字生成范围从距中心 3–8 缩为 0–4,允许接近中心,同时保留随机错落。刷新即可查看。

→ 1-6吧

已改为距中心 1–6。

→ 0.5-5

已改为距中心 0.5–5。

→ 整个页面有一种奇怪的底色,这个不需要

已统一为纯白背景,并去掉鱼眼边缘的灰色暗角。

→ 鱼眼边缘可以有暗角

已恢复鱼眼边缘的轻微暗角,页面背景仍为纯白。

→ 但是要求整体偏蓝色调,非常浅的低饱和的,但得是蓝色调

已调整为非常浅、低饱和的蓝色调:页面底色为 #f5f8fc,鱼眼暗角和玻璃反光也略偏蓝,黑字保持清晰。浏览器渲染检查通过。

→ 暗角不要那么明显,稍微有就好,蓝色可以明显偏亮一些

已将暗角减弱约 70%,只在最外缘轻微显现;整体改为更明亮清透的浅蓝色 #f4faff。

→ 整个画面增加一点滤镜

已加上轻微滤镜:略微降低饱和度、微调对比度,并叠加细颗粒,保留明亮浅蓝色调和文字清晰度。

→ 其实只需要杂色

已去掉饱和度和对比度调整,只保留轻微杂色。

→ 杂色也去掉吧,我之后自己处理

已去掉杂色层。

→ 目前只有最多1:44:12可用

已缩至 1:44:12(24fps,共 2508 帧),完整播放全部 3511 个生成单位,每帧生成 1–2 个。

最后一次填空约在 1:44:07,播放结束后中央保持空白。

→ 甜品前面换行。然后字号进一步增大

已将“甜品”单独换行,两侧填空歌词字号增大约 18%。

→ 不要横线,未填充的字很浅很浅存在。填成偏天蓝色

已去掉横线:待填字以极浅蓝色显示,填入后渐变为天蓝色;歌词库缺少的预填字仍保留灰色。

→ 更深的黑色略微偏蓝色调

已将填入后的文字改为略偏蓝的深黑色 #17232e,待填字仍保持极浅。

→ 未填充的浅色也是浅蓝灰色

未填充字已改为很浅的蓝灰色 #e3eaf0。

→ 深浅都更蓝一些

已加重蓝色倾向:深色改为 #142b45,浅色改为 #dce8f5。

→ 左下角歌词及填充字符,所有出现加上淡入淡出动画

已加入动画:左下角歌词和歌名切换时先淡出、再淡入;填充字符从浅色柔和过渡到深蓝色,初始文字也会淡入。

构建和浏览器检查通过。

→ 未出现的字预先置成黑色

歌词库中没有的预填字已改为黑色。

→ 右上角显示当前正在放映歌词的曲目编号和标题,例如 tr.1 无限呢喃

已在右上角加入两行、右对齐的当前曲目编号和标题,随歌词进度更新,切换时淡入淡出。

构建和浏览器检查通过。

→ 字号变大字重变重大大大

右上角曲目信息已大幅放大,最大 44px,字重拉到字体支持的最高 700,行距也收紧了。

→ 这个不要偏蓝

右上角标题改为纯黑色调,曲目编号改为中性灰,不再偏蓝。

→ 还不够重

已在最高字重基础上增加同色描边,让标题和编号进一步加粗。

→ 更大一些

已再放大约 25%,桌面最大 56px,保留加粗效果。

→ 行间距小些

已收紧右上角两行的行距。

→ 字号缩到75%

右上角字号已缩至当前的 75%,字重和行距保持不变。

桌面布局(现存截图已含后续 logo)
手机布局(现存截图已含后续 logo)

→ 播放完后虽然不再生成字但仍保持中间画布的样子,玻璃字还在

已调整:播放结束后停止生成新字,已有小字自然飞离;中间画布、轻微暗角和最后一个玻璃字持续保留。结束状态已验证。

播放结束后保留玻璃字

→ 左下角显示歌词有时显示了最后一个引号

已过滤左下角歌词中的引号,避免出现孤立的结尾引号。原始歌词库和查字时序保持不变。

→ 右上角标题有时会换行;不用缩小,就直接遮罩层盖上去;始终单行

已改为始终单行、字号不缩小,长标题直接叠在画布上方显示。

→ tr.5几乎被跳过了,将歌词重复四遍

已将 tr.5 歌词连续重复四遍,并同步重新分配填空时机。总时长仍为 1:44:12,构建和出处核查通过。

→ 右下角放上reference里面的logo;拉大到150%

右下角 logo 已放大到 150%,保持右侧和底部对齐。

Logo 预览

→ 左上角显示 ECBV-001-A 相同配色,Dela黑体,略倾斜;右下角logo75%

右下角 logo 已缩至当前的 75%,保持右下对齐。

→ 左上角采用蓝色系

左上角已改为蓝色 #376da3,保留 Dela 黑体和倾斜效果。

→ 蓝黑色,并且拉长,变密

已改为蓝黑色,横向拉长 20%,字距进一步收紧。

→ 纵向拉长,完全做反了

刚才方向理解反了。已改为纵向拉长 20%,恢复原宽度,保留紧字距。

→ 缩小一些

左上角已缩小约 17%,保留纵向拉长和紧字距。

→ 再拉长一些

纵向拉长已从 120% 调到 140%,宽度不变。

→ 125%

已改为纵向 125%。

→ 注意对齐;再小一些,斜体不变

左上角再缩小了 10%,倾斜角度保持不变。

→ 再小一些,减淡透明度至次要

左上角再缩小 15%,不透明度降至 55%,弱化为次要信息,倾斜保持不变。

飞字与玻璃字、角落信息

→ 左下角歌词略微增大

左下角歌词和歌名已略微增大:桌面 13px,手机 12px,保持原有对齐和间距。

→ 右下角logo可继续增大

右下角 logo 再增大了 20%,保持右下对齐。

→ 全部都改成logo的玫红色系呢;背景色不要

已去掉背景色,恢复纯白;文字和玻璃保留玫红色系。

→ 并非纯白啊

是鱼眼着色器还残留玫红色暗角,现已去掉。已检查实际画面像素,页面和画布空白区域均为纯白 #FFFFFF。

→ 还是恢复到之前吧

已撤回玫红色系调整,恢复蓝黑文字、黑色飞字和之前的玻璃配色,背景保持纯白;logo 保留原色。

→ 鼠标基本就是沿着屏幕中心为圆心的可变半径的螺旋线在绕圈子,能不能自动化这个过程

已自动化:每 9 秒绕一圈,半径每 30 秒完成一次扩大、收回。

移动鼠标可临时接管,停止 2 秒后恢复自动运动。摄像机仍保持原有范围限制,构建和浏览器检查通过。

→ 感觉不够自然,绕快点,而且现在感觉总是会像撞墙了似的

已加快到约 4.5 秒一圈,半径变化也更快,并加入轻微节奏变化。

自动运动改为平滑跟随范围内的螺旋轨迹,不再撞到边界后停顿。已验证轨迹不会触碰边界。

→ 未找到的字再浅一些

待填字已进一步减淡为 #edf3fa,保留很浅的蓝灰色。

视频导出

→ 以网页画布尺寸为1920*1080,导出一个24fps的1:44:12视频,能不能想办法用脚本在渲染时记录并导出

已导出:下载视频

1920×1080 · 24fps · 2508 帧 · 1:44:12,MP4,无音轨。已核验参数并抽查画面。

之后可运行 npm run export:video 重新导出。

1920×1080 试导出抽帧
首版视频多时间点拼图
首版视频末尾抽帧

→ 视频中,左下歌词和右上曲名都偏小,是否需要写死比例;但是两侧差不多字号是成比例的;也要复查左上角是否有问题;最后需要多导出2s左右,便于剪辑;告诉我怎么导出,我自己来

在项目目录执行:

代码块
Shell
自动换行
复制代码
npm run dev
复制成功

另开终端执行:

代码块
Shell
自动换行
复制代码
npm run export:video -- --output exports/final.mp4
复制成功

输出:1920×1080、24fps,歌词 1:44:12,加 2 秒尾帧。三个角落的字号已修正。

修正角落字号后的检查快照