√-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-orbsthinking-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] // 绶带的车道 × 分段scaleCountssrc/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 × 4420px 时 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.9count交给上面那套缩放规则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.mdscripts/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 statesearching 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），仅供参考
√-pair晶格缩放与烘焙预设的秘密：thinking-orbs如何用一套参数调出“两个尺寸“的独立设计
√-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-orbsthinking-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] // 绶带的车道 × 分段scaleCountssrc/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 × 4420px 时 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.9count交给上面那套缩放规则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.mdscripts/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 statesearching 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），仅供参考
