原版双烘焙状态与静态碰撞组装 ​

本批结果 ​

已补原版视觉／碰撞双烘焙状态、静态顶点变换与法线重建，以及基础／条件物件两遍组装顺序。

• 原BAKE设置函数及真实模型动画谓词：64组机器码对照一致。
• 原468CC0追加碰撞、469570重算法线：6276次对照零差异。
• 包含400组任意三角形和56个实际原版代理三角形，不只用坐标为0／1的标准三角形验证平移舍入。
• 10张现有转换地图完成输入预检，确定接线仍缺原版实例状态／姿态、变体结果与条件分组分类。
• 1185条核心断言、123项相关Python检查通过；Godot C#构建及coresimlint通过。

整场景LOS尚未接完；武器构造覆盖仍1053／1419。本批数值核与预检数量不是新增完成武器数。

双状态不是一个BAKE布尔 ​

623D70构造时，piece+0x190与piece+0x191均为true。它们分别影响视觉烘焙与碰撞烘焙：

因此：

• 动画模型不一定有动态碰撞；它可以保留烘焙碰撞。
• NEVERBAKE关闭视觉烘焙，却会把碰撞烘焙设为true，甚至覆盖先前BAKE=false。
• 执行顺序有意义：加载后再执行BAKE=false，与BAKE=false后加载NEVERBAKE资源，最终状态不同。
• 资源路径未变、空路径或owner加载抑制门使加载体未执行时，不能额外套用加载阶段覆盖。

证据：4B92E0／4B9320、622FB0、623D70。4B92E0调用622220；后者通过模型+520指针以及指向对象+88的计数判断模型有无动画。不是简单检查同目录是否存在某个.ANIMATION文件。

加载抑制门的确切读取是piece+76 → 对象+388 → byte+16。本批保留为ownerLoadSuppressed输入，不凭用途猜成通用“编辑器模式”。

NativeRoomBakeState复现的是这些bit的事件转移，不是整个视觉资源加载器；缓存共享、动画资源装载和所有对象生命周期尚未一起迁移。

烘焙与独立物件的关系 ​

原622950独立射线要求：

!piece[0x190] && !definition.ALWAYSBAKECOLLISION && !piece[0x191]

原5F6250静态碰撞追加要求碰撞资源存在、COLLISION ENABLED允许，并且：

definition.ALWAYSBAKECOLLISION || piece[0x191]

独立射线被烘焙标志排除，不等于整个世界无遮挡；对应几何可能已经进入静态集合。

原构建器会暂时显示物件以读取几何，然后恢复可见性。因此不能把“当前没有画出来”直接当作“不参与静态烘焙”，也不能把Godot现有Mesh可见列表当作完整原版候选集合。

两遍追加顺序 ​

5F6250：

1. 按原区域／物件遍历顺序处理基础物件。
2. 原621F60认定属于条件分组的物件，留到后面的第二遍追加。
3. 每遍均使用ALWAYSBAKECOLLISION／碰撞烘焙标志判断是否追加。
4. 完成相关阶段后重建碰撞法线。

NativeRayMath.BakeRoomBatch保留这个基础先、条件后顺序，不按资源名称排序，也不合并重复实例。输出segments记录每个实例的面区间。

ConditionalDetail必须由原621F60等价分类结果提供。该函数涉及祖先CRandomGroup、权重、多个主题／特征字符串及运行时标志；本批没有根据名字、是否有Group或当前VISIBLE猜它。输入还必须是实际实例化候选，而非LAYOUT文件中所有描述对象。

静态顶点变换与独立射线不同 ​

原静态构建矩阵是：

scaled = I * S
matrix = R * scaled
matrix.setTrans(origin)
world_vertex = matrix * local_vertex

这是先把平移写进矩阵，再在原Matrix4乘Vector3中求和，最后存float。

独立物件命中点返回则是先存float形式的M*point，再做Vector3加origin。将后者复用到静态烘焙，会改变部分顶点末位；新增任意坐标／原代理三角形用例明确覆盖了这种差异。

