11/8/2028

画图。处理杂事。

#我看了一百个平面设计案例（没那么少

#我 学不会 构成

写了一点点代码。原本打算用paperPath画丢勒的测量指南，画迷糊了，干脆直接画个矩形然后加载图片好了。因为很多东西都有先后顺序，现在layers的元素越来越多...

11/7/2025

画图。写了一点点代码。沟槽的设计谁做的？

算了吧模拟不出来，反正人偶的逻辑也移除了就重装演算室了，墙面平坦一点多正常？ttr建在海底天天泡水要是有瓷砖缝准给泡发了。

记一下用扫描线和噪点模拟屏幕的感觉，虽然暂时不知道为什么测试用的扫描线有问题，但总之先留个图层。

用paper画index的动画，要把path传来传去烦得要死好麻烦，还因为对象之间的依赖不太好拆分函数的功能。

受不了了干脆在这个js文件写全局数组。并遵循源源的建议开了个excle表格记录参数（我怎么没想到？以前还在打比赛的时候都能想到用表格记录每天刷了哪些题，虽然后来为了方便关联笔记改成notion了，但我怎么没想到？？？

11/6/2025

考虑通过mask、裁剪和偏移模拟投影在高低不同平面上的效果，暂缓。paper不能应用shader好烦，用shader写轻轻松松的事。

忙死。画视觉设计图。一边想能不能别画些折磨未来写代码的自己的设计了，一边画得忘乎所以。以后的事以后再说啊哈哈...

11/5/2025

没做，4节大课+处理这一周堆积的其他作业。拜托我只是一个专科生而已为什么一周的作业会多到一天写不完？有的东西太简单但要重复多次，机械工作还学不到任何东西，烦。

11/4/2025

或许我应该停下来思考。当然，能在网页上做到是好的，可是即便我打算沿用这份作业作为个人博客，即便我想要实现某些特定的效果，我真的有必要在这上面死磕吗？
现实的问题始终存在，我的物理与数学基础仍然薄弱，图形学和程序物理也只学了皮毛。回头看来就会发现这几天实在有点钻牛角尖了，用一个相对折中的方案达到较为理想的效果，理解整个流程，到这里就该止步。我需要学的远远不止网页设计，想做的东西也不仅仅是一个网站，把所有精力全部放在上面是一个尤其鲁莽的选择。况且它已经远远超越我现在的知识深度了，再研究下去也会因为超出知识面范围而如同无头苍蝇乱撞。
固然我相当喜爱和享受这种沉浸在深刻的知识里的感觉（或者不妨坦然承认这是一种逃避现实的方式），但也应该正视兴趣外的现实，无论是亟待完成的作品集还是尚有一段余裕的就业。我将最后测试一次混合pbd的方案，如果仍然行不通，就简化所有动画。

我一直很认可速通那边的一个说法，是说一个skip被研究出来并且有人使用在记录里以后，如果不去学，那就等于永远和别人有了这个skip的收益那么多的差距。再放大一些也是一样的，对于很多领域都是，必须尽可能的学尽可能地理解，但我总是感到瓶颈一般的阻塞……我真的能学会吗？我所作的简化真的是在有限资源下的权衡和取舍，而不是懦弱的退缩吗？掉头的速度实在令人发笑，预定的三周验证时间才仅仅过去一天有余。

移除了所有人偶相关的逻辑，重新规划原本预留给人偶活动的空间的布局。使用更静态的方案。

11/3/2025

一整天都在调整方案。好消息是测试能画出软体了，但组合起来还是巨大的难题。pbd的方案决定了在这个系统中不可能存在串在一起的一串刚体在不形变的同时还能应用逆向运动学进行约束求解，而我还想往刚体上挂软体，这更是难上加难。

在正式开始前，我一直认为这个项目的主要难点在于软体的实现和组件的相互约束。现在看来这确实是一个需要重点攻克的难题，但还有另一个我想也没想过的问题横亘在我眼前：性能。如果我指望通过网页呈现，那就不可能选择高开销的方案。想想上次这么谨慎的控制时空复杂度还是打算法竞赛的时候了。

