fix: improve match3d tray preview readability

docs/design/BAIMENG_LOGO_GPT_IMAGE_2_CONCEPTS_2026-05-05.md

@@ -0,0 +1,235 @@
+# 百梦 logo gpt-image-2 概念方案 2026-05-05
+
+## 1. 产品气质提炼
+
+当前产品对外名为“百梦”，核心不是单一 RPG 玩法，而是面向互动叙事、世界生成和运行时演出的 AI 原生创作平台。
+
+本次 logo 概念围绕以下关键词设计：
+
+1. `百`：多世界、多题材、多角色关系，不是单条故事线。
+2. `梦`：创作者的世界锚点、想象入口和叙事氛围。
+3. `AI 原生`：AI 负责叙事表达、关系生成和世界扩展。
+4. `规则裁决`：本地系统负责状态、任务、背包、招募、存档等可信边界。
+5. `视觉 RPG`：保留游戏感、角色感和舞台感，但平台层需要比纯像素 UI 更清爽。
+
+## 2. 方案 A：梦门星轨
+
+视觉方向：
+
+- 用一个打开的门 / 星门作为主体，门内有多条细线向外延展，代表百梦主从一个灵感入口进入多个世界。
+- 负形中弱化出“百”的结构，不强行写字，方便后续做 App icon、favicon 和小尺寸导航标。
+- 色彩以暖白、珊瑚粉、少量紫蓝和深墨色组成，贴近平台亮色主题，同时保留梦境和 AI 的科技感。
+
+适合场景：
+
+- 平台主 logo
+- App icon
+- 创作入口主视觉
+
+设计含义：
+
+“梦门”代表创作入口，“星轨”代表剧情线程、角色关系和世界分支。它强调百梦是让创作者开启世界的工具，而不是只播放固定剧情的游戏。
+
+## 3. 方案 B：叙事图谱
+
+视觉方向：
+
+- 用节点、弧线和轻微书页轮廓组成一个稳定的圆形标志。
+- 图谱整体形成近似“百”的秩序感，避免复杂到小尺寸失真。
+- 色彩以深墨、湖青、光点金和珊瑚色组合，体现规则边界与创作活力并存。
+
+适合场景：
+
+- 技术品牌页
+- 开发者文档
+- AI 剧情引擎介绍
+
+设计含义：
+
+这个方向更强调“世界不是一段文本，而是一张可控的叙事图谱”。节点是角色、地点、物件和任务，弧线是关系、暗线与回响。
+
+## 4. 方案 C：光点梦织
+
+视觉方向：
+
+- 多个光点汇聚成柔和的“B / 百”抽象符号，中心像一枚被点亮的种子。
+- 线条更轻，图形更偏平台化和消费级，不做重游戏徽章。
+- 色彩采用珊瑚粉、暖金、浅青和深色细线，表达“光点”消费单位与灵感生长。
+
+适合场景：
+
+- 移动端启动页
+- 用户增长、邀请、充值与创作激励相关页面
+- 更轻量的品牌应用
+
+设计含义：
+
+每个光点都是一次生成、一次灵感、一次世界推进。多点汇聚成梦，呼应“百梦”里从许多小创意生长出完整作品的路径。
+
+## 5. 方案 D：像素剧场
+
+视觉方向：
+
+- 以轻度像素化的舞台窗、卷轴和星形光标构成标志，但不使用重像素边框。
+- 保留视觉 RPG 的游戏感，适合作为游戏内或活动页的品牌变体。
+- 色彩更高对比，适配暗色游戏 UI，也能在亮色平台层中作为强调图标。
+
+适合场景：
+
+- 游戏内 HUD 品牌露出
+- 活动页、社区头像
+- 复古 RPG 氛围更强的物料
+
+设计含义：
+
+舞台代表演出，卷轴代表叙事，星形光标代表 AI 与玩家选择。它让百梦看起来仍然属于游戏和互动内容，而不是泛 AI 工具。
+
+## 6. 生成说明
+
+本次推荐先用 `gpt-image-2` 生成 4 张 `1024x1024` 方形草案。由于图片模型对中文文字的稳定性有限，首轮应优先验证“图形标识”而不是直接把“百梦”两个字烘焙进图片。最终产品落地时，建议使用真实前端字体或 SVG 字形承载“百梦”字标，把生成图作为图形标志参考。
+
+## 7. 女性友好与全年龄潮流版补充
+
+在用户明确希望吸引女性用户或全年龄段用户后，logo 方向从“玄感书法 / 高级符印”调整为“可爱、圆润、潮流、轻社交平台感”。
+
+视觉方向：
+
+- 字形更圆润，减少尖锐笔锋、黑底压迫感和玄幻气质。
+- 色彩从黑白、金色、深墨切换到奶油白、莓果粉、薰衣草紫、薄荷青。
+- 允许轻量梦泡、云朵、柔软光点等符号，但不堆叠插画。
+- 保留“百梦”中文字标作为主识别，图标可作为 App icon 或社交头像补充。
+
+本轮生成 prompt：
+
+`tmp/imagegen/baimeng_logo_cute_trendy_batch6_prompts.jsonl`
+
+本轮输出目录：
+
+`output/imagegen/baimeng-logo-cute-trendy-batch6/`
+
+当前更适合作为产品主方向的是 `01-rounded-wordmark` 与 `04-icon-wordmark-lockup`。`03-dream-bubble-icon` 和 `05-soft-blob-mark` 更适合作为 App 图标或营销贴纸，而不是完整品牌字标。
+
+## 8. 生活物件原型抽象版补充
+
+在用户进一步要求“保持扁平和抽象，可以意象一些生活中较常见的事物作为原型”后，本轮将图形从糖果质感的梦泡收敛为更扁平的日常物件抽象。
+
+候选原型：
+
+- 枕头
+- 小夜灯
+- 便签 / 书签
+- 杯垫 / 泡泡饮料
+- 香薰 / 扩香石
+- 糖纸 / 包装折角
+- 叠放贴纸
+- 睡眠眼罩 / 软窗帘
+
+本轮生成 prompt：
+
+`tmp/imagegen/baimeng_logo_flat_daily_object_batch8_prompts.jsonl`
+
+本轮输出目录：
+
+`output/imagegen/baimeng-logo-flat-daily-object-batch8/`
+
+当前最值得继续推进的是 `03-bookmark-notes`：它保留了扁平、抽象、生活物件原型和创作平台语义，也较少落入儿童化或睡眠 App 的既有联想。`06-candy-wrapper` 可以作为更潮流的备选方向，但品牌语义比书签/便签弱。
+
+## 9. 简化产品主标版补充
+
+在用户反馈“整体还不错，但元素太碎，有些适合作为 icon 但不适合作为产品 logo”后，本轮将生活物件原型继续压缩为：
+
+- `1` 个主体轮廓
+- `1` 个负形
+- 不使用文字、星点、叠片、贴纸装饰和多层方案板
+
+本轮生成 prompt：
+
+`tmp/imagegen/baimeng_logo_simplified_product_batch9_prompts.jsonl`
+
+本轮输出目录：
+
+`output/imagegen/baimeng-logo-simplified-product-batch9/`
+
+当前最值得继续推进的是 `03-single-bookmark` 与 `06-rounded-square-notch`：
+
+- `03-single-bookmark` 更像独立品牌符号，保留了书签 / 作品卡 / 世界入口语义。
+- `06-rounded-square-notch` 更像 App icon 主体，亲和、简洁，但需要降低通用 App 图标感。
+
+不建议继续推进 `01/02/07/08`，它们被模型渲染成了方案板或 icon set；`05` 的版式参考价值高，但中文文字仍不能直接作为最终资产。
+
+## 10. 气泡共创主标版补充
+
+在用户明确提出“用轻盈的气泡展现梦，用多个气泡展现很多（百），气泡交错表示 UGC、共创、分享”后，本轮将主方向收敛到多气泡共创符号。
+
+设计原则：
+
+- 用 `3-5` 个大气泡表达“很多 / 百”，避免散乱小点。
+- 气泡之间必须交错或重叠，表达用户创作互相连接、分享和共创。
+- 整体必须收束成一个可识别主轮廓，而不是一组装饰元素。
+- 保持扁平、抽象、轻盈、女性友好和全年龄亲和。
+
+本轮生成 prompt：
+
+`tmp/imagegen/baimeng_logo_bubble_cocreation_batch10_prompts.jsonl`
+
+本轮输出目录：
+
+`output/imagegen/baimeng-logo-bubble-cocreation-batch10/`
+
+当前最值得继续推进的是：
+
+- `08-minimal-three-bubbles`：最像产品 logo，结构克制，气泡交错和共创语义清楚。
+- `01-overlap-cluster`：更适合品牌主视觉，轻盈梦感更明显，但作为小尺寸 logo 稍弱。
+- `06-sharing-knot`：共创感强，但中间负形需要继续简化。
+
+## 11. 吹泡泡行为亲和版补充
+
+在用户进一步提出“希望落在现实中常见的事物或行为上，比如吹泡泡行为，让用户觉得接地气或使用起来很简单，有亲和力”后，本轮将气泡主标落到“泡泡棒 / 泡泡水 / 轻轻吹出泡泡”的日常原型。
+
+设计原则：
+
+- 泡泡棒或泡泡圈表达“很简单、人人会用、低门槛”。
+- `3-4` 个气泡表达梦、很多、分享和共创。
+- 不画人物、嘴巴、小孩或玩具包装，避免儿童用品感。
+- 保持扁平抽象和品牌主标感，避免成为功能 icon。
+
+本轮生成 prompt：
+
+`tmp/imagegen/baimeng_logo_bubble_wand_batch11_prompts.jsonl`
+
+本轮输出目录：
+
+`output/imagegen/baimeng-logo-bubble-wand-batch11/`
+
+当前最值得继续推进的是：
+
+- `08-minimal-ring-bubbles`：最干净，保留泡泡棒原型，同时不太幼稚。
+- `01-ring-three-bubbles`：识别直接，但工具 icon 感略强。
+- `04-breath-origin`：梦感更强，但现实吹泡泡行为弱。
+
+批量生成 prompt 已放在：
+
+`tmp/imagegen/baimeng_logo_gpt_image_2_prompts.jsonl`
+
+建议输出目录：
+
+`output/imagegen/baimeng-logo/`
+
+生成命令：
+
+```powershell
+$env:OPENAI_API_KEY="本机已配置的 OpenAI API Key"
+python "C:\Users\wuxiangwanzi\.codex\skills\.system\imagegen\scripts\image_gen.py" generate-batch `
+  --input tmp\imagegen\baimeng_logo_gpt_image_2_prompts.jsonl `
+  --out-dir output\imagegen\baimeng-logo `
+  --concurrency 2 `
+  --quality high `
+  --size 1024x1024
+```
+
+若继续使用仓库现有 APIMart 路由，则需要配置：
+
+```text
+APIMART_BASE_URL=https://api.apimart.ai/v1
+APIMART_API_KEY=...
+```

docs/prd/AI_NATIVE_MATCH3D_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-04-30.md

@@ -330,7 +330,7 @@ itemTypeCount = clearCount <= 25 ? clearCount : 25
 
 1. 每次点击进入即时反馈流程后，前端先把物品表现为进入备选栏。
 2. 备选栏中每出现 `3` 个相同物品 id，前端立即播放自动消除效果并腾出格子。
-3. 3D 模式下，备选栏格子展示从场内取出的同款 3D 模型预览，视角固定斜 `45` 度，不使用另一套不一致的 UI 图标；托盘预览必须共享一个 WebGL renderer，不能因多个预览上下文导致中心场地模型不可见；WebGL 回退或 `2D` 模式下才使用保留的 2D 图标。
+3. 3D 模式下，备选栏格子展示从场内取出的同款 3D 模型预览，视角固定斜 `45` 度，不使用另一套不一致的 UI 图标；托盘预览必须共享一个 WebGL renderer，并按 `7` 格容器实际宽高把模型居中摆放到对应格子，不能因多个预览上下文导致中心场地模型不可见；WebGL 回退或 `2D` 模式下才使用保留的 2D 图标。
 4. 后端确认后固化真实备选栏和消除结果；若后端返回状态不一致，前端必须以最新后端快照校正。
 5. 如果备选栏满且无法消除，前端可以立即展示失败过渡，最终失败状态以后端确认为准。
 

docs/technical/MATCH3D_CREATION_AND_RUNTIME_MINIMAL_IMPLEMENTATION_2026-04-30.md

@@ -656,7 +656,7 @@ src/components/match3d-runtime/
 
 1. 圆形空间占据主要区域。
 2. 备选栏固定 `7` 格。
-3. 3D 模式下，备选栏格子使用与圆形空间内一致的程序化 3D 模型预览，固定斜 `45` 度视角，且不接入场内物理碰撞；托盘预览必须共享一个 WebGL renderer，不能每格创建独立 renderer；仅 WebGL 回退或 `2D` 模式使用 2D 图标。
+3. 3D 模式下，备选栏格子使用与圆形空间内一致的程序化 3D 模型预览，固定斜 `45` 度视角，且不接入场内物理碰撞；托盘预览必须共享一个 WebGL renderer，按实际容器宽高更新正交相机，并以独立 pivot 居中每个模型后定位到对应格子；不能每格创建独立 renderer；仅 WebGL 回退或 `2D` 模式使用 2D 图标。
 4. 倒计时清晰但不遮挡物品。
 5. 物品点击区域稳定，不因动画造成布局跳动。
 6. 胜利/失败结算使用独立面板，不在当前面板下方展开。

docs/technical/MATCH3D_RUNTIME_3D_GEOMETRY_EXPERIMENT_2026-05-02.md

@@ -50,7 +50,7 @@ cannon-es
 
 3D 分支只读取后端快照中的物品坐标、层级、可点击状态和视觉键。物理碰撞、轻微堆叠和几何体姿态只作为前端表现层，不改变消除规则、备选栏规则、胜负判定或最终权威快照。
 
-`match3dVisualAssets.tsx` 保留 2D 纯色几何图案映射，运行态托盘在 3D 模式下通过 `Match3DTrayPreviewBoard` 使用单个共享 WebGL 预览层复用 `createMatch3DItemMesh` 生成同款 3D 模型，不能为每个托盘格单独创建 `WebGLRenderer`。WebGL 不可用或 2D 回退时继续使用该 2D 图标；`match3dRuntimePresentation.ts` 收口显示层坐标和状态兼容，避免异常旧坐标把 2D 或 3D 物体推到圆形边界外。
+`match3dVisualAssets.tsx` 保留 2D 纯色几何图案映射，运行态托盘在 3D 模式下通过 `Match3DTrayPreviewBoard` 使用单个共享 WebGL 预览层复用 `createMatch3DItemMesh` 生成同款 3D 模型，不能为每个托盘格单独创建 `WebGLRenderer`。托盘预览层必须按实际容器宽高更新正交相机，并把每个模型放入独立 pivot 后再沿相机屏幕横轴定位到对应格子中心；托盘预览不能把所有模型统一缩放到同一外观尺寸，必须保留场内相对尺寸差异，否则会让点击后入槽的模型和场内物件对应关系失真。WebGL 不可用或 2D 回退时继续使用该 2D 图标；`match3dRuntimePresentation.ts` 收口显示层坐标和状态兼容，避免异常旧坐标把 2D 或 3D 物体推到圆形边界外。
 
 ## 4. 验收口径
 
@@ -159,3 +159,39 @@ cannon-es
 7. 本局使用类型数仍按第 11 节计算，即 `clearCount <= 25 ? clearCount : 25`。比例遇到非整数时按最大余数补齐，确保五档数量之和等于本局使用类型数。
 8. 体积档位分配绑定到本局选中的 `visualKey`，同一局内同一个颜色和造型只能有一个尺寸档位和一个半径；当 `clearCount > 25` 轮转复用类型时，复用的同一 `visualKey` 继续沿用同一尺寸。
 9. 前端本地试玩、创作后试玩和后端权威运行态必须使用同一套五档体积分配口径。
+
+## 13. 可点击物整体显示倍率
+
+2026-05-04 追加一轮点击手感优化，解决当前玩家点击可消除物偏困难的问题。
+
+编码口径：
+
+1. 运行态表现层使用 `MATCH3D_RENDER_ITEM_SCALE = 2`，把后端快照中的 `item.radius` 统一乘 `2` 后再进入显示层坐标收束。
+2. 该倍率只影响前端 2D 回退图标、3D 场内模型、碰撞体、射线点击命中区域和托盘 3D 预览测量。
+3. 五档体积规则、每局类型数量、每种物品的唯一尺寸关系、后端权威快照和消除判定不做变化；所有物体之间的相对大小比例保持不变。
+4. 放大后的物体仍必须通过圆形场地显示层收束和 3D 锅内空气墙约束，不允许重新依赖 DOM 圆形裁切。
+5. 2026-05-04 追加修正：碰撞体必须和当前视觉模型使用同一套尺寸公式。长条、光板、斜坡、圆柱、圆环、拱门和锥形件不能再只按 `shape + radius` 粗略生成统一碰撞体；不得借此调整整体显示倍率、点击倍率、锅体尺寸或物理步进。
+
+## 14. 两位数消除局的点击命中与旧模型复用修正
+
+2026-05-05 针对 `clearCount >= 10` 时出现“点击到的 3D 模型和下方备选栏模型不一致”的问题，补充运行态复用口径。
+
+编码口径：
+
+1. 运行态 3D 棋盘的物理条目不能只按 `itemInstanceId` 复用，还必须结合 `runId`、`itemTypeId`、`visualKey`、`radius` 和 `layer` 生成当前渲染签名。
+2. 当同一个 `itemInstanceId` 出现在新的 run 快照里，但渲染签名已经变化时，旧 mesh 和 body 必须先销毁，再按当前快照重建。
+3. 这条修正只针对前端 3D 表现层，不改变后端权威快照、点击判定、备选栏规则和三消规则。
+4. 底部备选栏预览继续沿用按当前 run 快照重建的视觉键，不允许把上一局的旧 3D 资源误复用到新一局。
+
+## 15. 备选栏 3D 模型可读性优化
+
+2026-05-05 针对备选栏中的 3D 模型偏小、部分积木件难以辨认的问题，补充 UI 预览层展示口径。
+
+编码口径：
+
+1. 备选栏 3D 预览可以使用比场内更紧凑的显示尺度，让模型在单格 UI 中占用更大可读面积。
+2. 托盘相机和模型姿态只服务 UI 识别；当前采用偏强的俯视 `3/4` 立体角，并通过更明显的光照对比突出顶面与侧面差异，避免退化成纯平面旋转。
+3. 该调整不能改变中心场地 3D 模型的物理姿态、碰撞体、点击判定和后端权威快照。
+4. 托盘仍使用共享 `WebGLRenderer`，继续按当前 `visualKey` 和尺寸关系生成同款模型；不得新增每格独立 renderer。
+5. 托盘缩放不能继续只按本局最大模型统一压缩所有物体；小尺寸模型需要保留最低可读显示尺寸，但仍不能改动场内真实尺寸、碰撞尺寸和后端权威尺寸。
+6. 备选栏单格高度可大于宽度，优先保证局内 3D 预览的识别面积；不得为了适配旧正方形格子把模型再次压小。