468CC0还保留原面顺序并重定位追加顶点索引。6276组原生对照在一个已有三顶点／一面的目标缓存后追加新三角形，确认新增索引为3／4／5而非误写0／1／2。

随后469570从已变换顶点重新计算法线。非均匀／负缩放下不能复用“只旋转局部法线”的独立物件返回算法。 NOPATH为true时，追加面类别覆盖为100；否则保留原面类别。

原生对照边界与身份 ​

tools/native_room_bake_oracle.c在独立32位进程执行原：

• 4B92E0 → 622220 → 593720。
• Ogre矩阵函数 → 468CC0 → 469570。

模型／顶点数组由明确夹具提供；数组容量预分配足够，追加函数所需临时分配使用本进程malloc/free适配。未改原数学、追加或setter指令。 本测试不验证动态数组扩容、全部CGenericModel加载、完整场景注册或每顶点颜色链。

源EXE： 186472c3057b38f4cdff4696959a943c396ae6166995f7418997b5ea853e8a5e。 源Ogre： 974c1dc77ea2818276cc7eb94a8b95b2ccf8595e28fa3f14b2cd6d516fdb67a1。

实际代理样本：ZERAPHI_TOWN的WALL_01、BRIDGE_MID_01、STONE_03，共56个面，使用缓存保留的原始顶点与碰撞绕序。 所有输入在PC24／53／64分别运行；比较矩阵、变换后顶点、重建法线和面类别的原始bits。

当前10图输入预检 ​

后续：变体与父子姿态内核已实现，但实际地图初始随机状态和调用顺序仍缺，因此以下289项尚未标为实例级解析完成。

tools/audit_native_room_scene_inputs.py按现有转换器的种子0、每图主题／模板选择，读取当前实际源LAYOUT，不生成渲染资源或改存档。

范围：ACT1 TOWN、四个ECHO PASS、四个先烈通道、CLOCKWORK BOSS。共展开44981个Room Piece描述。

这些选中／启用候选的所有可能COLLISIONFILE均在当前解包资源中找到，没有引用前批97个缺源路径。暂不需要为了这10图的这组候选先解决那97项。

24467个启用候选中17380个没有COLLISIONFILE列表，这不是缺源：原Room Piece路径本就没有隐式视觉回落。 剩余未解析变体中，不能沿用旧渲染导出器“缺VISUAL时取FILE[0]”来假装已经复原原版同步随机选择。

严格限制：

• 这不是原版当前游戏种子的实例全集或加载顺序。
• 转换器选中状态、碰撞抑制标志不是原版完整运行时状态。
• MESH OVERRIDE、实际模型动画计数、姿态传播、条件分组与加载后的状态仍需生产方。
• 每份预检manifest明确native_instantiation_and_pose_verified=false，每个记录也不宣称运行时输入已就绪。

文件、验证与下一步 ​

• core_sim/NativeRoomBaking.cs：事件状态、静态矩阵、法线、两遍组装。
• build/native_room_bake_oracle/results.json：6276组追加和64组setter。
• build/native_room_scene_inputs/*.json：10图逐实例预检。
• build/native_room_bake_core.log：1185断言。
• build/native_room_bake_python.log：123项检查。

NativeRoomBakeInput及NativeBakedCollisionBatch登记为Transient，是单次构建输入／派生输出，目前没有持久会话所有者持有它们。未来接长期缓存时仍需按真实生命周期管理，不因临时分类而丢失状态。

按godot-master的数据／表现分层，本批没有改渲染或默认存档；main原地工作，未提交。默认存档hash： 9840fe858b6e311c73f8c2d4ed49912d59d71365f6278392811730e012d32a7f。

下一步优先补原版实例加载顺序、视觉变体与姿态传播，再处理空间分区候选和世界LOS消费者。实际线程精度仍需验证；全武器目标未完成。