pbd是我当下能够找到最轻量的方案，但如果我想按照我的期望做一个挂着软体线缆的刚体机械臂，即便是最轻量的方案开销也会指数增长。一种妥协的方案是机械臂的所有移动都使用状态机进行控制，移动轨迹预先进行计算，状态机只会在符合条件时读取并执行，这需要大量预先计算，而且可能僵硬。更妥协的方案是根据设定确实可以删掉机械臂，但我不想。还没到完全无能为力的时候吧。雨世界是怎么做到的呢？

开始看昨天翻到的小册子，作者的语言风格相当风趣，内容也是我最近在研究的主题。我真希望它能发挥一点作用。

ai确实是伟大的发明，至少我很难想象三年前的自己要怎么阅读这样纯英文的技术文档。

11/2/2025

根据性能和效果再研究了一下，因为物理的开销始终还是太大，最终完全抛弃了物理引擎，工具链是基于Verlet 积分和约束求解的纯数学模拟，使用基于位置的动力学（PBD）的思路，配合有限状态机模拟生物ai，然后用线性混合蒙皮完善绘制。

【程序化生物】面条蝇躯干软体和Constraints - Sublucid Geometry给了我很多启发。嗯，可能还算不上启发，基本上是照抄并改动的程度。很显然上述名词涉及的知识点我一个也没学过(除了有限状态机)，我真的能做完吗？总之预留了三周时间，如果做不完就从画面中剔除人偶。

我想我相对那些好学校的学生唯一的的优势在于学校的课程大多对我来说都轻而易举，看看教案和书本就能学个大概，因此有充足的时间投入到感兴趣的技术上。但相应的，缺陷也很明显:我的基础太差了，很多东西要从头开始学。

下午要回学校，今天大概一整天都不能完全专注在写代码上，所以决定空余时间都用来写pearl的配置文件。

接触到一本感兴趣的小书，最近摸不到电脑的时候大概会看看，目前看来应该是和我现在的方向有关。

11/1/2025

今天主要在进行图像素材的处理和制作。写了一部分代码用于随机生成俯瞰的地图，原本用分形噪音模拟信号干扰，但分形噪音的开销太大，每次调整参数看效果都要跑三五分钟甚至更久，跑了几次烦了，干脆删掉了相关的代码，只保留生成随机地图的功能，生成图像以后再用csp处理。

随机生成还是太看运气，十张里说不定只有一张效果合适，不过删除分形噪音以后不算什么大问题，十张差不多也就五秒，运气这种东西带来的坏影响只要次数堆积上去也会抵消。

场景背景暂时还没有头绪，原本打算是用雨世界的mod编辑器制作房间并导出渲染图，但mod编辑器只能导出未调色版本，调色的功能内嵌在游戏代码里。另外，我试图使用游戏自带的房间文件进行修改，但mod编辑器竟然读取不了。再想想吧……总的来说今天没什么进度。

测试了人偶的物理的几种方案，决定使用有限状态机的模式。

前几天初步构思使用matterjs进行完全的物理模拟来模拟运动效果，但测试结果是仅仅是两到三条软体就会导致风扇狂转，而整个页面上除了软体还有不少别的物理对象。这是难以行得通的。

有限状态机也是因为unity想到，好吧，虽然说有触类旁通这个词但逮着一个薅有点好笑了，说明知识面还是太狭窄。

总之，不再依靠软体构建物理结构，而是仅使用有限数量的刚体作为骨架，用约束来模拟弹性，并用paperjs绘制外层，以掩盖刚体骨架的简陋。这一部分完全模拟了雨世界的思路。然后，由于我并没有给人偶设计鼠标拖动事件，所以它的所有行为都可以通过有限状态机来管理，对于不同位置的产生的一些差异依靠逆向运动学进行处理。不过逆向运动学的部分可能需要更多地依赖ai，我还没怎么学。（顺带一提，我记得学校公共选修有一门叫人体运动学，不知道有没有关系。

接下来一段时间大概会有大量时间花费在调参上吧。

10/31/2025

苦恼了一上午即便使用了工厂函数和把paperPath、matterBody封装进同一个类中方便管理，每次创建按照位置分布传参数并依次创建约束仍然是枯燥无聊的工作，这太愚蠢了。

