奥维实验icon
奥维实验
耳内有灰
当前状况导入功能虽然 UI 流程打通了,但像素读取失败——日志显示图片只有 16x16(原始是 128x128)。这是因为构建系统将 PNG 转成了 KTX 压缩纹理,Texture2D:GetImage() 拿到的是 GPU 上的缩小版本,像素数据丢失了。核心问题:构建管线(PNG → KTX)会破坏像素级数据,运行时无法可靠地从图片读取原始像素。可行方案既然运行时读图不可靠,应该把像素提取放在构建前——在开发环境中用 Python 完成:AI 生成 PNG (128×128)       ↓Python 脚本读取 PNG → 缩采样 32×32 → 输出像素 JSON       ↓编辑器导入 JSON(不再读图片)完整管线设计第一步:AI 批量生成图片对每个角色生成 3 方向 × 2 状态:方向 静止 (idle) 行走 (walk)正面 front 1 帧 2~4 帧背面 back 1 帧 2~4 帧侧面 side 1 帧 2~4 帧用参考图 + prompt 控制一致性,比如:“像素风,爸爸角色,正面站立,透明背景”“像素风,爸爸角色,背面行走第2帧,透明背景”第二步:Python 离线转换开发环境有 Python + Pillow,写一个脚本:输入:pixel_char_dad_front_idle.png (128×128)处理:缩采样到 32×32,提取 RGBA 像素输出:JSON 文件,格式与 CharData 的 pixels 结构一致("x,y": [r,g,b,a])第三步:编辑器批量导入导入按钮改为读取 JSON 像素数据(不再读图片文件),按文件名约定自动分配到对应槽位:dad_front_idle_1.json → front / idle / 帧1dad_back_walk_2.json → back / walk / 帧2第四步:用户微调在编辑器里对每个方向/帧做细节调整。关键决策点行走帧数:2 帧最小可用,4 帧更流畅,建议先做 2 帧验证AI 一致性:多方向/多帧之间风格一致性是最大挑战,可能需要用参考图(reference_image)约束侧面翻转:侧面只需画一侧,另一侧编辑器已支持翻转
耳内有灰
问题原因:拆除屋檐/柱子时调用的是旧版全局方法 mapData:UninstallRoof(),它只检查已弃用的 self.roofInstalled 全局字段。而实际屋檐数据存储在 wallParts[wk].roofInstalled 中。修复:从 piece.data.wallKey 解析出 anchorRow, anchorCol,改为调用 mapData:UninstallWallParts(row, col),这个方法会正确清除对应墙段的 pillarsInstalled 和 roofInstalled。
耳内有灰
分析两个核心 bug:Bug 1 - 加载界面不显示:beginPreloading() 的"快速路径"调用 PreloadOne() 时,实际执行了加载(不是仅检查缓存),所以 15 个纹理全部同步加载完,allCached=true,直接跳到 setupGameUI(),跳过了加载界面。Bug 2 - 预加载无效,地图仍然渐进加载:预加载用的 NVG 上下文来自 ImageCache.GetContext(),但当 MapCanvas:Render(nvg) 被调用时,它传入的 nvg 参数再次调用 TerrainRegistry.SetNVG(nvg) — 如果这两个 nvg 的 Lua userdata 身份不同(即使指向同一个底层对象),nvg_ ~= nvg 判断为 true,整个 texCache_ 被清空!解决方案:移除快速路径,添加一个仅检查缓存的方法(不加载)不在 beginPreloading 中设置 NVG 上下文,而是让预加载在 HandleUpdate 中进行,并确保使用的 NVG 上下文与 MapCanvas 后续使用的完全相同但根本问题是:我们无法保证 ImageCache.GetContext() 返回的 userdata 与 Widget Render(nvg) 回调中的 nvg 是同一个 Lua 对象引用。让我先验证这一点。
耳内有灰
改动清单CollisionMap.lua:构造函数新增 self.wallStrips = {} 数组Rebuild() 步骤 4 从网格阻挡改为门槛条:遍历 GetWallGroups() 按砖块跨度计算宽度,有柱子时加 PILLAR_VIS_W新增 RebuildWallStrips() 方法(增量更新,添砖/装柱后调用)IsAreaBlocked() 新增段落 C 检测 wallStrips_IsInAnyStrip() 新增 wallStrips 循环(防 Q/E 旋转卡住)删除旧的 MarkWallBlocked() 方法main.lua:3 处 MarkWallBlocked() 调用全部替换为 RebuildWallStrips()MapCanvas.lua:新增绿色调试可视化,渲染留言墙门槛条(与建筑的蓝色区分)宽度计算逻辑halfW = (maxBX - minBX + 1) * 16 / 2如果 pillarsInstalled:    halfW += 48 * 0.32  (≈15.36)1 砖 → halfW=83 砖 → halfW=246 砖 → halfW=486 砖+柱子 → halfW≈63可以预览看看绿色门槛条的位置是否和砖墙对齐。
耳内有灰
掉落物深度排序修复问题根因:MapCanvas 的渲染分两个阶段:_RenderBuildings — 建筑和树木统一按行号(sortRow)深度排序,远处先画、近处后画_RenderNPCs — 角色和掉落物,没有排序,且在建筑/树木之后绘制这导致所有掉落物无条件画在所有树木上面,不管掉落物实际上在哪棵树的前面还是后面。修复方案:将掉落物纳入 _RenderBuildings 的统一深度排序:_RenderBuildings 新增第 3 步:收集 _isDrop 标记的 NPC,根据 content 坐标 cy / ts + 1 计算 sortRow,与建筑/树木一起排序新增 _RenderOneDrop 方法:处理掉落物的坐标变换和 renderFunc 调用_RenderNPCs 增加 npc._isDrop 跳过判断,避免重复渲染现在掉落物会和树木按同一深度轴排序,后方树木掉出的木头会被前方树木正确遮挡,Q/E 旋转后也不会出现"木头跑到树冠上"的视觉错误。