√-pair晶格缩放与烘焙预设的秘密：thinking-orbs如何用一套参数调出"两个尺寸"的独立设计
【免费下载链接】thinking-orbsDotted thought-orb loading indicators for AI & agent UIs, 9 tuned types, two sizes, auto dark/light项目地址: https://gitcode.com/gh_mirrors/th/thinking-orbs
thinking-orbs 是一个面向 AI 与 Agent 界面的「思考球」加载指示器库：9 种手调动画状态、64/20 两种尺寸、自动明暗主题，全部跑在普通 2D Canvas 上。🧠 它最有意思的地方在于：64 和 20 并不是"放大版/缩小版"，而是两套独立设计——而支撑这两套设计的，只是一套 √-pair 晶格缩放规则 + 一张烘焙好的预设表。本文带你拆开这套机制。
先认识主角：9 个状态，2 个"尺寸"
组件只有一个，却描述了 AI 正在做的 9 件不同的事：
| 状态 | 动画 |
|---|---|
working | 倾斜轨道上的粒子 |
searching | 扫描经线扫过点阵地球 |
solving | 条纹打乱后咔哒归位 |
listening | 波形滚过纬度环 |
connecting | 星座自我接线 |
weaving | 三股 strands 编织 |
composing | 波浪多带绶带 |
breathing | 圆环缓慢变形 |
shaping | 圆 → 三角 → 方 |
尺寸只有两个：64（聊天头像尺度）与20（行内文字尺度），定义见 src/types.ts。类型注释里一句话点题：
Each size carries its own dot count, dot size and speed tuning — they are separate designs, not a scale factor.（每个尺寸自带点数、点径、速度调参——是独立设计，不是缩放系数。）
为什么不能"直接缩小"？
最直觉的做法是把 64 的画面整体缩成 20。但点阵动画有两个陷阱：
- 密度失真：点数量不变时，小画布上点会糊成一片，大画布上又显得稀疏；
- 深度语言失真：点径若线性缩放，远浅近深的层次感会变形，20px 下直接糊掉。
thinking-orbs 的解法是：把"基础设计"和"每个 (状态 × 尺寸) 的调参"彻底分开，中间只隔一套确定性的缩放规则。
√-pair 晶格缩放：一条保住"密度"的公式
大多数球面动画画的是二维晶格：比如地球模式 = 纬度圈数 × 每圈经线点数。总点数 ≈ 两个维度相乘。于是缩放规则很优雅：
每个轴乘以 √scale，总数就精确乘以 scale。
规则实现在 src/engine/profiles.ts，声明了三个"配对键"：
['latRings', 'lonDensity'] // 球面经纬点阵 ['rings', 'lonDensity'] // 波浪的纬度环 ['lanes', 'segs'] // 绶带的车道 × 分段scaleCounts（src/engine/profiles.ts）对每一对取√scale后四舍五入（下限 2），其余如orbitN、ghostN、nodeN这类一维列表则按scale线性缩放。
用真实数据感受一下。searching（地球）的基础画布是 17 圈 × 44 经线；20px 预设的 count 为 0.105，√0.105 ≈ 0.324：
- 纬度圈：round(17 × 0.324) ≈6
- 经线密度：round(44 × 0.324) ≈14
密度按面积等比缩小，但"每圈点数随纬度收缩"的球形结构原样保留。再看composing（绶带）：基础 5 车道 × 88 段，64px 时 count 0.25 →√0.25 = 0.5→3 × 44；20px 时 count 0.051 →2 × 20。三档密度，同一套公式。✅
零值规则：一个防止"死层复活"的细节
breathing复用了绶带的画笔，但故意关掉了背景幽灵球（ghostN: 0）。如果线性缩放规则无脑套用max(1, round(v × scale))，0 会被"复活"成 1 个孤立杂点。所以代码对v === 0显式跳过——注释写得很直白：scaling must not resurrect it as a single stray dot（见 src/engine/profiles.ts）。
烘焙预设：18 行参数表调出 18 套设计
真正的手调结果都"烤"在 src/presets.ts 的一张PRESETS表里：9 状态 × 2 尺寸 = 18 行，每行三个乘数 + 可选附加项：
speed：乘到共享时钟上的速度（注意 20px 往往更快，如working的 1.885 → 3.9）；count：交给上面那套缩放规则；size：交给 scaleRadii，把全部 9 个半径键一起乘——点径整体变厚变细，但"近大远小"的衰减半衰程不变；extra：逐字合并的模式附加项（如bandMul、spread）。
同一个working状态，64px 是{ speed: 1.885, count: 1, size: 1 }，20px 却是{ speed: 3.9, count: 0.238, size: 2.4 }——数字完全不同，这就是"两个尺寸是两套设计"的出处。💡
resolvePreset对每个 (state, size) 只解析一次并缓存（src/presets.ts），渲染循环拿到的全是现成数字，零每帧开销。更小的兜底在 src/engine/core.ts：点径按(size/300)^0.6次线性缩放，保证小尺寸依然清晰。
一套参数，三个平台：spec 抽取与黄金校验
这套机制的终极价值在跨端移植（背景见 PORT_PLAN.md）：
- scripts/extract-spec.ts 把预设、缩放规则（配对键、零值规则）、渲染契约全部导出为 spec/orbs-spec.json——Swift 与 React Native 移植从数据生成，而非手工誊抄公式；
- scripts/extract-golden.ts 在 72 个 (状态 × 尺寸) 组合 × 固定时间戳下导出 11,288 个点的精确坐标/半径/墨值（6 位小数，容差 1e-4）到 spec/orbs-golden.json，作为各端逐点比对的黄金基准。
也就是说：在 Web 端重新调参 → 重跑抽取 → 三个平台自动保持一致，整个循环不产生任何手写同步代码。🎯
小结：三个可带走的设计秘密
- √-pair 晶格缩放：二维晶格两轴各乘 √scale，总点数精确按 scale 走，球形结构不失真；
- 按 (状态 × 尺寸) 烘焙 + 解析缓存：18 行参数表即 18 套独立设计，运行时零成本；
- 规则外化为 spec + golden：一套参数喂饱 Web、Swift、React Native，靠数据而非约定保持像素一致。
想亲自体验的话，npm install thinking-orbs后引入<ThinkingOrb state="searching" size={20} />即可，更多用法见 README.md 与 src/engine/index.ts。
【免费下载链接】thinking-orbsDotted thought-orb loading indicators for AI & agent UIs, 9 tuned types, two sizes, auto dark/light项目地址: https://gitcode.com/gh_mirrors/th/thinking-orbs
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
