three-base 2.0.188 → 2.0.192

package/MktMesh/modelSlot.js

@@ -107,6 +107,12 @@ export class ModelSlot extends Group {
     _staged = null;
     /** 载入令牌：换地址/删除后迟到的回调靠它作废（否则旧模型会挂进新槽） */
     _loadToken = 0;
+    /**
+     * 内容是否已落定：真模型挂进了 `_contentRoot`，或这一颗压根没在等什么（空地址 / 取回失败 ⇒ 停在占位小立方体）。
+     * ⚠️ 落定**不等于**已经画进 GPU —— 顶点缓冲与首次 program 编译发生在「亮出来的那一帧」，
+     *   所以逐帧限流必须闸在点亮这一下（`MktMesh.tickProgressiveReveal`），闸在挂载那一下拦不住 GPU 侧的账。
+     */
+    _loaded = false;
     _disposed = false;
     constructor(name) {
         super();
@@ -126,6 +132,8 @@ export class ModelSlot extends Group {
     get naturalSize() { return this._naturalSize; }
     /** 是否已经挂上真模型（false = 仍是占位小立方体） */
     get hasModel() { return this._model !== null; }
+    /** 这一颗的内容落定没有 —— 库的逐帧点亮闸只认这一条（`MktMesh.tickProgressiveReveal`）。 */
+    get loaded() { return this._loaded; }
     /** 改尺寸档（米，最长边）：立刻重缩内容 */
     setSize(size) {
         this._size = size > 0 ? size : this._size;
@@ -161,13 +169,25 @@ export class ModelSlot extends Group {
     async loadModel(url) {
         this._url = url;
         const token = ++this._loadToken;
+        this._loaded = false;
         this._detachModel();
         // 先立刻退回占位小立方体：GLB 在路上那段窗口（慢网/大模型）⛔ 不许让这一槽凭空消失
         //   （取回失败那条支路本来也是停在占位上，两段时间里画面一致）
         this._layout();
-        if (!url)
+        if (!url) {
+            // 空地址 = 这一颗压根没在等什么 ⇒ 当场落定（占位小立方体就是它的最终内容）
+            this._loaded = true;
             return true;
-        const obj = await threeLoader.loadModel(url);
+        }
+        // 取回失败（404 / 解析报错都从这一档走）：`threeLoader.loadModel` 是会 reject 的，⚠️ 必须当「落定在占位方块」处理
+        //   —— 整层重建时这一颗是压着不亮的，不落定就永远隐形（旧写法里它至少还露得出占位方块）。
+        let obj;
+        try {
+            obj = await threeLoader.loadModel(url);
+        }
+        catch {
+            obj = undefined;
+        }
         // 迟到回调：这一槽已经改指向别的地址、或已经删除 ⇒ 当场释放，别留一份没人认领的显存
         if (this._disposed || token !== this._loadToken) {
             if (obj)
@@ -175,6 +195,7 @@ export class ModelSlot extends Group {
             return false;
         }
         if (!obj) {
+            this._loaded = true;
             this._layout();
             return false;
         }
@@ -189,6 +210,7 @@ export class ModelSlot extends Group {
         this._staged = null;
         this._model = obj;
         this._contentRoot.add(obj);
+        this._loaded = true;
         this._layout();
         return true;
     }
@@ -220,6 +242,8 @@ export class ModelSlot extends Group {
         this._size = d.size > 0 ? d.size : MODEL_SLOT_DEFAULT_SIZE;
         this._naturalSize = d.naturalSize;
         this._url = d.url || "";
+        // 落定判据跟着地址走：空地址 = 没在等什么（占位方块就是最终内容）；有地址 = 等 GLB 那一拍
+        this._loaded = !this._url;
         if (!this._url)
             this._detachModel();
         this._layout();

package/MktMesh/modelSlot.ts

@@ -137,6 +137,12 @@ export class ModelSlot extends Group {
     private _staged: Object3D | null = null;
     /** 载入令牌：换地址/删除后迟到的回调靠它作废（否则旧模型会挂进新槽） */
     private _loadToken = 0;
+    /**
+     * 内容是否已落定：真模型挂进了 `_contentRoot`，或这一颗压根没在等什么（空地址 / 取回失败 ⇒ 停在占位小立方体）。
+     * ⚠️ 落定**不等于**已经画进 GPU —— 顶点缓冲与首次 program 编译发生在「亮出来的那一帧」，
+     *   所以逐帧限流必须闸在点亮这一下（`MktMesh.tickProgressiveReveal`），闸在挂载那一下拦不住 GPU 侧的账。
+     */
+    private _loaded = false;
     private _disposed = false;
 
     constructor(name?: string) {
@@ -164,6 +170,8 @@ export class ModelSlot extends Group {
     get naturalSize(): { x: number; y: number; z: number } | undefined { return this._naturalSize; }
     /** 是否已经挂上真模型（false = 仍是占位小立方体） */
     get hasModel(): boolean { return this._model !== null; }
+    /** 这一颗的内容落定没有 —— 库的逐帧点亮闸只认这一条（`MktMesh.tickProgressiveReveal`）。 */
+    get loaded(): boolean { return this._loaded; }
 
     /** 改尺寸档（米，最长边）：立刻重缩内容 */
     setSize(size: number): void {
@@ -201,18 +209,31 @@ export class ModelSlot extends Group {
     async loadModel(url: string): Promise<boolean> {
         this._url = url;
         const token = ++this._loadToken;
+        this._loaded = false;
         this._detachModel();
         // 先立刻退回占位小立方体：GLB 在路上那段窗口（慢网/大模型）⛔ 不许让这一槽凭空消失
         //   （取回失败那条支路本来也是停在占位上，两段时间里画面一致）
         this._layout();
-        if (!url) return true;
-        const obj = await threeLoader.loadModel(url);
+        if (!url) {
+            // 空地址 = 这一颗压根没在等什么 ⇒ 当场落定（占位小立方体就是它的最终内容）
+            this._loaded = true;
+            return true;
+        }
+        // 取回失败（404 / 解析报错都从这一档走）：`threeLoader.loadModel` 是会 reject 的，⚠️ 必须当「落定在占位方块」处理
+        //   —— 整层重建时这一颗是压着不亮的，不落定就永远隐形（旧写法里它至少还露得出占位方块）。
+        let obj: Object3D | undefined;
+        try {
+            obj = await threeLoader.loadModel(url);
+        } catch {
+            obj = undefined;
+        }
         // 迟到回调：这一槽已经改指向别的地址、或已经删除 ⇒ 当场释放，别留一份没人认领的显存
         if (this._disposed || token !== this._loadToken) {
             if (obj) disposeSubtree(obj);
             return false;
         }
         if (!obj) {
+            this._loaded = true;
             this._layout();
             return false;
         }
@@ -227,6 +248,7 @@ export class ModelSlot extends Group {
         this._staged = null;
         this._model = obj;
         this._contentRoot.add(obj);
+        this._loaded = true;
         this._layout();
         return true;
     }
@@ -257,6 +279,8 @@ export class ModelSlot extends Group {
         this._size = d.size > 0 ? d.size : MODEL_SLOT_DEFAULT_SIZE;
         this._naturalSize = d.naturalSize;
         this._url = d.url || "";
+        // 落定判据跟着地址走：空地址 = 没在等什么（占位方块就是最终内容）；有地址 = 等 GLB 那一拍
+        this._loaded = !this._url;
         if (!this._url) this._detachModel();
         this._layout();
     }

package/MktMesh/panoTileStitcher.d.ts

@@ -6,7 +6,7 @@ import { type TileLayout } from "./mktShader";
  */
 export interface PanoStitcher {
     /** 确保批次已在册并发起瓦片加载（幂等；同批已在册 ⇒ 什么都不做）。
-     *  新增可选 `layout` 参数：缺省 = PANO_TILE_LAYOUT（全景 6×3 / 2 槽 / 6144×6144，10-26 需求）；
+     *  新增可选 `layout` 参数：缺省 = PANO_TILE_LAYOUT（全景 8×4 / 2 槽 / 6144×6144，2026-10-27 需求）；
      *  图片平面传 `imageTileLayout(natW, natH)`（2×2 / 1 槽 / RT 宽高比=原图）。 */
     ensure(urls: string[], layout?: TileLayout): void;
     /**
@@ -59,7 +59,7 @@ export declare class PanoTileStitcher implements PanoStitcher {
     private _camera;
     private _mat;
     /** 几何是 2×2（铺满正交相机的 [-1,1]²），每格按 `1/slotCellCols × 1/slotCellRows` 缩放再挪过去
-     *  ⇒ 全景一格 = 槽的 1/3（横 1 竖 3，10-23 旨），图片平面一格 = 1/4（横 2 竖 2） */
+     *  ⇒ 全景一格 = 槽的 1/4 宽 × 1/4 高（横 4 竖 4，2026-10-27 口径），图片平面一格 = 1/4（横 2 竖 2） */
     private _quad;
     /** 缺格那一路 `uMap` 也要有个合法纹理可绑（1×1，从不真采样） */
     private _blank;
@@ -67,10 +67,12 @@ export declare class PanoTileStitcher implements PanoStitcher {
     private _rtTextures;
     constructor();
     /** 确保批次已建组、加载已发起。幂等：同批已在册 ⇒ 直接返回（一片瓦片终身只下载、只解码一次）。
-     *  ⭐ 09-29「不足的涂灰」+ 10-26「6×3 = 18 片」：1~18 条皆可入组，内部补空串占位到 18；
+     *  ⭐ 09-29「不足的涂灰」+ 2026-10-27「8×4 = 32 片」：1~32 条皆可入组，内部补空串占位到 32；
      *  空串 / 死链的格子拼合时涂灰（一眼看出该全景数据不全）。
-     *  ⛔ 旧版 16 条（4×4）、32 条（8×4）、64 条（8×8）与 9 条（3×3）的数据**都不做兼容**（用户「无须兼容正常使用, 有异常我会重传」）：
-     *  超 18 条会在上一行被判超限直接丢弃；真喂进来的短数据只占前几格 + 其余涂灰，那是**故意**让数据不全看得见。
+     *  ⛔ 旧版 18 条（6×3）、16 条（4×4）、64 条（8×8）与 9 条（3×3）的数据**都不做兼容**（用户「无须兼容正常使用, 有异常我会重传」）：
+     *  超 32 条会在上一行被判超限直接丢弃；真喂进来的短数据只占前几格 + 其余涂灰，那是**故意**让数据不全看得见。
+     *  ⚠️ 唯一按张数**能混进来**的是 10-06 那版同为 32 片的老档（切片顺序与槽分组两版一致 ⇒ 不会错位），
+     *  但它的瓦片是 1024²、被画进 1536² 的格子 = 1.5× 放大 ⇒ 发虚，那类老点仍要重传一次。
      *  ⚠️ 每槽数组长度由 `RT_STITCH_SLOT_COUNT` 派生（⛔ 不许手写 `[null,null]` —— 槽数再变会漏改）。 */
     ensure(urls: string[], layout?: TileLayout): void;
     /** 取某一拼合槽的纹理：**画过 ≥1 格就交出去**（同日旨「需要先喂给 shader」⇒ 不再等 `cellsPerSlot` 格画满）。
@@ -121,7 +123,7 @@ export declare class PanoTileStitcher implements PanoStitcher {
      *   （与 `MktMesh._uploadTileTexture` 的「排上队之后已被清掉 ⇒ 本项作废」同一口径。） */
     private _uploadTile;
     /** 画一格：把那片瓦片的**中间那块**铺进该槽第 `cell` 格（每槽 `slotCellCols × slotCellRows` 格里的一格，
-     *  10-26 起全景是「横 3 × 竖 3」= 9 格、图片平面是 2×2 = 4 格）。
+     *  2026-10-27 起全景是「横 4 × 竖 4」= 16 格、图片平面是 2×2 = 4 格）。
      *  ⚠️⚠️ `autoClear` 必须关掉：three 每次 `render()` 默认清屏，而这里**同一张 RT 要连画 cellsPerSlot 帧**，
      *     清一次就把前面画好的格子抹了 ⇒ 槽纹理只剩最后一格。清屏交给我们自己（见 `_clearRt`）。 */
     private _stitchCell;

package/MktMesh/panoTileStitcher.js

@@ -1,5 +1,5 @@
 /*
- * @Description: 18 瓦片全景的「离屏拼合器」= **shader 逐格画进 WebGLRenderTarget**（本项目唯一一份拼合实现）。
+ * @Description: 32 瓦片全景的「离屏拼合器」= **shader 逐格画进 WebGLRenderTarget**（本项目唯一一份拼合实现）。
  *
  * 三道旨意叠成现在这一份：
  *   ① 2026-09-29：一张全景切多片（每片所有 GPU 都装得下），运行时离屏拼回若干张固定尺寸的「槽纹理」，
@@ -28,9 +28,16 @@
  *      ⇒ 改 **6×3=18 片 / 左右 2 槽**，每槽 = 原图半幅（横 3 格 × 竖 3 格）= **6144×6144**、与原图 1:1。
  *      ⭐ 净效果：单全景有效分辨率与显存**一字未动**（仍是 75.5Mpx / ≈384MB），sampler = 点数 × 2 ⇒
  *         **同屏全景点数 5 → 8**（8×2=16 正好用满硬顶）。旧存档 9 条地址**不兼容**，用户重传即可。
+ *   ⑥ 2026-10-27（需求，逐字）：「目前全景的 2个RT 是 3*3=9张的对吧, 我想要改成之前的 4*4=16张的逻辑, 数据你不用管,
+ *      我会重新上传, 你把代码改正确就行」
+ *      ⇒ 改 **8×4=32 片 / 左右 2 槽**，每槽 = 原图半幅（横 4 格 × 竖 4 格 = 16 格）= **6144×6144**、与原图 1:1。
+ *      ⭐ 净效果：单全景有效分辨率与显存**一字未动**（有效分辨率仍是 **12288×6144**、与 ⑤ 那版 18 片**逐像素同量**；
+ *         显存仍 ≈384MB 含 mipmap），sampler 账不变（每点 2 张 × 同屏 8 点 = 16 = 本机硬顶）⇒ 变的只有「切几刀」：
+ *         每格像素 2048×2048 → **1536×1536**、一组待画格 18 → **32**。
+ *      ⚠️ 旧存档 18 / 9 / 64 / 16 条地址**不兼容**（张数不符被判废）⇒ 用户「数据你不用管，我会重新上传」。
  *
  * ⚠️ **仍然有 canvas，但只在上传切图那一步**（`src/views/MktMeshEdit/panoramaUpload.ts` 用 2D 画布把原图
- *    切成 18 个 JPEG 传 OSS）—— 那是**离线、一次性、产出的是数据**；运行时这条路上一个 canvas 都没有。
+ *    切成 32 个 JPEG 传 OSS）—— 那是**离线、一次性、产出的是数据**；运行时这条路上一个 canvas 都没有。
  *
  * ── 每帧的三道工序（旨②那两句话逐条落地，顺序固定）────────────────────────────────
  *   1. `_pumpDownloads()`：补发缺图的下载（每帧 ≤2 张、在册 ≤8、已解码待上传 ≤8）⇒ ⛔ 一批几十条 XHR 一起炸。
@@ -40,49 +47,51 @@
  *      到 GPU 里面去」）。这一趟**只上传、不画** ⇒ 上传与绘制永不落在同一拍（09-29 那句「两个大头别在同一
  *      帧」的延续），而且第 2 步天然只能画「上一帧及更早」传上去的图 ⇒ 每帧 = 1 上传 + 1 绘制（稳态）。
  *
- * ⚠️ 于是「一帧一片」的帧数随网格走：16 片 → 32 片 → 9 片 → **18 片/组 = 18 帧**（30ms/帧 ⇒ 约 0.55s，
- *    10-26 需求）。每格像素 = `RT_STITCH_SLOT_W/3 × RT_STITCH_SLOT_H/3` = **2048×2048**（原图切出来那片多大就多大，一比一）。
- *    且因为下面那条「先喂 shader」的旨意，第一格画完墙上就有东西了，不必等 18 帧。
+ * ⚠️ 于是「一帧一片」的帧数随网格走：16 片 → 32 片 → 9 片 → 18 片 → **32 片/组 = 32 帧**（30ms/帧 ⇒ 约 1.0s，
+ *    2026-10-27 需求）。每格像素 = `RT_STITCH_SLOT_W/4 × RT_STITCH_SLOT_H/4` = **1536×1536**（原图切出来那片多大就多大，一比一）。
+ *    且因为下面那条「先喂 shader」的旨意，第一格画完墙上就有东西了，不必等 32 帧。
  *
  * ⭐ 部分就绪就先喂（同日旨「1. 需要先喂给 shader」）：`peek()` 不再等一个槽的 `cellsPerSlot` 格画满，
  *   **画过 ≥1 格就交出去**。为了保证交出去的那张 RT 里绝无未定义像素，RT 建好后的第一件事是
  *   整张涂成缺失灰（`_clearRt`）⇒ 观感 = 该象限从左上角起逐格显影，缺数据的格子一直是灰的。
  *
  * ── 画质四条（⛔ 改任何一条都是改画质，先请旨）──────────────────────────────
- *  1. **尺寸 / 格子几何**：槽 `RT_STITCH_SLOT_W/H` = **6144×6144**、每槽「横 3 格 × 竖 3 格」、原图**横 6 × 竖 3** 片，
+ *  1. **尺寸 / 格子几何**：槽 `RT_STITCH_SLOT_W/H` = **6144×6144**、每槽「横 4 格 × 竖 4 格」、原图**横 8 × 竖 4** 片，
  *     全在 `./mktShader`（单一来源）。⭐ 10-23 旨后格子尺寸 = 那片瓦片的尺寸 ⇒ **一比一**：11968×5984 那类原图
- *     切 6×3 得 ~1995×1995 的片，铺进 2048×2048 的格子几乎不缩（缩放比 1.03，与上一版同一档）
- *     ⇒ 单全景有效分辨率 33.5Mpx → **75.5Mpx**，是**升**画质，与「千万不要降低质量」红线同向。
+ *     切 8×4 得 ~1496×1496 的片，铺进 1536×1536 的格子几乎不缩（缩放比 1.03，与上一版同一档）
+ *     ⇒ 单全景有效分辨率 33.5Mpx → **75.5Mpx**（= 12288×6144，本次与上一版**逐像素同量**），是**升**画质那一档定下的，
+ *     与「千万不要降低质量」红线同向。
  *     ⛔ 不许拿槽尺寸当省显存的旋钮：现口径每槽覆盖**横 180° × 竖 180°**（原图左/右半幅），
- *     宽高比 1:1 与「半幅（3 列 × 3 行）」一致；上一版一槽装一整列时是 2:3，两版各自都对，⛔ 别混着抄。
+ *     宽高比 1:1 与「半幅（4 列 × 4 行）」一致；更早按列分槽那一版一槽装一整列时是 2:3，两版各自都对，⛔ 别混着抄。
  *  2. **色彩**：瓦片纹理 `colorSpace = SRGBColorSpace` ⇒ WebGL2 内部格式 `SRGB8_ALPHA8`，采样时硬件解码成
  *     linear；RT 纹理同样标 sRGB ⇒ 写入时硬件再编码回 sRGB。一进一出**逐字节还原**。
  *     ⚠️ 另一半证据在 three 里：写进非 XR 的 render target 时片元末尾的 `linearToOutputTexel` 恒按
  *     LinearSRGB（= 不转换），编码完全交给硬件 ⇒ ⛔ 我们的片元绝不 `#include <colorspace_fragment>`，
  *     也不带 tone mapping 的 chunk（那两处都会再转一遍 ⇒ 画面发白）。
  *  3. **摩尔纹**：两层都开 mipmap ——
- *     ① 瓦片纹理 `generateMipmaps` + `LinearMipmapLinearFilter`：一片原图（~1995×1995）铺进 2048×2048
+ *     ① 瓦片纹理 `generateMipmaps` + `LinearMipmapLinearFilter`：一片原图（~1496×1496）铺进 1536×1536
  *        的格子是**一比一**，但墙面在远处仍会缩到格子以下 ⇒ ⛔ 单点双线性会采出锯齿，mipmap 照旧开
  *        （WebGL2 对 NPOT 也能生成 mipmap，three r163 起只支持 WebGL2）。
  *     ② 槽 RT 标 `generateMipmaps`：three 每次渲染进 RT 后自己 `glGenerateMipmap`（`WebGLRenderer.js`
  *        `updateRenderTargetMipmap`）⇒ 与当年 CanvasTexture 上传后生成 mipmap 同一口径。
  *        ⚠️ 代价：每格一次（旧版每格也是一次），都在 GPU 上、不占主线程。
- *  4. **接缝**：槽内「横 3 × 竖 3」⇒ 一张槽内部的格子线是 **2 横 2 竖**（上一版一槽一整列时只有 2 横 0 竖）；
- *     槽与槽之间另有 u=1/2 **一道**跨纹理竖缝，那道治不了（见 `PanoTexMode` 说明②；上一版是两道）。治法 = 上传时每片向四边**多切**
+ *  4. **接缝**：槽内「横 4 × 竖 4」⇒ 一张槽内部的格子线是 **3 横 3 竖**（上一版 3×3 是 2 横 2 竖；更早一槽一整列时只有 2 横 0 竖）；
+ *     槽与槽之间另有 u=1/2 **一道**跨纹理竖缝，那道治不了（见 `PanoTexMode` 说明②；更早按列 3 槽那版才是两道）。治法 = 上传时每片向四边**多切**
  *     `RT_STITCH_SEAM_MARGIN_PX` 像素、拼合时**只采中间那块**（`uSrcRect`）⇒ 边界插值拿得到真邻居像素，
  *     不再复制自己的边缘。⛔ 这条不许「顺手简化」成直接铺满格子：几何会挤歪，缝也还在。
  *     详见 `./mktShader` 里那三个 `rtStitch*` 纯函数 —— **上传侧与拼合侧必须共用同一份几何**。
  *
- * 资源账（⚠️ 如实记；10-26 需求改 6×3=18 片 / 左右 2 槽 / 6144×6144 后重算）：
+ * 资源账（⚠️ 如实记；2026-10-27 需求改 8×4=32 片 / 左右 2 槽 / 6144×6144 后重算 —— 槽尺寸一字未动 ⇒ 显存那一栏不变）：
  *   - 常驻显存：2 槽 × (6144×**6144**×4B + mipmap≈33%) ≈ **384MB/全景**（不含 mipmap 288MB —— 与上一版**一字不差**）
  *     —— 更早那版 8×4=32 片 / 2 槽 4096² 只有 **170MB/全景** ⇒ 单全景 **2.26 倍**，代价来自「槽与原图一比一」那次**升分辨率**，
  *     不是浪费：33.5Mpx → 75.5Mpx 的有效像素全在 RT 里。
- *     ⚠️ 组**运行中不淘汰**（见文末那条需求）⇒ 13 张全景全常驻 ≈ **4.9GB**（上一版 2.2GB）。同屏景点数虽回到 8，
+ *     ⚠️ 组**运行中不淘汰**（见文末那条需求）⇒ 13 张全景全常驻 ≈ **4.9GB**（上一版同数 —— 单全景显存一字未动）。同屏景点数 8，
  *     那只省 sampler 绑定、**不省显存**。⚠️ 这是这一轮最大的风险项，已另记待用户裁决（见「RT 不回收」）。
- *   - 上传总量：同一张原图切完 ⇒ **总像素与上一版逐字节同量**，片数 9 → 18、每片 4096×2048 → 2048×2048（单片像素减半）
- *     ⇒ 下载发起数比 9 片那版**翻倍**（仍比 32 片那版少 14 条）、单请求变小。
+ *   - 上传总量：同一张原图切完 ⇒ **总像素与上一版逐字节同量**，片数 18 → 32、每片 2048×2048 → 1536×1536（单片像素减到 ≈0.56 倍）
+ *     ⇒ 下载发起数比 18 片那版**多 14 条**（与 10-06 那版 32 片同数）、单请求更小。
  *   - 瓦片纹理画完即弃 ⇒ 同时在册的只有「下载中 + 已解码待上传」那些，上限 8+8 片；
- *     ⚠️ 每片解码位图 2048×2048×4B = **16MB**（上一版每片 4096×2048 = 32MB）⇒ 峰值 CPU 侧 ≈ **256MB**（原 512MB）。
+ *     ⚠️ 每片解码位图 1536×1536×4B = **9MB**（上一版每片 2048×2048 = 16MB）⇒ 闸内在制品峰值 CPU 侧 ≈ **144MB**（原 256MB）；
+ *     一组 32 片若全解码则是 ≈**288MB**（上一版 18 片 × 16MB = 288MB —— **同一量**）。
  *
  * ⚠️ RT 是 GL 上下文私有资源：`pump(renderer)` 换 renderer 时整组作废（`_switchRenderer`），下一帧消费方
  *   照旧的 `ensure()` 重建（瓦片走浏览器 HTTP 缓存重新下载）。现况是**每个持有者一份拼合器 + 一个 renderer**
@@ -103,11 +112,11 @@ import { MISSING_TILE_GRAY, rtStitchBatchOf, rtStitchCellPos, rtStitchTileInset,
  *   ⛔ 别再拿它去写 budget 循环：那正是「一帧上传 2 张」的根因（消费方 onBeforeRender 里 pump 了两次）。
  */
 const PANO_STITCH_UPLOADS_PER_FRAME = 1;
-/** 每帧最多发起几张下载（现行一批 18 片，⛔ 不加以限制就是一帧甩 18 条 XHR + 18 次 400 万像素解码） */
+/** 每帧最多发起几张下载（现行一批 32 片，⛔ 不加以限制就是一帧甩 32 条 XHR + 32 次 ≈236 万像素解码） */
 const PANO_STITCH_DOWNLOADS_PER_FRAME = 2;
 /** 「下载中」的片数上限（跨所有批次） */
 const PANO_STITCH_MAX_INFLIGHT = 8;
-/** 「已解码、还没上传进 GPU」的片数上限 ⇒ 也是 CPU 侧位图的峰值内存闸（≈8 × 4.6MB） */
+/** 「已解码、还没上传进 GPU」的片数上限 ⇒ 也是 CPU 侧位图的峰值内存闸（≈8 × 9MB，每片 1536×1536×4B） */
 const PANO_STITCH_MAX_DECODED_AHEAD = 8;
 /** 瓦片纹理的实际像素宽高（`loadPanoTexture` 交回来的是 `ImageBitmap`，尺寸就是切片区）。
  *  内缩比例按**实际尺寸**算 ⇒ 编码差 1px 也不会露出邻居格子的像素。拿不到尺寸时退回下面那个兜底边长。 */
@@ -192,7 +201,7 @@ export class PanoTileStitcher {
         blending: NoBlending,
     });
     /** 几何是 2×2（铺满正交相机的 [-1,1]²），每格按 `1/slotCellCols × 1/slotCellRows` 缩放再挪过去
-     *  ⇒ 全景一格 = 槽的 1/3（横 1 竖 3，10-23 旨），图片平面一格 = 1/4（横 2 竖 2） */
+     *  ⇒ 全景一格 = 槽的 1/4 宽 × 1/4 高（横 4 竖 4，2026-10-27 口径），图片平面一格 = 1/4（横 2 竖 2） */
     _quad = new Mesh(new PlaneGeometry(2, 2), this._mat);
     /** 缺格那一路 `uMap` 也要有个合法纹理可绑（1×1，从不真采样） */
     _blank = new DataTexture(new Uint8Array([0, 0, 0, 255]), 1, 1);
@@ -204,10 +213,12 @@ export class PanoTileStitcher {
         this._blank.needsUpdate = true;
     }
     /** 确保批次已建组、加载已发起。幂等：同批已在册 ⇒ 直接返回（一片瓦片终身只下载、只解码一次）。
-     *  ⭐ 09-29「不足的涂灰」+ 10-26「6×3 = 18 片」：1~18 条皆可入组，内部补空串占位到 18；
+     *  ⭐ 09-29「不足的涂灰」+ 2026-10-27「8×4 = 32 片」：1~32 条皆可入组，内部补空串占位到 32；
      *  空串 / 死链的格子拼合时涂灰（一眼看出该全景数据不全）。
-     *  ⛔ 旧版 16 条（4×4）、32 条（8×4）、64 条（8×8）与 9 条（3×3）的数据**都不做兼容**（用户「无须兼容正常使用, 有异常我会重传」）：
-     *  超 18 条会在上一行被判超限直接丢弃；真喂进来的短数据只占前几格 + 其余涂灰，那是**故意**让数据不全看得见。
+     *  ⛔ 旧版 18 条（6×3）、16 条（4×4）、64 条（8×8）与 9 条（3×3）的数据**都不做兼容**（用户「无须兼容正常使用, 有异常我会重传」）：
+     *  超 32 条会在上一行被判超限直接丢弃；真喂进来的短数据只占前几格 + 其余涂灰，那是**故意**让数据不全看得见。
+     *  ⚠️ 唯一按张数**能混进来**的是 10-06 那版同为 32 片的老档（切片顺序与槽分组两版一致 ⇒ 不会错位），
+     *  但它的瓦片是 1024²、被画进 1536² 的格子 = 1.5× 放大 ⇒ 发虚，那类老点仍要重传一次。
      *  ⚠️ 每槽数组长度由 `RT_STITCH_SLOT_COUNT` 派生（⛔ 不许手写 `[null,null]` —— 槽数再变会漏改）。 */
     ensure(urls, layout) {
         const L = layout ?? PANO_TILE_LAYOUT;
@@ -442,14 +453,14 @@ export class PanoTileStitcher {
     }
     // ───────────────────────── 内部：单格绘制 ─────────────────────────
     /** 画一格：把那片瓦片的**中间那块**铺进该槽第 `cell` 格（每槽 `slotCellCols × slotCellRows` 格里的一格，
-     *  10-26 起全景是「横 3 × 竖 3」= 9 格、图片平面是 2×2 = 4 格）。
+     *  2026-10-27 起全景是「横 4 × 竖 4」= 16 格、图片平面是 2×2 = 4 格）。
      *  ⚠️⚠️ `autoClear` 必须关掉：three 每次 `render()` 默认清屏，而这里**同一张 RT 要连画 cellsPerSlot 帧**，
      *     清一次就把前面画好的格子抹了 ⇒ 槽纹理只剩最后一格。清屏交给我们自己（见 `_clearRt`）。 */
     _stitchCell(renderer, g, slot, cell, tex) {
         const rt = this._ensureRt(renderer, g, slot);
         const tileIdx = g.slotTiles[slot][cell];
         const [cc, rr] = rtStitchCellPos(cell, g.layout.slotCellCols);
-        // ⚠️ 横竖**分轴**缩放/摆位（旧的单一 `slotGrid` 方形假设整条作废）：10-26 起全景一槽 = 原图半幅 ⇒ 3 横 3 竖，图片平面那档 2 横 2 竖
+        // ⚠️ 横竖**分轴**缩放/摆位（旧的单一 `slotGrid` 方形假设整条作废）：现行全景一槽 = 原图半幅 ⇒ 4 横 4 竖，图片平面那档 2 横 2 竖
         const cw = g.layout.slotCellCols;
         const ch = g.layout.slotCellRows;
         this._quad.scale.set(1 / cw, 1 / ch, 1);

package/MktMesh/panoTileStitcher.ts

@@ -1,5 +1,5 @@
 /*
- * @Description: 18 瓦片全景的「离屏拼合器」= **shader 逐格画进 WebGLRenderTarget**（本项目唯一一份拼合实现）。
+ * @Description: 32 瓦片全景的「离屏拼合器」= **shader 逐格画进 WebGLRenderTarget**（本项目唯一一份拼合实现）。
  *
  * 三道旨意叠成现在这一份：
  *   ① 2026-09-29：一张全景切多片（每片所有 GPU 都装得下），运行时离屏拼回若干张固定尺寸的「槽纹理」，
@@ -28,9 +28,16 @@
  *      ⇒ 改 **6×3=18 片 / 左右 2 槽**，每槽 = 原图半幅（横 3 格 × 竖 3 格）= **6144×6144**、与原图 1:1。
  *      ⭐ 净效果：单全景有效分辨率与显存**一字未动**（仍是 75.5Mpx / ≈384MB），sampler = 点数 × 2 ⇒
  *         **同屏全景点数 5 → 8**（8×2=16 正好用满硬顶）。旧存档 9 条地址**不兼容**，用户重传即可。
+ *   ⑥ 2026-10-27（需求，逐字）：「目前全景的 2个RT 是 3*3=9张的对吧, 我想要改成之前的 4*4=16张的逻辑, 数据你不用管,
+ *      我会重新上传, 你把代码改正确就行」
+ *      ⇒ 改 **8×4=32 片 / 左右 2 槽**，每槽 = 原图半幅（横 4 格 × 竖 4 格 = 16 格）= **6144×6144**、与原图 1:1。
+ *      ⭐ 净效果：单全景有效分辨率与显存**一字未动**（有效分辨率仍是 **12288×6144**、与 ⑤ 那版 18 片**逐像素同量**；
+ *         显存仍 ≈384MB 含 mipmap），sampler 账不变（每点 2 张 × 同屏 8 点 = 16 = 本机硬顶）⇒ 变的只有「切几刀」：
+ *         每格像素 2048×2048 → **1536×1536**、一组待画格 18 → **32**。
+ *      ⚠️ 旧存档 18 / 9 / 64 / 16 条地址**不兼容**（张数不符被判废）⇒ 用户「数据你不用管，我会重新上传」。
  *
  * ⚠️ **仍然有 canvas，但只在上传切图那一步**（`src/views/MktMeshEdit/panoramaUpload.ts` 用 2D 画布把原图
- *    切成 18 个 JPEG 传 OSS）—— 那是**离线、一次性、产出的是数据**；运行时这条路上一个 canvas 都没有。
+ *    切成 32 个 JPEG 传 OSS）—— 那是**离线、一次性、产出的是数据**；运行时这条路上一个 canvas 都没有。
  *
  * ── 每帧的三道工序（旨②那两句话逐条落地，顺序固定）────────────────────────────────
  *   1. `_pumpDownloads()`：补发缺图的下载（每帧 ≤2 张、在册 ≤8、已解码待上传 ≤8）⇒ ⛔ 一批几十条 XHR 一起炸。
@@ -40,49 +47,51 @@
  *      到 GPU 里面去」）。这一趟**只上传、不画** ⇒ 上传与绘制永不落在同一拍（09-29 那句「两个大头别在同一
  *      帧」的延续），而且第 2 步天然只能画「上一帧及更早」传上去的图 ⇒ 每帧 = 1 上传 + 1 绘制（稳态）。
  *
- * ⚠️ 于是「一帧一片」的帧数随网格走：16 片 → 32 片 → 9 片 → **18 片/组 = 18 帧**（30ms/帧 ⇒ 约 0.55s，
- *    10-26 需求）。每格像素 = `RT_STITCH_SLOT_W/3 × RT_STITCH_SLOT_H/3` = **2048×2048**（原图切出来那片多大就多大，一比一）。
- *    且因为下面那条「先喂 shader」的旨意，第一格画完墙上就有东西了，不必等 18 帧。
+ * ⚠️ 于是「一帧一片」的帧数随网格走：16 片 → 32 片 → 9 片 → 18 片 → **32 片/组 = 32 帧**（30ms/帧 ⇒ 约 1.0s，
+ *    2026-10-27 需求）。每格像素 = `RT_STITCH_SLOT_W/4 × RT_STITCH_SLOT_H/4` = **1536×1536**（原图切出来那片多大就多大，一比一）。
+ *    且因为下面那条「先喂 shader」的旨意，第一格画完墙上就有东西了，不必等 32 帧。
  *
  * ⭐ 部分就绪就先喂（同日旨「1. 需要先喂给 shader」）：`peek()` 不再等一个槽的 `cellsPerSlot` 格画满，
  *   **画过 ≥1 格就交出去**。为了保证交出去的那张 RT 里绝无未定义像素，RT 建好后的第一件事是
  *   整张涂成缺失灰（`_clearRt`）⇒ 观感 = 该象限从左上角起逐格显影，缺数据的格子一直是灰的。
  *
  * ── 画质四条（⛔ 改任何一条都是改画质，先请旨）──────────────────────────────
- *  1. **尺寸 / 格子几何**：槽 `RT_STITCH_SLOT_W/H` = **6144×6144**、每槽「横 3 格 × 竖 3 格」、原图**横 6 × 竖 3** 片，
+ *  1. **尺寸 / 格子几何**：槽 `RT_STITCH_SLOT_W/H` = **6144×6144**、每槽「横 4 格 × 竖 4 格」、原图**横 8 × 竖 4** 片，
  *     全在 `./mktShader`（单一来源）。⭐ 10-23 旨后格子尺寸 = 那片瓦片的尺寸 ⇒ **一比一**：11968×5984 那类原图
- *     切 6×3 得 ~1995×1995 的片，铺进 2048×2048 的格子几乎不缩（缩放比 1.03，与上一版同一档）
- *     ⇒ 单全景有效分辨率 33.5Mpx → **75.5Mpx**，是**升**画质，与「千万不要降低质量」红线同向。
+ *     切 8×4 得 ~1496×1496 的片，铺进 1536×1536 的格子几乎不缩（缩放比 1.03，与上一版同一档）
+ *     ⇒ 单全景有效分辨率 33.5Mpx → **75.5Mpx**（= 12288×6144，本次与上一版**逐像素同量**），是**升**画质那一档定下的，
+ *     与「千万不要降低质量」红线同向。
  *     ⛔ 不许拿槽尺寸当省显存的旋钮：现口径每槽覆盖**横 180° × 竖 180°**（原图左/右半幅），
- *     宽高比 1:1 与「半幅（3 列 × 3 行）」一致；上一版一槽装一整列时是 2:3，两版各自都对，⛔ 别混着抄。
+ *     宽高比 1:1 与「半幅（4 列 × 4 行）」一致；更早按列分槽那一版一槽装一整列时是 2:3，两版各自都对，⛔ 别混着抄。
  *  2. **色彩**：瓦片纹理 `colorSpace = SRGBColorSpace` ⇒ WebGL2 内部格式 `SRGB8_ALPHA8`，采样时硬件解码成
  *     linear；RT 纹理同样标 sRGB ⇒ 写入时硬件再编码回 sRGB。一进一出**逐字节还原**。
  *     ⚠️ 另一半证据在 three 里：写进非 XR 的 render target 时片元末尾的 `linearToOutputTexel` 恒按
  *     LinearSRGB（= 不转换），编码完全交给硬件 ⇒ ⛔ 我们的片元绝不 `#include <colorspace_fragment>`，
  *     也不带 tone mapping 的 chunk（那两处都会再转一遍 ⇒ 画面发白）。
  *  3. **摩尔纹**：两层都开 mipmap ——
- *     ① 瓦片纹理 `generateMipmaps` + `LinearMipmapLinearFilter`：一片原图（~1995×1995）铺进 2048×2048
+ *     ① 瓦片纹理 `generateMipmaps` + `LinearMipmapLinearFilter`：一片原图（~1496×1496）铺进 1536×1536
  *        的格子是**一比一**，但墙面在远处仍会缩到格子以下 ⇒ ⛔ 单点双线性会采出锯齿，mipmap 照旧开
  *        （WebGL2 对 NPOT 也能生成 mipmap，three r163 起只支持 WebGL2）。
  *     ② 槽 RT 标 `generateMipmaps`：three 每次渲染进 RT 后自己 `glGenerateMipmap`（`WebGLRenderer.js`
  *        `updateRenderTargetMipmap`）⇒ 与当年 CanvasTexture 上传后生成 mipmap 同一口径。
  *        ⚠️ 代价：每格一次（旧版每格也是一次），都在 GPU 上、不占主线程。
- *  4. **接缝**：槽内「横 3 × 竖 3」⇒ 一张槽内部的格子线是 **2 横 2 竖**（上一版一槽一整列时只有 2 横 0 竖）；
- *     槽与槽之间另有 u=1/2 **一道**跨纹理竖缝，那道治不了（见 `PanoTexMode` 说明②；上一版是两道）。治法 = 上传时每片向四边**多切**
+ *  4. **接缝**：槽内「横 4 × 竖 4」⇒ 一张槽内部的格子线是 **3 横 3 竖**（上一版 3×3 是 2 横 2 竖；更早一槽一整列时只有 2 横 0 竖）；
+ *     槽与槽之间另有 u=1/2 **一道**跨纹理竖缝，那道治不了（见 `PanoTexMode` 说明②；更早按列 3 槽那版才是两道）。治法 = 上传时每片向四边**多切**
  *     `RT_STITCH_SEAM_MARGIN_PX` 像素、拼合时**只采中间那块**（`uSrcRect`）⇒ 边界插值拿得到真邻居像素，
  *     不再复制自己的边缘。⛔ 这条不许「顺手简化」成直接铺满格子：几何会挤歪，缝也还在。
  *     详见 `./mktShader` 里那三个 `rtStitch*` 纯函数 —— **上传侧与拼合侧必须共用同一份几何**。
  *
- * 资源账（⚠️ 如实记；10-26 需求改 6×3=18 片 / 左右 2 槽 / 6144×6144 后重算）：
+ * 资源账（⚠️ 如实记；2026-10-27 需求改 8×4=32 片 / 左右 2 槽 / 6144×6144 后重算 —— 槽尺寸一字未动 ⇒ 显存那一栏不变）：
  *   - 常驻显存：2 槽 × (6144×**6144**×4B + mipmap≈33%) ≈ **384MB/全景**（不含 mipmap 288MB —— 与上一版**一字不差**）
  *     —— 更早那版 8×4=32 片 / 2 槽 4096² 只有 **170MB/全景** ⇒ 单全景 **2.26 倍**，代价来自「槽与原图一比一」那次**升分辨率**，
  *     不是浪费：33.5Mpx → 75.5Mpx 的有效像素全在 RT 里。
- *     ⚠️ 组**运行中不淘汰**（见文末那条需求）⇒ 13 张全景全常驻 ≈ **4.9GB**（上一版 2.2GB）。同屏景点数虽回到 8，
+ *     ⚠️ 组**运行中不淘汰**（见文末那条需求）⇒ 13 张全景全常驻 ≈ **4.9GB**（上一版同数 —— 单全景显存一字未动）。同屏景点数 8，
  *     那只省 sampler 绑定、**不省显存**。⚠️ 这是这一轮最大的风险项，已另记待用户裁决（见「RT 不回收」）。
- *   - 上传总量：同一张原图切完 ⇒ **总像素与上一版逐字节同量**，片数 9 → 18、每片 4096×2048 → 2048×2048（单片像素减半）
- *     ⇒ 下载发起数比 9 片那版**翻倍**（仍比 32 片那版少 14 条）、单请求变小。
+ *   - 上传总量：同一张原图切完 ⇒ **总像素与上一版逐字节同量**，片数 18 → 32、每片 2048×2048 → 1536×1536（单片像素减到 ≈0.56 倍）
+ *     ⇒ 下载发起数比 18 片那版**多 14 条**（与 10-06 那版 32 片同数）、单请求更小。
  *   - 瓦片纹理画完即弃 ⇒ 同时在册的只有「下载中 + 已解码待上传」那些，上限 8+8 片；
- *     ⚠️ 每片解码位图 2048×2048×4B = **16MB**（上一版每片 4096×2048 = 32MB）⇒ 峰值 CPU 侧 ≈ **256MB**（原 512MB）。
+ *     ⚠️ 每片解码位图 1536×1536×4B = **9MB**（上一版每片 2048×2048 = 16MB）⇒ 闸内在制品峰值 CPU 侧 ≈ **144MB**（原 256MB）；
+ *     一组 32 片若全解码则是 ≈**288MB**（上一版 18 片 × 16MB = 288MB —— **同一量**）。
  *
  * ⚠️ RT 是 GL 上下文私有资源：`pump(renderer)` 换 renderer 时整组作废（`_switchRenderer`），下一帧消费方
  *   照旧的 `ensure()` 重建（瓦片走浏览器 HTTP 缓存重新下载）。现况是**每个持有者一份拼合器 + 一个 renderer**
@@ -135,13 +144,13 @@ import {
  */
 const PANO_STITCH_UPLOADS_PER_FRAME = 1;
 
-/** 每帧最多发起几张下载（现行一批 18 片，⛔ 不加以限制就是一帧甩 18 条 XHR + 18 次 400 万像素解码） */
+/** 每帧最多发起几张下载（现行一批 32 片，⛔ 不加以限制就是一帧甩 32 条 XHR + 32 次 ≈236 万像素解码） */
 const PANO_STITCH_DOWNLOADS_PER_FRAME = 2;
 
 /** 「下载中」的片数上限（跨所有批次） */
 const PANO_STITCH_MAX_INFLIGHT = 8;
 
-/** 「已解码、还没上传进 GPU」的片数上限 ⇒ 也是 CPU 侧位图的峰值内存闸（≈8 × 4.6MB） */
+/** 「已解码、还没上传进 GPU」的片数上限 ⇒ 也是 CPU 侧位图的峰值内存闸（≈8 × 9MB，每片 1536×1536×4B） */
 const PANO_STITCH_MAX_DECODED_AHEAD = 8;
 
 /** 瓦片纹理的实际像素宽高（`loadPanoTexture` 交回来的是 `ImageBitmap`，尺寸就是切片区）。
@@ -228,7 +237,7 @@ interface StitchGroup {
  */
 export interface PanoStitcher {
     /** 确保批次已在册并发起瓦片加载（幂等；同批已在册 ⇒ 什么都不做）。
-     *  新增可选 `layout` 参数：缺省 = PANO_TILE_LAYOUT（全景 6×3 / 2 槽 / 6144×6144，10-26 需求）；
+     *  新增可选 `layout` 参数：缺省 = PANO_TILE_LAYOUT（全景 8×4 / 2 槽 / 6144×6144，2026-10-27 需求）；
      *  图片平面传 `imageTileLayout(natW, natH)`（2×2 / 1 槽 / RT 宽高比=原图）。 */
     ensure(urls: string[], layout?: TileLayout): void;
     /**
@@ -296,7 +305,7 @@ private _uploadQueued: Set<TileRec> = new Set();
         blending: NoBlending,
     });
     /** 几何是 2×2（铺满正交相机的 [-1,1]²），每格按 `1/slotCellCols × 1/slotCellRows` 缩放再挪过去
-     *  ⇒ 全景一格 = 槽的 1/3（横 1 竖 3，10-23 旨），图片平面一格 = 1/4（横 2 竖 2） */
+     *  ⇒ 全景一格 = 槽的 1/4 宽 × 1/4 高（横 4 竖 4，2026-10-27 口径），图片平面一格 = 1/4（横 2 竖 2） */
     private _quad: Mesh<PlaneGeometry, ShaderMaterial> = new Mesh(new PlaneGeometry(2, 2), this._mat);
     /** 缺格那一路 `uMap` 也要有个合法纹理可绑（1×1，从不真采样） */
     private _blank: DataTexture = new DataTexture(new Uint8Array([0, 0, 0, 255]), 1, 1);
@@ -310,10 +319,12 @@ private _uploadQueued: Set<TileRec> = new Set();
     }
 
     /** 确保批次已建组、加载已发起。幂等：同批已在册 ⇒ 直接返回（一片瓦片终身只下载、只解码一次）。
-     *  ⭐ 09-29「不足的涂灰」+ 10-26「6×3 = 18 片」：1~18 条皆可入组，内部补空串占位到 18；
+     *  ⭐ 09-29「不足的涂灰」+ 2026-10-27「8×4 = 32 片」：1~32 条皆可入组，内部补空串占位到 32；
      *  空串 / 死链的格子拼合时涂灰（一眼看出该全景数据不全）。
-     *  ⛔ 旧版 16 条（4×4）、32 条（8×4）、64 条（8×8）与 9 条（3×3）的数据**都不做兼容**（用户「无须兼容正常使用, 有异常我会重传」）：
-     *  超 18 条会在上一行被判超限直接丢弃；真喂进来的短数据只占前几格 + 其余涂灰，那是**故意**让数据不全看得见。
+     *  ⛔ 旧版 18 条（6×3）、16 条（4×4）、64 条（8×8）与 9 条（3×3）的数据**都不做兼容**（用户「无须兼容正常使用, 有异常我会重传」）：
+     *  超 32 条会在上一行被判超限直接丢弃；真喂进来的短数据只占前几格 + 其余涂灰，那是**故意**让数据不全看得见。
+     *  ⚠️ 唯一按张数**能混进来**的是 10-06 那版同为 32 片的老档（切片顺序与槽分组两版一致 ⇒ 不会错位），
+     *  但它的瓦片是 1024²、被画进 1536² 的格子 = 1.5× 放大 ⇒ 发虚，那类老点仍要重传一次。
      *  ⚠️ 每槽数组长度由 `RT_STITCH_SLOT_COUNT` 派生（⛔ 不许手写 `[null,null]` —— 槽数再变会漏改）。 */
     ensure(urls: string[], layout?: TileLayout): void {
         const L = layout ?? PANO_TILE_LAYOUT;
@@ -533,14 +544,14 @@ private _uploadQueued: Set<TileRec> = new Set();
     // ───────────────────────── 内部：单格绘制 ─────────────────────────
 
     /** 画一格：把那片瓦片的**中间那块**铺进该槽第 `cell` 格（每槽 `slotCellCols × slotCellRows` 格里的一格，
-     *  10-26 起全景是「横 3 × 竖 3」= 9 格、图片平面是 2×2 = 4 格）。
+     *  2026-10-27 起全景是「横 4 × 竖 4」= 16 格、图片平面是 2×2 = 4 格）。
      *  ⚠️⚠️ `autoClear` 必须关掉：three 每次 `render()` 默认清屏，而这里**同一张 RT 要连画 cellsPerSlot 帧**，
      *     清一次就把前面画好的格子抹了 ⇒ 槽纹理只剩最后一格。清屏交给我们自己（见 `_clearRt`）。 */
     private _stitchCell(renderer: WebGLRenderer, g: StitchGroup, slot: number, cell: number, tex: Texture | null): void {
         const rt = this._ensureRt(renderer, g, slot);
         const tileIdx = g.slotTiles[slot][cell];
         const [cc, rr] = rtStitchCellPos(cell, g.layout.slotCellCols);
-        // ⚠️ 横竖**分轴**缩放/摆位（旧的单一 `slotGrid` 方形假设整条作废）：10-26 起全景一槽 = 原图半幅 ⇒ 3 横 3 竖，图片平面那档 2 横 2 竖
+        // ⚠️ 横竖**分轴**缩放/摆位（旧的单一 `slotGrid` 方形假设整条作废）：现行全景一槽 = 原图半幅 ⇒ 4 横 4 竖，图片平面那档 2 横 2 竖
         const cw = g.layout.slotCellCols;
         const ch = g.layout.slotCellRows;
         this._quad.scale.set(1 / cw, 1 / ch, 1);

package/MktMesh/types.d.ts

@@ -25,7 +25,8 @@ export interface MktTextureInfo {
      * ⭐ 皇上旨 2026-10-06 晚（逐字）「我希望一次能够展示 8 个全景纹理, 每个全景纹理由左右 2 个 RT 组成,
      * 每个 RT 由 16 个全景瓦片组成, 所以, 全景图在上传的时候, 只需要拆分成 横 8 * 竖 4 = 32 个瓦片图就可以了」
      * ⇒ **现行唯一形态 = 32 张（横 8 × 竖 4）**：行优先从图像左上开始，运行时由
-     * `PanoTileStitcher` 用 shader 逐格画进 **2 张 4096×4096** `WebGLRenderTarget`（左半幅 / 右半幅，每槽 4×4 格），
+     * `PanoTileStitcher` 用 shader 逐格画进 **2 张 6144×6144** `WebGLRenderTarget`（左半幅 / 右半幅，每槽 4×4 格；
+     *   槽尺寸是 10-26 那版定的，2026-10-27 回到 32 片切档时一字未动），
      * 2 槽组成完整全景再喂 shader。⚠️ 同一天早些时候那道「8×8 = 64 片 / 4 张 4096×2048」**已作废**。
      * ⚠️ 每片向四边**多带** `RT_STITCH_SEAM_MARGIN_PX` 像素的邻居余量（治内部接缝；采样窗口由
      *   `rtStitchTileInset` 还原），所以片宽 ≠ 原图正好 1/8、片高 ≠ 正好 1/4。

package/MktMesh/types.ts

@@ -33,7 +33,8 @@ export interface MktTextureInfo {
      * ⭐ 皇上旨 2026-10-06 晚（逐字）「我希望一次能够展示 8 个全景纹理, 每个全景纹理由左右 2 个 RT 组成,
      * 每个 RT 由 16 个全景瓦片组成, 所以, 全景图在上传的时候, 只需要拆分成 横 8 * 竖 4 = 32 个瓦片图就可以了」
      * ⇒ **现行唯一形态 = 32 张（横 8 × 竖 4）**：行优先从图像左上开始，运行时由
-     * `PanoTileStitcher` 用 shader 逐格画进 **2 张 4096×4096** `WebGLRenderTarget`（左半幅 / 右半幅，每槽 4×4 格），
+     * `PanoTileStitcher` 用 shader 逐格画进 **2 张 6144×6144** `WebGLRenderTarget`（左半幅 / 右半幅，每槽 4×4 格；
+     *   槽尺寸是 10-26 那版定的，2026-10-27 回到 32 片切档时一字未动），
      * 2 槽组成完整全景再喂 shader。⚠️ 同一天早些时候那道「8×8 = 64 片 / 4 张 4096×2048」**已作废**。
      * ⚠️ 每片向四边**多带** `RT_STITCH_SEAM_MARGIN_PX` 像素的邻居余量（治内部接缝；采样窗口由
      *   `rtStitchTileInset` 还原），所以片宽 ≠ 原图正好 1/8、片高 ≠ 正好 1/4。

package/ThreeBase.d.ts

@@ -44,6 +44,8 @@ export default class ThreeBase extends EventDispatcher<ThreeBaseEventTypeMap> {
     maxPixelRatio: number;
     renderScale: number;
     private _resolution;
+    /** baseRenderTarget 之外**全部** RT 的倍率（深度 / 法线 / 各效果 mask / 屏幕合成）；1 = 不超采样 */
+    auxResolution: number;
     get resolution(): number;
     set resolution(value: number);
     /**
@@ -127,7 +129,8 @@ export default class ThreeBase extends EventDispatcher<ThreeBaseEventTypeMap> {
     setContainer(div: HTMLDivElement | null): Promise<void>;
     setSize(width: number, height: number): void;
     /**
-     * 按「容器尺寸 × effectiveRatio × resolution」重建所有渲染目标尺寸。
+     * 按「容器尺寸 × effectiveRatio」重建所有渲染目标尺寸：base 再乘 resolution，
+     * 其余（深度 / 法线 / mask / 屏幕合成）再乘 auxResolution。
      * 由 setSize()（容器尺寸变化）与 resolution setter（运行时调倍率）共用 ——
      * 关键：resolution 是运行时可调的性能/质量旋钮，改完必须立刻重建 RT，
      * 否则倍率变了而 RT 尺寸没变，画面毫无变化（历史坑："调分辨率没感觉"）。