中午想到之前接触过OnyxAmber老师使用Unity引擎制作的桌宠，因为功能并不复杂并没有图形化配置界面，但开放了config.json文件可以修改部分配置（如渲染颜色、生成概率和读取本地图片等）。

我仿照这个思路，把参数按组划分写进PearlOption.json里，向工厂函数传json，工厂函数解json并一次性生成所有的Pearl对象和对应约束。先前因为网课枯燥无味而一直没看的数据持久化之json反而通过这种方式学习了。也逐渐理解了向上封装，朋友开玩笑说我顿悟了操作系统原理。

另，趁着当前代码不多结构不复杂，以更符合vite的模式重构了文件树。

暂时把代码框架的结构优化先放一下，还有很多逻辑没写，如果到时候写了又要动框架就是无用功了。

先记录一下用fetch处理json。

我想很快我在写代码上也会复刻在画画上的问题，即审美远远超出了自我的能力，唯一值得庆幸的是我在代码上的基础比美术基础强多了。

10/30/2025

首页选项卡的关闭事件和布局还有待调整，通过paper加载图片纹理的部分还有待调整。

对于Pearl的工作流基本确立，逐步把测试对象替换为封装的函数和类，然后细化物理和视觉效果。尽可能不要在onload中留太多代码。

由于计算必然存在的浮点数误差，即便关闭所有阻力和摩擦，在只给予对象初速度的状态下，这个速度也会随时间衰减。一开始我想每帧给物体补一个微小的力，以维持这样的运动，但实践起来出现了问题：这个力必须沿着当前帧运动方向，且每帧增加力会导致速度累计得越来越大。总之是改了一阵，最后改成了速度衰减到一定范围后重设速度。

↑11/1/2025：力和速度只是一个别名，重要的是输入值是经过了怎样的计算如何作用到对象上。就像最初学图形学时书上写的那样，图形学所作的绝非完全复刻现实的物理规则，而是让观众的眼睛认为这和现实一样。这一点必须谨记。

东西越来越多，模块化……

10/29/2025

先写一点简单的运动约束确定工作流，没问题的话就开始做首页的运动模拟。似乎并没有想象中那么困难。注意更多地使用ai检查代码，以避免做重复造轮子不自知的工作（物理和数学原理相当重要，但现在我赶时间）。

测试用的对象比较简单，不由自主思考到底有没有使用paper的必要性。GPT说matter的render功能很有限。暂时还感受不到，也许在进行更复杂的处理的时候会出问题？还是从一开始确定工作流的时候就预留出paper的部分吧，比较保险。重构的话很麻烦，我现在已经有点想不起来五天前写完的UI布局的计算思路了。

从中午开始被布局问题困扰，一直到晚上才成功解决。

问题有两个：首先是载入物理模拟的文件（即paper和matter）的代码，布局文件中的所有计算都会失效，同时paper绑定canvas会覆盖布局文件中对canvas的约束，导致页面高度异常；其次依旧是载入这个文件导致的，即canvas上层的ui被拦截了鼠标事件，原本应该存在的点击事件不再被触发。

折腾了很久差点完全重构，最后发现是很愚蠢的问题……由于两个文件都写了window.onLoad=function（）{}，导致布局文件的所有内容都被物理模拟覆盖了，也就是说写在布局文件里的点击事件根本不是被拦截，而是根本就没添加到dom元素上。今后应该多使用add。

另外，保险起见，还是把canvas设置了事件穿透。

调试了一下午始终没找到问题的时候很想重构整个项目了，思维很混乱，自己都搞不清自己写的逻辑，事后看很清晰的模块在那时看来也混乱不堪了。没重构是因为不确定重构之后的结构是否会比现在更好。而且有一个很重要的问题，我总是要克服做错了就推翻全部重来的心态的，很多时候并没有可以重来的机会，更重要的是整理手上的资源进行挽救。唉，我希望在做完这个作业后能取得进步吧，无论是技术上还是心态上。

10/28/2025

越发认为Matter.js+Paper.js是很好的思路，通过物理和渲染的解耦可以节省很多花费在找问题出现在哪里的时间，到现在这个代码量再复制给ai让它看哪里有问题也有点困难了，或者难道我没有找到合适的方式？

