three-base 2.0.193 → 2.0.195

package/MktMesh/MktMesh.d.ts

@@ -4,7 +4,6 @@ import { type PanoStitcher } from "./panoTileStitcher";
 import type { MktMeshData, MktTextureInfo, WallPoint, WallSide } from "./types";
 import { ImagePlane, type ImagePlaneData } from "./imagePlane";
 import { ModelSlot, type ModelSlotData } from "./modelSlot";
-import { GlassPane, type GlassPaneData } from "./glassPane";
 export default class MktMesh extends Mesh<BufferGeometry, ShaderMaterial> {
     /** 纹理列表（每个纹理的 url + 世界矩阵） */
     textures: MktTextureInfo[];
@@ -129,23 +128,6 @@ export default class MktMesh extends Mesh<BufferGeometry, ShaderMaterial> {
     imagePlanes: ImagePlane[];
     /** 模型槽层（同一棵子树，口径同上） */
     models: ModelSlot[];
-    /**
-     * 玻璃面层（⭐ 2026-10-28 需求「正方的面」）：同一棵子树，口径与上面两层一致。
-     * 与那两层的区别只在材质（MeshPhysicalMaterial + transmission + DoubleSide，见 `./glassPane.ts`）
-     * ⇒ 它**没有自己的内容纹理**，反射源共用下面那一张 `_glassEnvTex`。
-     */
-    glassPanes: GlassPane[];
-    /**
-     * 玻璃面反射环境的**源地址** = 第一个全景的整图地址（`textures[0].url`），空串 = 还没有全景可用。
-     * ⚠️ 这里存的是**未拼尺寸参数的原始地址**（与 `_texCache` 的键同一口径）⇒ 全景换了地址才发现要重载；
-     *    下载时按当前 `_ossSize` 档过 `resolveOssUrl`（默认为 1024 那一档）。PMREM 卷积输出的分辨率上限远小于 1024
-     *    ⇒ 反射精度由那一步决定，用缩放副本不降低观感，换来的是省掉整张原图（实测 11904×5952 ≈ 283MB）的解码内存。
-     * ⚠️ 为什么不用「第一个全景那两张拼合槽 RT」：每张 RT 装的是原图**左/右半幅**且压成 1:1 方图，
-     *    当等距柱状环境采会横向拉伸一倍 + 缺半边；且它的 mapping 是 UVMapping，three 不会替它做 PMREM ⇒ 采出花屏。
-     */
-    private _glassEnvKey;
-    /** 已就绪的反射环境纹理（null = 未就绪 / 没有全景）；同一张共用给所有玻璃面 ⇒ 只下载、只卷积一次 */
-    private _glassEnvTex;
     /**
      * 那 4 张瓦片的下载/解码缓存。⭐ 与全景 `_texCache` 同一条旨（10-02「纹理都缓存在对象里面，执行 dispose 时才销毁」）
      * ⇒ 切工程**不**清它，回来那一圈直接命中缓存、不会再空一格；只随本对象 `dispose()` 释放。
@@ -392,32 +374,6 @@ export default class MktMesh extends Mesh<BufferGeometry, ShaderMaterial> {
     private _queueModelMount;
     /** 全局队列里的那一帧：只挂这一槽，挂好才回调（`onEachLoad` = 按需渲染宿主的标脏钩子） */
     private _mountModelStep;
-    /** 单颗玻璃面入层（编辑态双击落点用）：进数组 + 挂进本对象子树 + 先吃当前反射源，再确认源在下路没有 */
-    addGlassPane(gp: GlassPane): GlassPane;
-    /** 摘掉一颗并释放它的几何/材质；反射纹理是共用那张 ⇒ 最后一颗也摘掉时才由 `syncGlassEnvironment` 收（按源地址记账，⛔ 不在这里直接 dispose） */
-    removeGlassPane(gp: GlassPane): void;
-    /**
-     * 整层重建玻璃面（`importData` 与预览那一路）。玻璃面不引用任何素材文件 ⇒ ⛔ 不过 `absAssetUrl`
-     * （地址只有反射源那一处，而它取的是**本对象内存里**的 `textures[0].url`，已经是补过域名的形态）。
-     */
-    setGlassPanes(datas: GlassPaneData[]): void;
-    /**
-     * 把「第一个全景」的整图当成玻璃面的反射环境（2026-10-28 需求）。
-     *
-     * 判据 = 源地址变了没有（⛔ 不按下标记：删掉 0 号景点后原 1 号自动顶上来，那时地址会变 ⇒ 自愈）。
-     * 调用点只有四处，⛔ 不进 `onBeforeRender` 自驱：① 单颗入层 ② 单颗摘除 ③ 整层重建 ④ 编辑态每帧 tick 里与
-     * `feedImagePlaneTiles()` 并排那一句（源地址没变就一句比较直接返回 ⇒ 无玻璃面的场景零成本，
-     * 而全景被增删/换图那些路都不必各自记得再来点一次）。
-     *
-     * ⚠️ 换源那一步必须**先摘后放**：材质还指着这张、位图却已 `close()` ⇒ 采出来是空图。
-     * ⚠️ 下载走 `loadPanoTexture`（解码在工作线程）并自动向 `DefaultLoadingManager` 记账 ⇒ 预览弹窗那个
-     *    加载进度条能看见它，与全景瓦片同一本账。
-     * ⚠️ 结果只存进 `_glassEnvTex`，⛔ 不进 `_texCache`：那张表在 `setOssSize` 换档时会被整批 dispose
-     *    （`_reloadActiveTexture`），而正在被材质引用的这张不能被那样顺手清掉。
-     */
-    syncGlassEnvironment(): void;
-    /** 把同一张反射源发给每一颗玻璃面（`GlassPane` 内部按对象判等 ⇒ 重复发同一张不会重编译）。 */
-    private _applyGlassEnv;
     /**
      * 把各颗平面那 4 张瓦片的纹理绑进材质（10-22 晚定的口径：不走拼合器 RT）。
      * 2026-10-26 决定改成**逐帧**：一次把整层地址全丢给下载器（下载/解码在网络与工作线程侧，不占这一帧），
@@ -450,34 +406,37 @@ export default class MktMesh extends Mesh<BufferGeometry, ShaderMaterial> {
      *  @param onModelLoad 每只 GLB 落地时回调一次（可选）——按需渲染的宿主（编辑器）拿它标脏；每帧真画的预览不传 */
     importData(data: MktMeshData, projName?: string, onModelLoad?: () => void): void;
     /**
-     * 把**存档里前 `PANO_IMPORT_PRIORITY` 个全景**的素材点名抢在别的之前加载（2026-10-29 需求）。
+     * 把**存档里前 `PANO_IMPORT_PRIORITY` 个全景**按存档顺序登记进拼合器的**加载任务队列**
+     *（2026-10-29 需求「优先加载前 2 个全景素材」+ 2026-10-30 需求逐字：「给 mktmesh 内部加一个加载任务队列，
+     *  把模型和平面图排在最前面，然后按照顺序，依次把前 2 个全景的顺序把瓦片加载任务添加到任务队列里面，
+     *  第一个加载完了，就把这个加载任务从任务队列里面去掉，然后加载第二个；
+     *  如果后续再按照距离计算需要加载哪个全景的时候，同样地添加到加载任务队列的后面等待加载」）。
      * 由两处渲染循环每帧点一次：基类 `onBeforeRender`（预览弹窗 / 发布页）与编辑器的 `updateFloorTexture`
      *（`MktDevMesh` 覆写了 `onBeforeRender`，只点 `syncProjInvMatrix` + `tickProgressiveReveal`，库内那句在编辑态不跑）。
      *
-     * 为什么能「先加载」：拼合器每帧那三道工序（补下载 → 画已进 GPU 的 → 再传一张）都按
-     *   `_groups` 这张 Map 的**在册顺序**取料，而下载额度只有「每帧 2 张 / 在途 ≤8 / 已解码待上传 ≤8」
-     *   （`panoTileStitcher.ts` 顶部那三个常数）⇒ 排在头部的两组把额度吃满，其余全景要等它们画满才轮得到。
-     *   平时这个顺序由每帧的槽位名册定（离注视点近的先下），本方法把它钉成「存档数组的前两个」，与机位无关。
-     * ⚠️⚠️ 为什么点名时要带第三个参 `front = true`（每帧把这两批**挪回队首**）而⛔ 不只是「先入册」：
-     *   在册顺序是拼合器自己的状态 —— 后入册的只会**追加到队尾**，而 `ensure` 幂等、已在册就不再移动。
-     *   预览这条路恰好是最坏的那种排法：`feedFaceMapping` 开头还有一记 `pump`，拼合器**第一次**拿到渲染器时
-     *   必走 `_switchRenderer`（`null → 真 renderer` 也算换，弹窗每开一次就是换一次）把在册组整份作废，
-     *   随后名册按距离重新入册占了队首 ⇒ 本方法下一帧重新入册只能排在它们后面，而且**从此再也翻不了身**。
-     *   2026-10-29 逐帧打点就是这个形状：帧 1 `p0,p1,p11…p4` → 帧 2 起 `p11…p4,p0,p1`，
-     *   40 帧下来 p0 只下到 1 片、p1 下到 30 片，离注视点最近那颗第 13 条请求就开始了 = 线上报的现象。
-     *   ⇒ 带 `front` 之后顺序每帧重新成立，与谁先入册、作废过几次、机位在哪都无关
-     *   （真跑自证在护栏 BE ④：`D` 后入册排队尾，带 `front` 再点一次 ⇒ 立刻回到队首、下一帧下载全归它）。
-     * ⚠️ 为什么是**每帧**而不是「载入那一次点一记」：上面那次作废就发生在载入之后的第一帧，
-     *   只在 `importData` 里点名等于白点；本方法点在 `pump` 之后、名册逐槽 `ensure` 之前，且每帧都点
-     *   （已在册且已在队首 ⇒ `_toFront` 里一次 `keys().next()` 就返回，没有额外开销）。
-     * ⛔ 不另立第二把下载尺：这里用的就是 `feedFaceMapping` 每帧在用的同一个 `ensure(info.tiles, …)`
-     *   与同一个批次键（第一条非空瓦片地址）⇒ 后面那句自然判重，一片瓦片终身只 `fetch` 一次。
+     * 队列怎么排（`panoTileStitcher` 的 `_queue`，一处排队一张尺）：
+     *   ① **模型与平面图天然在最前面** —— 这两族的下载不在拼合器里，`importData` 当场同步发起
+     *      （GLB 逐只 `loadModel` 不 throttle；平面那 4 片一次性 `_imgTileLoader.preload`），
+     *      而全景瓦片最早也要等下一帧的 `pump` 才发第一片 ⇒ 发起次序天然是「模型 → 平面图 → 全景」，
+     *      ⛔ 这里不再把它们塞进队列重复管一遍（塞了就是第二把尺）。
+     *   ② 本方法把存档 0 号、1 号依次 `prioritize` 进队列 ⇒ 拼合器每帧**只喂队首那一组**，
+     *      0 号 32 格全落定（画进 RT，或该格本就缺地址/判死）才出队、1 号才开始发第一片。
+     *      比 10-29 那版（只是把两批挪到在册顺序前面、额度仍被两批分摊）更硬：**第 1 颗独享额度，最快出全图**。
+     *   ③ 名册按距离点到的其他全景走 `feedFaceMapping` 里那句 `ensure(t.tiles)`（不带队列）⇒ 只入册、
+     *      排在队列后面等，队列空了才按在册顺序补料（现行口径不变）。
+     * ⚠️⚠️ 为什么每帧点而⛔ 只在 `importData` 里点一记：预览每开一次都换渲染器，`_switchRenderer` 把在册组
+     *   整份作废（队列里的键也在同一刻失效）；只在载入那次点名等于白点。本方法点在 `pump` 之后、名册逐槽
+     *   `ensure` 之前 ⇒ 每帧把这两记任务补回队列头部（`prioritize` 幂等，已在队列里就不挪，所以 0 号恒在 1 号前）。
+     * ⚠️ 代价如实记：
+     *   · 队列非空时**其他全景一片都不发** ⇒ 开机那几秒里，离注视点最近、但不在存档前两颗的那面墙会多灰一会儿。
+     *   · 一颗「永远下不完」的瓦片（下载失败还没累计到判死）会压住队列；判死阈值是解码失败 3 次
+     *     （`_dead`），退避重试期间队首不落定 ⇒ 第 2 颗跟着延后。真实数据里缺片是「地址为空/404」，
+     *     404 走三次即判死、那一格拼合涂灰 ⇒ 队列照样出清。
+     *   · 这两颗全景若本来不在开机那一刻的名册里，它们的瓦片与拼合槽 RT 会被**提前**建出来
+     *     （现行口径每颗全景 2 槽 × 6144² ≈ 384MB 显存）—— 组在运行中不淘汰，走进这两个景点迟早要建。
      * ⚠️ 形态判据读 `this._panoTexMode`（整图形态那一档一张全景只有一张整图，走 `_texCache` 那条路，
      *   走错档就是白下 32 片）⇒ 宿主若用自己那份形态变量（编辑器的 `store.panoTexMode`），
      *   要在调 `importData` 之前先 `setPanoTexMode` 推进来，编辑器那侧已按此接线。
-     * ⚠️ 代价如实记：这两颗全景若本来不在开机那一刻的名册里，它们的瓦片与拼合槽 RT 会被**提前**建出来
-     *   （现行口径每颗全景 2 槽 × 6144² ≈ 400MB 显存）—— 组在运行中不淘汰，走进那两个景点迟早要建，
-     *   这里只是把这一笔挪到了载入的第一帧。
      */
     prefetchHeadPanoramas(): void;
     /** 释放 GPU 资源：瓦片缓存（**只有这里**清，2026-10-02 决定）、拼合器、平面图 / 模型 / 玻璃面三层、几何、材质 */

package/MktMesh/MktMesh.js

@@ -23,7 +23,7 @@
  * 说明：所有实例共享同一份 material（单一 panorama uniform），
  * 同一时刻只激活名册 0 号槽（中心）那一个纹理（全局共享单激活方案）。
  */
-import { BufferGeometry, BackSide, EquirectangularReflectionMapping, Float32BufferAttribute, Matrix4, Mesh, Shape, ShapeGeometry, SRGBColorSpace, Vector3, Vector4, } from "three";
+import { BufferGeometry, BackSide, Float32BufferAttribute, Matrix4, Mesh, Shape, ShapeGeometry, SRGBColorSpace, Vector3, Vector4, } from "three";
 import { createPlaceholderTexture, isPanoTexMode, mktPanoTiledFlag, mktPanoTexUrls, isRtStitchKey, rtStitchKeyParts, RT_STITCH_KEY_PREFIX, RT_STITCH_SLOT_COUNT } from "./mktShader";
 import { MKT_PANO_MAX_SLOTS } from "./mktMappingShader";
 import { createMktFloorMappingShaderMaterial } from "./mktMappingShader";
@@ -51,9 +51,6 @@ import { stripAssetHost, absAssetUrl } from "./assetUrl";
 import { ImagePlane } from "./imagePlane";
 import { ModelSlot } from "./modelSlot";
 import { ImagePlaneTileLoader } from "./imageTileLoader";
-// ⭐ 2026-10-28 需求「正方的面 + 双面 + 反射用第一个全景 + 进 json 回显」：第三层，形状与上面两层同口径
-//   （挂在本网格子树、随展品一起走；数据由自己的 `toData/applyData` 逐字存）。
-import { GlassPane } from "./glassPane";
 /** 载入 JSON 时**优先**加载几个全景的素材（2026-10-29 需求「优先加载前 2 个全景图的素材，然后再加载其他的」）。
  *  口径 = 存档 `textures` 数组的前 n 项；其余全景照常按每帧的槽位名册（离注视点最近 8 个）排队，只是排在它们后面。 */
 const PANO_IMPORT_PRIORITY = 2;
@@ -191,23 +188,6 @@ export default class MktMesh extends Mesh {
     imagePlanes = [];
     /** 模型槽层（同一棵子树，口径同上） */
     models = [];
-    /**
-     * 玻璃面层（⭐ 2026-10-28 需求「正方的面」）：同一棵子树，口径与上面两层一致。
-     * 与那两层的区别只在材质（MeshPhysicalMaterial + transmission + DoubleSide，见 `./glassPane.ts`）
-     * ⇒ 它**没有自己的内容纹理**，反射源共用下面那一张 `_glassEnvTex`。
-     */
-    glassPanes = [];
-    /**
-     * 玻璃面反射环境的**源地址** = 第一个全景的整图地址（`textures[0].url`），空串 = 还没有全景可用。
-     * ⚠️ 这里存的是**未拼尺寸参数的原始地址**（与 `_texCache` 的键同一口径）⇒ 全景换了地址才发现要重载；
-     *    下载时按当前 `_ossSize` 档过 `resolveOssUrl`（默认为 1024 那一档）。PMREM 卷积输出的分辨率上限远小于 1024
-     *    ⇒ 反射精度由那一步决定，用缩放副本不降低观感，换来的是省掉整张原图（实测 11904×5952 ≈ 283MB）的解码内存。
-     * ⚠️ 为什么不用「第一个全景那两张拼合槽 RT」：每张 RT 装的是原图**左/右半幅**且压成 1:1 方图，
-     *    当等距柱状环境采会横向拉伸一倍 + 缺半边；且它的 mapping 是 UVMapping，three 不会替它做 PMREM ⇒ 采出花屏。
-     */
-    _glassEnvKey = "";
-    /** 已就绪的反射环境纹理（null = 未就绪 / 没有全景）；同一张共用给所有玻璃面 ⇒ 只下载、只卷积一次 */
-    _glassEnvTex = null;
     /**
      * 那 4 张瓦片的下载/解码缓存。⭐ 与全景 `_texCache` 同一条旨（10-02「纹理都缓存在对象里面，执行 dispose 时才销毁」）
      * ⇒ 切工程**不**清它，回来那一圈直接命中缓存、不会再空一格；只随本对象 `dispose()` 释放。
@@ -1211,91 +1191,6 @@ export default class MktMesh extends Mesh {
         if (ms.mountStaged() && onEachLoad)
             onEachLoad();
     }
-    // ───────────── 玻璃面层（⭐ 2026-10-28 需求「正方的面：双面 + 反射用第一个全景 + 进 json 回显」） ─────────────
-    /** 单颗玻璃面入层（编辑态双击落点用）：进数组 + 挂进本对象子树 + 先吃当前反射源，再确认源在下路没有 */
-    addGlassPane(gp) {
-        this.glassPanes.push(gp);
-        this.add(gp);
-        gp.setEnvironmentTexture(this._glassEnvTex);
-        this.syncGlassEnvironment();
-        return gp;
-    }
-    /** 摘掉一颗并释放它的几何/材质；反射纹理是共用那张 ⇒ 最后一颗也摘掉时才由 `syncGlassEnvironment` 收（按源地址记账，⛔ 不在这里直接 dispose） */
-    removeGlassPane(gp) {
-        const i = this.glassPanes.indexOf(gp);
-        if (i >= 0)
-            this.glassPanes.splice(i, 1);
-        this.remove(gp);
-        gp.dispose();
-        this.syncGlassEnvironment();
-    }
-    /**
-     * 整层重建玻璃面（`importData` 与预览那一路）。玻璃面不引用任何素材文件 ⇒ ⛔ 不过 `absAssetUrl`
-     * （地址只有反射源那一处，而它取的是**本对象内存里**的 `textures[0].url`，已经是补过域名的形态）。
-     */
-    setGlassPanes(datas) {
-        for (const gp of this.glassPanes) {
-            this.remove(gp);
-            gp.dispose();
-        }
-        this.glassPanes = [];
-        for (const d of datas) {
-            const gp = new GlassPane(d.name);
-            gp.applyData(d);
-            this.glassPanes.push(gp);
-            this.add(gp);
-        }
-        this.syncGlassEnvironment();
-    }
-    /**
-     * 把「第一个全景」的整图当成玻璃面的反射环境（2026-10-28 需求）。
-     *
-     * 判据 = 源地址变了没有（⛔ 不按下标记：删掉 0 号景点后原 1 号自动顶上来，那时地址会变 ⇒ 自愈）。
-     * 调用点只有四处，⛔ 不进 `onBeforeRender` 自驱：① 单颗入层 ② 单颗摘除 ③ 整层重建 ④ 编辑态每帧 tick 里与
-     * `feedImagePlaneTiles()` 并排那一句（源地址没变就一句比较直接返回 ⇒ 无玻璃面的场景零成本，
-     * 而全景被增删/换图那些路都不必各自记得再来点一次）。
-     *
-     * ⚠️ 换源那一步必须**先摘后放**：材质还指着这张、位图却已 `close()` ⇒ 采出来是空图。
-     * ⚠️ 下载走 `loadPanoTexture`（解码在工作线程）并自动向 `DefaultLoadingManager` 记账 ⇒ 预览弹窗那个
-     *    加载进度条能看见它，与全景瓦片同一本账。
-     * ⚠️ 结果只存进 `_glassEnvTex`，⛔ 不进 `_texCache`：那张表在 `setOssSize` 换档时会被整批 dispose
-     *    （`_reloadActiveTexture`），而正在被材质引用的这张不能被那样顺手清掉。
-     */
-    syncGlassEnvironment() {
-        // 没有玻璃面 ⇒ 源地址按「空」算：下面那一段照常走换源流程，把共用那张位图关干净（⛔ 不让它悬着）
-        const key = this.glassPanes.length === 0 ? "" : (this.textures[0]?.url ?? "");
-        if (key === this._glassEnvKey)
-            return;
-        this._glassEnvKey = key;
-        if (this._glassEnvTex) {
-            this._applyGlassEnv(null);
-            releasePanoTexture(this._glassEnvTex);
-            this._glassEnvTex = null;
-        }
-        if (!key)
-            return;
-        loadPanoTexture(this.resolveOssUrl(key, false)).then((tex) => {
-            // 这一张到货时源可能已被后来的换源（切项目 / 换全景）顶掉 ⇒ 就地释放，⛔ 不许写回材质
-            if (this._glassEnvKey !== key) {
-                releasePanoTexture(tex);
-                return;
-            }
-            tex.colorSpace = SRGBColorSpace;
-            // three 的 `WebGLCubeUVMaps` 只对这个标记才自动 PMREM 卷积（示例也是把等距柱状图直接挂 material.envMap）
-            tex.mapping = EquirectangularReflectionMapping;
-            this._glassEnvTex = tex;
-            this._applyGlassEnv(tex);
-        }, () => {
-            // 单次失败：清掉记账 ⇒ 下一次有人调本方法（新增/重建玻璃面、编辑态 tick）自然重试，
-            // 与全景瓦片那条「失败后下一帧同键再试」同口径，只是这里由调用点驱动而非每帧驱动。
-            this._glassEnvKey = "";
-        });
-    }
-    /** 把同一张反射源发给每一颗玻璃面（`GlassPane` 内部按对象判等 ⇒ 重复发同一张不会重编译）。 */
-    _applyGlassEnv(tex) {
-        for (const gp of this.glassPanes)
-            gp.setEnvironmentTexture(tex);
-    }
     /**
      * 把各颗平面那 4 张瓦片的纹理绑进材质（10-22 晚定的口径：不走拼合器 RT）。
      * 2026-10-26 决定改成**逐帧**：一次把整层地址全丢给下载器（下载/解码在网络与工作线程侧，不占这一帧），
@@ -1417,9 +1312,6 @@ export default class MktMesh extends Mesh {
                 const d = ms.toData();
                 return { ...d, url: d.url ? stripAssetHost(d.url, pn) : "" };
             }),
-            // 玻璃面层（2026-10-28 需求）：只有位置/旋转/边长，⛔ 不过 `stripAssetHost` —— 它不引用任何素材，
-            //   反射源是运行时从 `textures[0].url` 取的（上面那个键自己就落进存档了）。
-            glass: this.glassPanes.map((gp) => gp.toData()),
         };
     }
     /** 导入数据：重建墙体几何与纹理列表，并激活第一个纹理
@@ -1475,51 +1367,48 @@ export default class MktMesh extends Mesh {
             tiles: (d.tiles ?? []).map((u) => absAssetUrl(u, pn)),
         })));
         this.setModels((data.models ?? []).map((d) => ({ ...d, url: d.url ? absAssetUrl(d.url, pn) : "" })), onModelLoad);
-        // 玻璃面层（2026-10-28 需求）：排在 setTextures **之后**是硬要求 —— 它的反射源读的就是刚还原好的
-        //   `textures[0].url`（补过域名的形态），排在前面会用上一次项目的地址起一次错的载。
-        //   旧存档没有这个键 ⇒ 空数组 = 整层清空，与上面两层的口径逐字一致。
-        this.setGlassPanes(data.glass ?? []);
     }
     /**
-     * 把**存档里前 `PANO_IMPORT_PRIORITY` 个全景**的素材点名抢在别的之前加载（2026-10-29 需求）。
+     * 把**存档里前 `PANO_IMPORT_PRIORITY` 个全景**按存档顺序登记进拼合器的**加载任务队列**
+     *（2026-10-29 需求「优先加载前 2 个全景素材」+ 2026-10-30 需求逐字：「给 mktmesh 内部加一个加载任务队列，
+     *  把模型和平面图排在最前面，然后按照顺序，依次把前 2 个全景的顺序把瓦片加载任务添加到任务队列里面，
+     *  第一个加载完了，就把这个加载任务从任务队列里面去掉，然后加载第二个；
+     *  如果后续再按照距离计算需要加载哪个全景的时候，同样地添加到加载任务队列的后面等待加载」）。
      * 由两处渲染循环每帧点一次：基类 `onBeforeRender`（预览弹窗 / 发布页）与编辑器的 `updateFloorTexture`
      *（`MktDevMesh` 覆写了 `onBeforeRender`，只点 `syncProjInvMatrix` + `tickProgressiveReveal`，库内那句在编辑态不跑）。
      *
-     * 为什么能「先加载」：拼合器每帧那三道工序（补下载 → 画已进 GPU 的 → 再传一张）都按
-     *   `_groups` 这张 Map 的**在册顺序**取料，而下载额度只有「每帧 2 张 / 在途 ≤8 / 已解码待上传 ≤8」
-     *   （`panoTileStitcher.ts` 顶部那三个常数）⇒ 排在头部的两组把额度吃满，其余全景要等它们画满才轮得到。
-     *   平时这个顺序由每帧的槽位名册定（离注视点近的先下），本方法把它钉成「存档数组的前两个」，与机位无关。
-     * ⚠️⚠️ 为什么点名时要带第三个参 `front = true`（每帧把这两批**挪回队首**）而⛔ 不只是「先入册」：
-     *   在册顺序是拼合器自己的状态 —— 后入册的只会**追加到队尾**，而 `ensure` 幂等、已在册就不再移动。
-     *   预览这条路恰好是最坏的那种排法：`feedFaceMapping` 开头还有一记 `pump`，拼合器**第一次**拿到渲染器时
-     *   必走 `_switchRenderer`（`null → 真 renderer` 也算换，弹窗每开一次就是换一次）把在册组整份作废，
-     *   随后名册按距离重新入册占了队首 ⇒ 本方法下一帧重新入册只能排在它们后面，而且**从此再也翻不了身**。
-     *   2026-10-29 逐帧打点就是这个形状：帧 1 `p0,p1,p11…p4` → 帧 2 起 `p11…p4,p0,p1`，
-     *   40 帧下来 p0 只下到 1 片、p1 下到 30 片，离注视点最近那颗第 13 条请求就开始了 = 线上报的现象。
-     *   ⇒ 带 `front` 之后顺序每帧重新成立，与谁先入册、作废过几次、机位在哪都无关
-     *   （真跑自证在护栏 BE ④：`D` 后入册排队尾，带 `front` 再点一次 ⇒ 立刻回到队首、下一帧下载全归它）。
-     * ⚠️ 为什么是**每帧**而不是「载入那一次点一记」：上面那次作废就发生在载入之后的第一帧，
-     *   只在 `importData` 里点名等于白点；本方法点在 `pump` 之后、名册逐槽 `ensure` 之前，且每帧都点
-     *   （已在册且已在队首 ⇒ `_toFront` 里一次 `keys().next()` 就返回，没有额外开销）。
-     * ⛔ 不另立第二把下载尺：这里用的就是 `feedFaceMapping` 每帧在用的同一个 `ensure(info.tiles, …)`
-     *   与同一个批次键（第一条非空瓦片地址）⇒ 后面那句自然判重，一片瓦片终身只 `fetch` 一次。
+     * 队列怎么排（`panoTileStitcher` 的 `_queue`，一处排队一张尺）：
+     *   ① **模型与平面图天然在最前面** —— 这两族的下载不在拼合器里，`importData` 当场同步发起
+     *      （GLB 逐只 `loadModel` 不 throttle；平面那 4 片一次性 `_imgTileLoader.preload`），
+     *      而全景瓦片最早也要等下一帧的 `pump` 才发第一片 ⇒ 发起次序天然是「模型 → 平面图 → 全景」，
+     *      ⛔ 这里不再把它们塞进队列重复管一遍（塞了就是第二把尺）。
+     *   ② 本方法把存档 0 号、1 号依次 `prioritize` 进队列 ⇒ 拼合器每帧**只喂队首那一组**，
+     *      0 号 32 格全落定（画进 RT，或该格本就缺地址/判死）才出队、1 号才开始发第一片。
+     *      比 10-29 那版（只是把两批挪到在册顺序前面、额度仍被两批分摊）更硬：**第 1 颗独享额度，最快出全图**。
+     *   ③ 名册按距离点到的其他全景走 `feedFaceMapping` 里那句 `ensure(t.tiles)`（不带队列）⇒ 只入册、
+     *      排在队列后面等，队列空了才按在册顺序补料（现行口径不变）。
+     * ⚠️⚠️ 为什么每帧点而⛔ 只在 `importData` 里点一记：预览每开一次都换渲染器，`_switchRenderer` 把在册组
+     *   整份作废（队列里的键也在同一刻失效）；只在载入那次点名等于白点。本方法点在 `pump` 之后、名册逐槽
+     *   `ensure` 之前 ⇒ 每帧把这两记任务补回队列头部（`prioritize` 幂等，已在队列里就不挪，所以 0 号恒在 1 号前）。
+     * ⚠️ 代价如实记：
+     *   · 队列非空时**其他全景一片都不发** ⇒ 开机那几秒里，离注视点最近、但不在存档前两颗的那面墙会多灰一会儿。
+     *   · 一颗「永远下不完」的瓦片（下载失败还没累计到判死）会压住队列；判死阈值是解码失败 3 次
+     *     （`_dead`），退避重试期间队首不落定 ⇒ 第 2 颗跟着延后。真实数据里缺片是「地址为空/404」，
+     *     404 走三次即判死、那一格拼合涂灰 ⇒ 队列照样出清。
+     *   · 这两颗全景若本来不在开机那一刻的名册里，它们的瓦片与拼合槽 RT 会被**提前**建出来
+     *     （现行口径每颗全景 2 槽 × 6144² ≈ 384MB 显存）—— 组在运行中不淘汰，走进这两个景点迟早要建。
      * ⚠️ 形态判据读 `this._panoTexMode`（整图形态那一档一张全景只有一张整图，走 `_texCache` 那条路，
      *   走错档就是白下 32 片）⇒ 宿主若用自己那份形态变量（编辑器的 `store.panoTexMode`），
      *   要在调 `importData` 之前先 `setPanoTexMode` 推进来，编辑器那侧已按此接线。
-     * ⚠️ 代价如实记：这两颗全景若本来不在开机那一刻的名册里，它们的瓦片与拼合槽 RT 会被**提前**建出来
-     *   （现行口径每颗全景 2 槽 × 6144² ≈ 400MB 显存）—— 组在运行中不淘汰，走进那两个景点迟早要建，
-     *   这里只是把这一笔挪到了载入的第一帧。
      */
     prefetchHeadPanoramas() {
         const n = Math.min(PANO_IMPORT_PRIORITY, this.textures.length);
-        // ⚠️ **倒着**点：`front` 是「挪到最前」，正着点会让 0 号被 1 号压到后面（实测队首变成 `p1,p0`）
-        //   ⇒ 倒着点，最后一手挪的是 0 号，存档序号小的仍排在更前。
-        for (let i = n - 1; i >= 0; i--) {
+        // 正着点：0 号先入队 ⇒ 队首是它，落定后才轮到 1 号（`prioritize` 对已在队列里的键不挪位置）
+        for (let i = 0; i < n; i++) {
             const info = this.textures[i];
             // 与 `feedFaceMapping` 里那一句同判据：真瓦片才进拼合器，整图形态进瓦片缓存
-            // 第三个参 `true` = 把这批**挪到在册顺序最前**（⛔ 光靠「先入册」押不住顺序，见方法头）
             if (mktPanoTiledFlag(info.tiles, this._panoTexMode) === 1)
-                this._stitcher.ensure(info.tiles, undefined, true);
+                this._stitcher.prioritize(info.tiles);
             else if (info.url)
                 this.ensureTileTexture(info.url, false);
         }
@@ -1548,16 +1437,6 @@ export default class MktMesh extends Mesh {
             ms.dispose();
         }
         this.models = [];
-        // 玻璃面层：几何/材质各归各颗释放；那张共用的反射纹理在这里连位图一起关
-        //   （⛔ 它从不在 `_texCache` 里 ⇒ 上面那一轮清不到它，漏了这一句就是每次换页漏一张全景整图）。
-        for (const gp of this.glassPanes) {
-            this.remove(gp);
-            gp.dispose();
-        }
-        this.glassPanes = [];
-        releasePanoTexture(this._glassEnvTex);
-        this._glassEnvTex = null;
-        this._glassEnvKey = "";
         this._imgTileLoader.clear();
         this._imgBindQueued.clear();
         this._imgBindDone.clear();

package/MktMesh/MktMesh.ts

@@ -28,7 +28,6 @@ import {
     BufferGeometry,
     Camera,
     BackSide,
-    EquirectangularReflectionMapping,
     Float32BufferAttribute,
     Material,
     Matrix4,
@@ -72,9 +71,6 @@ import { stripAssetHost, absAssetUrl } from "./assetUrl";
 import { ImagePlane, type ImagePlaneData } from "./imagePlane";
 import { ModelSlot, type ModelSlotData } from "./modelSlot";
 import { ImagePlaneTileLoader } from "./imageTileLoader";
-// ⭐ 2026-10-28 需求「正方的面 + 双面 + 反射用第一个全景 + 进 json 回显」：第三层，形状与上面两层同口径
-//   （挂在本网格子树、随展品一起走；数据由自己的 `toData/applyData` 逐字存）。
-import { GlassPane, type GlassPaneData } from "./glassPane";
 
 /** 载入 JSON 时**优先**加载几个全景的素材（2026-10-29 需求「优先加载前 2 个全景图的素材，然后再加载其他的」）。
  *  口径 = 存档 `textures` 数组的前 n 项；其余全景照常按每帧的槽位名册（离注视点最近 8 个）排队，只是排在它们后面。 */
@@ -219,23 +215,6 @@ export default class MktMesh extends Mesh<BufferGeometry, ShaderMaterial> {
     imagePlanes: ImagePlane[] = [];
     /** 模型槽层（同一棵子树，口径同上） */
     models: ModelSlot[] = [];
-    /**
-     * 玻璃面层（⭐ 2026-10-28 需求「正方的面」）：同一棵子树，口径与上面两层一致。
-     * 与那两层的区别只在材质（MeshPhysicalMaterial + transmission + DoubleSide，见 `./glassPane.ts`）
-     * ⇒ 它**没有自己的内容纹理**，反射源共用下面那一张 `_glassEnvTex`。
-     */
-    glassPanes: GlassPane[] = [];
-    /**
-     * 玻璃面反射环境的**源地址** = 第一个全景的整图地址（`textures[0].url`），空串 = 还没有全景可用。
-     * ⚠️ 这里存的是**未拼尺寸参数的原始地址**（与 `_texCache` 的键同一口径）⇒ 全景换了地址才发现要重载；
-     *    下载时按当前 `_ossSize` 档过 `resolveOssUrl`（默认为 1024 那一档）。PMREM 卷积输出的分辨率上限远小于 1024
-     *    ⇒ 反射精度由那一步决定，用缩放副本不降低观感，换来的是省掉整张原图（实测 11904×5952 ≈ 283MB）的解码内存。
-     * ⚠️ 为什么不用「第一个全景那两张拼合槽 RT」：每张 RT 装的是原图**左/右半幅**且压成 1:1 方图，
-     *    当等距柱状环境采会横向拉伸一倍 + 缺半边；且它的 mapping 是 UVMapping，three 不会替它做 PMREM ⇒ 采出花屏。
-     */
-    private _glassEnvKey: string = "";
-    /** 已就绪的反射环境纹理（null = 未就绪 / 没有全景）；同一张共用给所有玻璃面 ⇒ 只下载、只卷积一次 */
-    private _glassEnvTex: Texture | null = null;
     /**
      * 那 4 张瓦片的下载/解码缓存。⭐ 与全景 `_texCache` 同一条旨（10-02「纹理都缓存在对象里面，执行 dispose 时才销毁」）
      * ⇒ 切工程**不**清它，回来那一圈直接命中缓存、不会再空一格；只随本对象 `dispose()` 释放。
@@ -1247,96 +1226,6 @@ export default class MktMesh extends Mesh<BufferGeometry, ShaderMaterial> {
         if (ms.mountStaged() && onEachLoad) onEachLoad();
     }
 
-    // ───────────── 玻璃面层（⭐ 2026-10-28 需求「正方的面：双面 + 反射用第一个全景 + 进 json 回显」） ─────────────
-
-    /** 单颗玻璃面入层（编辑态双击落点用）：进数组 + 挂进本对象子树 + 先吃当前反射源，再确认源在下路没有 */
-    addGlassPane(gp: GlassPane): GlassPane {
-        this.glassPanes.push(gp);
-        this.add(gp);
-        gp.setEnvironmentTexture(this._glassEnvTex);
-        this.syncGlassEnvironment();
-        return gp;
-    }
-
-    /** 摘掉一颗并释放它的几何/材质；反射纹理是共用那张 ⇒ 最后一颗也摘掉时才由 `syncGlassEnvironment` 收（按源地址记账，⛔ 不在这里直接 dispose） */
-    removeGlassPane(gp: GlassPane): void {
-        const i = this.glassPanes.indexOf(gp);
-        if (i >= 0) this.glassPanes.splice(i, 1);
-        this.remove(gp);
-        gp.dispose();
-        this.syncGlassEnvironment();
-    }
-
-    /**
-     * 整层重建玻璃面（`importData` 与预览那一路）。玻璃面不引用任何素材文件 ⇒ ⛔ 不过 `absAssetUrl`
-     * （地址只有反射源那一处，而它取的是**本对象内存里**的 `textures[0].url`，已经是补过域名的形态）。
-     */
-    setGlassPanes(datas: GlassPaneData[]): void {
-        for (const gp of this.glassPanes) {
-            this.remove(gp);
-            gp.dispose();
-        }
-        this.glassPanes = [];
-        for (const d of datas) {
-            const gp = new GlassPane(d.name);
-            gp.applyData(d);
-            this.glassPanes.push(gp);
-            this.add(gp);
-        }
-        this.syncGlassEnvironment();
-    }
-
-    /**
-     * 把「第一个全景」的整图当成玻璃面的反射环境（2026-10-28 需求）。
-     *
-     * 判据 = 源地址变了没有（⛔ 不按下标记：删掉 0 号景点后原 1 号自动顶上来，那时地址会变 ⇒ 自愈）。
-     * 调用点只有四处，⛔ 不进 `onBeforeRender` 自驱：① 单颗入层 ② 单颗摘除 ③ 整层重建 ④ 编辑态每帧 tick 里与
-     * `feedImagePlaneTiles()` 并排那一句（源地址没变就一句比较直接返回 ⇒ 无玻璃面的场景零成本，
-     * 而全景被增删/换图那些路都不必各自记得再来点一次）。
-     *
-     * ⚠️ 换源那一步必须**先摘后放**：材质还指着这张、位图却已 `close()` ⇒ 采出来是空图。
-     * ⚠️ 下载走 `loadPanoTexture`（解码在工作线程）并自动向 `DefaultLoadingManager` 记账 ⇒ 预览弹窗那个
-     *    加载进度条能看见它，与全景瓦片同一本账。
-     * ⚠️ 结果只存进 `_glassEnvTex`，⛔ 不进 `_texCache`：那张表在 `setOssSize` 换档时会被整批 dispose
-     *    （`_reloadActiveTexture`），而正在被材质引用的这张不能被那样顺手清掉。
-     */
-    syncGlassEnvironment(): void {
-        // 没有玻璃面 ⇒ 源地址按「空」算：下面那一段照常走换源流程，把共用那张位图关干净（⛔ 不让它悬着）
-        const key = this.glassPanes.length === 0 ? "" : (this.textures[0]?.url ?? "");
-        if (key === this._glassEnvKey) return;
-        this._glassEnvKey = key;
-        if (this._glassEnvTex) {
-            this._applyGlassEnv(null);
-            releasePanoTexture(this._glassEnvTex);
-            this._glassEnvTex = null;
-        }
-        if (!key) return;
-        loadPanoTexture(this.resolveOssUrl(key, false)).then(
-            (tex) => {
-                // 这一张到货时源可能已被后来的换源（切项目 / 换全景）顶掉 ⇒ 就地释放，⛔ 不许写回材质
-                if (this._glassEnvKey !== key) {
-                    releasePanoTexture(tex);
-                    return;
-                }
-                tex.colorSpace = SRGBColorSpace;
-                // three 的 `WebGLCubeUVMaps` 只对这个标记才自动 PMREM 卷积（示例也是把等距柱状图直接挂 material.envMap）
-                tex.mapping = EquirectangularReflectionMapping;
-                this._glassEnvTex = tex;
-                this._applyGlassEnv(tex);
-            },
-            () => {
-                // 单次失败：清掉记账 ⇒ 下一次有人调本方法（新增/重建玻璃面、编辑态 tick）自然重试，
-                // 与全景瓦片那条「失败后下一帧同键再试」同口径，只是这里由调用点驱动而非每帧驱动。
-                this._glassEnvKey = "";
-            }
-        );
-    }
-
-    /** 把同一张反射源发给每一颗玻璃面（`GlassPane` 内部按对象判等 ⇒ 重复发同一张不会重编译）。 */
-    private _applyGlassEnv(tex: Texture | null): void {
-        for (const gp of this.glassPanes) gp.setEnvironmentTexture(tex);
-    }
-
     /**
      * 把各颗平面那 4 张瓦片的纹理绑进材质（10-22 晚定的口径：不走拼合器 RT）。
      * 2026-10-26 决定改成**逐帧**：一次把整层地址全丢给下载器（下载/解码在网络与工作线程侧，不占这一帧），
@@ -1454,9 +1343,6 @@ export default class MktMesh extends Mesh<BufferGeometry, ShaderMaterial> {
                 const d = ms.toData();
                 return { ...d, url: d.url ? stripAssetHost(d.url, pn) : "" };
             }),
-            // 玻璃面层（2026-10-28 需求）：只有位置/旋转/边长，⛔ 不过 `stripAssetHost` —— 它不引用任何素材，
-            //   反射源是运行时从 `textures[0].url` 取的（上面那个键自己就落进存档了）。
-            glass: this.glassPanes.map((gp) => gp.toData()),
         };
     }
 
@@ -1519,51 +1405,48 @@ export default class MktMesh extends Mesh<BufferGeometry, ShaderMaterial> {
             (data.models ?? []).map((d) => ({ ...d, url: d.url ? absAssetUrl(d.url, pn) : "" })),
             onModelLoad
         );
-        // 玻璃面层（2026-10-28 需求）：排在 setTextures **之后**是硬要求 —— 它的反射源读的就是刚还原好的
-        //   `textures[0].url`（补过域名的形态），排在前面会用上一次项目的地址起一次错的载。
-        //   旧存档没有这个键 ⇒ 空数组 = 整层清空，与上面两层的口径逐字一致。
-        this.setGlassPanes(data.glass ?? []);
     }
 
     /**
-     * 把**存档里前 `PANO_IMPORT_PRIORITY` 个全景**的素材点名抢在别的之前加载（2026-10-29 需求）。
+     * 把**存档里前 `PANO_IMPORT_PRIORITY` 个全景**按存档顺序登记进拼合器的**加载任务队列**
+     *（2026-10-29 需求「优先加载前 2 个全景素材」+ 2026-10-30 需求逐字：「给 mktmesh 内部加一个加载任务队列，
+     *  把模型和平面图排在最前面，然后按照顺序，依次把前 2 个全景的顺序把瓦片加载任务添加到任务队列里面，
+     *  第一个加载完了，就把这个加载任务从任务队列里面去掉，然后加载第二个；
+     *  如果后续再按照距离计算需要加载哪个全景的时候，同样地添加到加载任务队列的后面等待加载」）。
      * 由两处渲染循环每帧点一次：基类 `onBeforeRender`（预览弹窗 / 发布页）与编辑器的 `updateFloorTexture`
      *（`MktDevMesh` 覆写了 `onBeforeRender`，只点 `syncProjInvMatrix` + `tickProgressiveReveal`，库内那句在编辑态不跑）。
      *
-     * 为什么能「先加载」：拼合器每帧那三道工序（补下载 → 画已进 GPU 的 → 再传一张）都按
-     *   `_groups` 这张 Map 的**在册顺序**取料，而下载额度只有「每帧 2 张 / 在途 ≤8 / 已解码待上传 ≤8」
-     *   （`panoTileStitcher.ts` 顶部那三个常数）⇒ 排在头部的两组把额度吃满，其余全景要等它们画满才轮得到。
-     *   平时这个顺序由每帧的槽位名册定（离注视点近的先下），本方法把它钉成「存档数组的前两个」，与机位无关。
-     * ⚠️⚠️ 为什么点名时要带第三个参 `front = true`（每帧把这两批**挪回队首**）而⛔ 不只是「先入册」：
-     *   在册顺序是拼合器自己的状态 —— 后入册的只会**追加到队尾**，而 `ensure` 幂等、已在册就不再移动。
-     *   预览这条路恰好是最坏的那种排法：`feedFaceMapping` 开头还有一记 `pump`，拼合器**第一次**拿到渲染器时
-     *   必走 `_switchRenderer`（`null → 真 renderer` 也算换，弹窗每开一次就是换一次）把在册组整份作废，
-     *   随后名册按距离重新入册占了队首 ⇒ 本方法下一帧重新入册只能排在它们后面，而且**从此再也翻不了身**。
-     *   2026-10-29 逐帧打点就是这个形状：帧 1 `p0,p1,p11…p4` → 帧 2 起 `p11…p4,p0,p1`，
-     *   40 帧下来 p0 只下到 1 片、p1 下到 30 片，离注视点最近那颗第 13 条请求就开始了 = 线上报的现象。
-     *   ⇒ 带 `front` 之后顺序每帧重新成立，与谁先入册、作废过几次、机位在哪都无关
-     *   （真跑自证在护栏 BE ④：`D` 后入册排队尾，带 `front` 再点一次 ⇒ 立刻回到队首、下一帧下载全归它）。
-     * ⚠️ 为什么是**每帧**而不是「载入那一次点一记」：上面那次作废就发生在载入之后的第一帧，
-     *   只在 `importData` 里点名等于白点；本方法点在 `pump` 之后、名册逐槽 `ensure` 之前，且每帧都点
-     *   （已在册且已在队首 ⇒ `_toFront` 里一次 `keys().next()` 就返回，没有额外开销）。
-     * ⛔ 不另立第二把下载尺：这里用的就是 `feedFaceMapping` 每帧在用的同一个 `ensure(info.tiles, …)`
-     *   与同一个批次键（第一条非空瓦片地址）⇒ 后面那句自然判重，一片瓦片终身只 `fetch` 一次。
+     * 队列怎么排（`panoTileStitcher` 的 `_queue`，一处排队一张尺）：
+     *   ① **模型与平面图天然在最前面** —— 这两族的下载不在拼合器里，`importData` 当场同步发起
+     *      （GLB 逐只 `loadModel` 不 throttle；平面那 4 片一次性 `_imgTileLoader.preload`），
+     *      而全景瓦片最早也要等下一帧的 `pump` 才发第一片 ⇒ 发起次序天然是「模型 → 平面图 → 全景」，
+     *      ⛔ 这里不再把它们塞进队列重复管一遍（塞了就是第二把尺）。
+     *   ② 本方法把存档 0 号、1 号依次 `prioritize` 进队列 ⇒ 拼合器每帧**只喂队首那一组**，
+     *      0 号 32 格全落定（画进 RT，或该格本就缺地址/判死）才出队、1 号才开始发第一片。
+     *      比 10-29 那版（只是把两批挪到在册顺序前面、额度仍被两批分摊）更硬：**第 1 颗独享额度，最快出全图**。
+     *   ③ 名册按距离点到的其他全景走 `feedFaceMapping` 里那句 `ensure(t.tiles)`（不带队列）⇒ 只入册、
+     *      排在队列后面等，队列空了才按在册顺序补料（现行口径不变）。
+     * ⚠️⚠️ 为什么每帧点而⛔ 只在 `importData` 里点一记：预览每开一次都换渲染器，`_switchRenderer` 把在册组
+     *   整份作废（队列里的键也在同一刻失效）；只在载入那次点名等于白点。本方法点在 `pump` 之后、名册逐槽
+     *   `ensure` 之前 ⇒ 每帧把这两记任务补回队列头部（`prioritize` 幂等，已在队列里就不挪，所以 0 号恒在 1 号前）。
+     * ⚠️ 代价如实记：
+     *   · 队列非空时**其他全景一片都不发** ⇒ 开机那几秒里，离注视点最近、但不在存档前两颗的那面墙会多灰一会儿。
+     *   · 一颗「永远下不完」的瓦片（下载失败还没累计到判死）会压住队列；判死阈值是解码失败 3 次
+     *     （`_dead`），退避重试期间队首不落定 ⇒ 第 2 颗跟着延后。真实数据里缺片是「地址为空/404」，
+     *     404 走三次即判死、那一格拼合涂灰 ⇒ 队列照样出清。
+     *   · 这两颗全景若本来不在开机那一刻的名册里，它们的瓦片与拼合槽 RT 会被**提前**建出来
+     *     （现行口径每颗全景 2 槽 × 6144² ≈ 384MB 显存）—— 组在运行中不淘汰，走进这两个景点迟早要建。
      * ⚠️ 形态判据读 `this._panoTexMode`（整图形态那一档一张全景只有一张整图，走 `_texCache` 那条路，
      *   走错档就是白下 32 片）⇒ 宿主若用自己那份形态变量（编辑器的 `store.panoTexMode`），
      *   要在调 `importData` 之前先 `setPanoTexMode` 推进来，编辑器那侧已按此接线。
-     * ⚠️ 代价如实记：这两颗全景若本来不在开机那一刻的名册里，它们的瓦片与拼合槽 RT 会被**提前**建出来
-     *   （现行口径每颗全景 2 槽 × 6144² ≈ 400MB 显存）—— 组在运行中不淘汰，走进那两个景点迟早要建，
-     *   这里只是把这一笔挪到了载入的第一帧。
      */
     prefetchHeadPanoramas(): void {
         const n = Math.min(PANO_IMPORT_PRIORITY, this.textures.length);
-        // ⚠️ **倒着**点：`front` 是「挪到最前」，正着点会让 0 号被 1 号压到后面（实测队首变成 `p1,p0`）
-        //   ⇒ 倒着点，最后一手挪的是 0 号，存档序号小的仍排在更前。
-        for (let i = n - 1; i >= 0; i--) {
+        // 正着点：0 号先入队 ⇒ 队首是它，落定后才轮到 1 号（`prioritize` 对已在队列里的键不挪位置）
+        for (let i = 0; i < n; i++) {
             const info = this.textures[i];
             // 与 `feedFaceMapping` 里那一句同判据：真瓦片才进拼合器，整图形态进瓦片缓存
-            // 第三个参 `true` = 把这批**挪到在册顺序最前**（⛔ 光靠「先入册」押不住顺序，见方法头）
-            if (mktPanoTiledFlag(info.tiles, this._panoTexMode) === 1) this._stitcher.ensure(info.tiles, undefined, true);
+            if (mktPanoTiledFlag(info.tiles, this._panoTexMode) === 1) this._stitcher.prioritize(info.tiles);
             else if (info.url) this.ensureTileTexture(info.url, false);
         }
     }
@@ -1592,16 +1475,6 @@ export default class MktMesh extends Mesh<BufferGeometry, ShaderMaterial> {
             ms.dispose();
         }
         this.models = [];
-        // 玻璃面层：几何/材质各归各颗释放；那张共用的反射纹理在这里连位图一起关
-        //   （⛔ 它从不在 `_texCache` 里 ⇒ 上面那一轮清不到它，漏了这一句就是每次换页漏一张全景整图）。
-        for (const gp of this.glassPanes) {
-            this.remove(gp);
-            gp.dispose();
-        }
-        this.glassPanes = [];
-        releasePanoTexture(this._glassEnvTex);
-        this._glassEnvTex = null;
-        this._glassEnvKey = "";
         this._imgTileLoader.clear();
         this._imgBindQueued.clear();
         this._imgBindDone.clear();