Matter.js自带的约束系统在处理物理模拟上很好用，减少了相当多的手写工作量（其实主要的问题是我还没学完）。我想等昨晚手上这个再去彻底学原理，理解表征以后再去学基础理论的话会好理解很多。

稍微整理一下目前对物理动画这部分的思路：Matter模拟物理运动，Paper读取Matter对象的坐标信息进行绘制。

对于鼠标交互的部分，使用Matter的MouseConstraint进行逻辑判断，需要输出的部分转发给管理output文本框的事件统一处理，改变运动的部分就在逻辑内处理。

特别的，预想中有一个需要从外部转发到物理逻辑处理的鼠标点击事件，这部分要单独处理。

记录一下关于全局的渲染后处理思路，paper对这方面有限，可能需要使用webGL，一种方案是使用相对熟悉的threejs提供的shader，但目前还没到这个阶段，暂缓。

找了一段录屏观察Pearl的运动规则，记录一下，之后模拟：

  • 房间的光源共有五处，分别是四角和人偶的位置。其中人偶处的光源会跟随人偶移动，影响范围比四角阴影更有限，但亮度更高。

  • 对于pearl以外的对象，如果同时存在于两处光源的影响范围内，可能同时存在两个阴影投影，强度会随着和光源的距离衰减；对于pearl，始终有且仅有唯一的阴影投影。

  • 结构整体分为两部分，分别是pearl和文字（接下来用托盘指代），两者之间存在距离约束，坐标x值衰减时距离减小，x增大时距离增大。pearl有反光和阴影投影，托盘没有投影，且会被房间瓷砖的缝隙切割（即瓷砖缝隙的layer位于托盘之上，pearl之下）。

  • 以pearl的大小为单位1，堆放的pearl之间的最小距离保持在1.5-2之间，整体以（1，-1，0）的方向排列（右手坐标系），同一堆中右侧的pearl总比左侧高1。运动趋势类似波浪起伏。堆叠中的所有子对象总是保持一致的运动趋势，右下角的堆叠总是彩色且具有反光，左下角的pearl多为白色且无反光；

    ↑10/29/2025：群体运动可以用正弦波进行计算，我想。

  • 活动的pearl分为围绕人偶进行圆周运动和非特定情况固定区域活动两种。

    • 固定区域活动：通常围绕某一pearl进行圆周运动或保持静止。圆周运动的圆心可能发生嵌套，即a静止不动，b以a为圆心，c以b为圆心（最大层数为3）；
    • 围绕人偶进行圆周运动：共8颗，其中两颗在外圈，六颗构成内圈。

目前来看原作没有做相关的随机初始化位置，暂时搁置。

10/27/2025

让GPT各自写了一小段实例看各个包能做到什么程度，最终是确定下来用Matter.js+Paper.js，应该不会再变动了。

最初我是想手写刚体之类的物理，但这段时间一直在担心能否及时做完。103一直在看但进度挺慢，还有很多别的东西要学，其实js也是这个月才开始看。时间总是不够用，有点怀念高中那两年了。

之前一直在苦恼背景要怎么处理，一种尊重（照搬）原作的做法是划分网格并用官方提供的tile资源进行拼贴，每次运行时实时进行，但这样做的工作量太大，负荷也不低，本来要实时计算那么多对象就已经有可能太耗性能了，万一提交上去打不开很尴尬……

今天刷SNS看到关注的老师绘制了内存集成的图片，风格非常还原，给了我灵感。我想可以先用tile素材拼两组背景图，分别是阴影和明亮状态，按加载图像的方法加载明亮状态，然后根据活动对象的位置计算阴影区域，作为图像遮罩的依据，部分绘制阴影图像。

这个方案还有待完善，存在一些显著的问题，比如阴影和光面的过渡太僵硬，要怎么处理暗角和发光对象。但这些都可以解决，存在问题才是好事，如果没有问题了我反而会无所适从。

↑29/10/2025：想起在学Unity的时候有学到类似的思路，叫做烘焙。

引入matter.js到index.js以后，布局计算失效了，吓了一大跳，排查了半天似乎是因为import语句破坏了文件结构，具体原理的理解先放一放，总之以后会把布局和物理逻辑分开放两个文件。

↑10/28/2025：破案了，是引入js文件的时候没写type，默认的type不认识import。