three-base 2.0.181 → 2.0.187

package/MktMesh/panoTileStitcher.d.ts

@@ -6,7 +6,7 @@ import { type TileLayout } from "./mktShader";
  */
 export interface PanoStitcher {
     /** 确保批次已在册并发起瓦片加载（幂等；同批已在册 ⇒ 什么都不做）。
-     *  新增可选 `layout` 参数：缺省 = PANO_TILE_LAYOUT（全景 3×3 / 3 槽 / 4096×6144，10-23 旨）；
+     *  新增可选 `layout` 参数：缺省 = PANO_TILE_LAYOUT（全景 6×3 / 2 槽 / 6144×6144，10-26 需求）；
      *  图片平面传 `imageTileLayout(natW, natH)`（2×2 / 1 槽 / RT 宽高比=原图）。 */
     ensure(urls: string[], layout?: TileLayout): void;
     /**
@@ -67,11 +67,11 @@ export declare class PanoTileStitcher implements PanoStitcher {
     private _rtTextures;
     constructor();
     /** 确保批次已建组、加载已发起。幂等：同批已在册 ⇒ 直接返回（一片瓦片终身只下载、只解码一次）。
-     *  ⭐ 09-29 晚旨「不足的涂灰」+ 10-23 旨「3×3 = 9 片」：1~9 条皆可入组，内部补空串占位到 9；
+     *  ⭐ 09-29「不足的涂灰」+ 10-26「6×3 = 18 片」：1~18 条皆可入组，内部补空串占位到 18；
      *  空串 / 死链的格子拼合时涂灰（一眼看出该全景数据不全）。
-     *  ⛔ 旧版 16 条（4×4）、32 条（8×4）与 64 条（8×8）的数据**都不做兼容**（皇上「无须兼容正常使用, 有异常我会重传」）：
-     *  超 9 条会在上一行被判超限直接丢弃；真喂进来的短数据只占前几格 + 其余涂灰，那是**故意**让数据不全看得见。
-     *  ⚠️ 每槽数组长度由 `RT_STITCH_SLOT_COUNT` 派生（⛔ 不许手写 `[null,null,null]` —— 槽数再变会漏改）。 */
+     *  ⛔ 旧版 16 条（4×4）、32 条（8×4）、64 条（8×8）与 9 条（3×3）的数据**都不做兼容**（用户「无须兼容正常使用, 有异常我会重传」）：
+     *  超 18 条会在上一行被判超限直接丢弃；真喂进来的短数据只占前几格 + 其余涂灰，那是**故意**让数据不全看得见。
+     *  ⚠️ 每槽数组长度由 `RT_STITCH_SLOT_COUNT` 派生（⛔ 不许手写 `[null,null]` —— 槽数再变会漏改）。 */
     ensure(urls: string[], layout?: TileLayout): void;
     /** 取某一拼合槽的纹理：**画过 ≥1 格就交出去**（同日旨「需要先喂给 shader」⇒ 不再等 `cellsPerSlot` 格画满）。
      *  RT 建好时整张涂过缺失灰 ⇒ 交出去的那张里**没有未定义像素**，观感 = 该象限逐格显影。 */
@@ -121,7 +121,7 @@ export declare class PanoTileStitcher implements PanoStitcher {
      *   （与 `MktMesh._uploadTileTexture` 的「排上队之后已被清掉 ⇒ 本项作废」同一口径。） */
     private _uploadTile;
     /** 画一格：把那片瓦片的**中间那块**铺进该槽第 `cell` 格（每槽 `slotCellCols × slotCellRows` 格里的一格，
-     *  10-23 旨后全景是「横 1 × 竖 3」= 3 格、图片平面是 2×2 = 4 格）。
+     *  10-26 起全景是「横 3 × 竖 3」= 9 格、图片平面是 2×2 = 4 格）。
      *  ⚠️⚠️ `autoClear` 必须关掉：three 每次 `render()` 默认清屏，而这里**同一张 RT 要连画 cellsPerSlot 帧**，
      *     清一次就把前面画好的格子抹了 ⇒ 槽纹理只剩最后一格。清屏交给我们自己（见 `_clearRt`）。 */
     private _stitchCell;
@@ -140,7 +140,7 @@ export declare class PanoTileStitcher implements PanoStitcher {
     /** 换 renderer：RT 是旧上下文的私有资源，留着既画不了也释放不掉 ⇒ 在册组整份作废，
      *  靠消费方每帧照旧的 `ensure()` 重建（瓦片走浏览器 HTTP 缓存，不重新编码）。 */
     private _switchRenderer;
-    /** 懒建某槽的渲染目标：尺寸取自 `g.layout.rtW/rtH`（全景档 = **4096×6144**，10-23 旨）、RGBA8 + sRGB + mipmap，
+    /** 懒建某槽的渲染目标：尺寸取自 `g.layout.rtW/rtH`（全景档 = **6144×6144**，10-26 需求）、RGBA8 + sRGB + mipmap，
      *  并**立刻整张涂缺失灰**（⛔ 未定义像素不许进 shader：`peek()` 现在画过 1 格就交出去）。
      *  ⚠️ 6144 这个数受本机 `MAX_TEXTURE_SIZE` / 最大渲染目标尺寸约束（ANGLE/D3D11 的 11_0 是 16384，远超；
      *     只有老 Intel 集显才可能卡 4096 —— 真建不出来 three 会报 `GL_INVALID_VALUE`，届时墙上整片缺失灰）。 */

package/MktMesh/panoTileStitcher.js

@@ -1,5 +1,5 @@
 /*
- * @Description: 9 瓦片全景的「离屏拼合器」= **shader 逐格画进 WebGLRenderTarget**（本项目唯一一份拼合实现）。
+ * @Description: 18 瓦片全景的「离屏拼合器」= **shader 逐格画进 WebGLRenderTarget**（本项目唯一一份拼合实现）。
  *
  * 三道旨意叠成现在这一份：
  *   ① 2026-09-29：一张全景切多片（每片所有 GPU 都装得下），运行时离屏拼回若干张固定尺寸的「槽纹理」，
@@ -23,9 +23,14 @@
  *      ⇒ 改 **3×3=9 片 / 按列 3 槽**，每槽 = 原图一整列（横 1 格 × 竖 3 格）= **4096×6144**、与原图 1:1（不再缩小）。
  *      ⚠️ 代价（皇上在「A/B/C/D」里点了 **A**）：sampler = 同屏景点数 × 3，硬顶 16 ⇒ **同屏全景点数 8 → 5**（5×3=15）。
  *         单全景 RT 显存 170MB → **288MB**（含 mipmap ≈384MB）。旧存档 32 条地址**不兼容**，「有异常我会重传」。
+ *   ⑤ 2026-10-26（需求，逐字）：「目前的 全景球是 9片瓦片图的方案, 我想要换成6*3 的18片的方案呢, 就像之前一样的
+ *      方案一样 一个全景是 2个RT 每个 RT上面是 4*4 的方案, 现在我想要改成 2个RT 每个RT 上面 3*3=9 的方案」
+ *      ⇒ 改 **6×3=18 片 / 左右 2 槽**，每槽 = 原图半幅（横 3 格 × 竖 3 格）= **6144×6144**、与原图 1:1。
+ *      ⭐ 净效果：单全景有效分辨率与显存**一字未动**（仍是 75.5Mpx / ≈384MB），sampler = 点数 × 2 ⇒
+ *         **同屏全景点数 5 → 8**（8×2=16 正好用满硬顶）。旧存档 9 条地址**不兼容**，用户重传即可。
  *
  * ⚠️ **仍然有 canvas，但只在上传切图那一步**（`src/views/MktMeshEdit/panoramaUpload.ts` 用 2D 画布把原图
- *    切成 9 个 JPEG 传 OSS）—— 那是**离线、一次性、产出的是数据**；运行时这条路上一个 canvas 都没有。
+ *    切成 18 个 JPEG 传 OSS）—— 那是**离线、一次性、产出的是数据**；运行时这条路上一个 canvas 都没有。
  *
  * ── 每帧的三道工序（旨②那两句话逐条落地，顺序固定）────────────────────────────────
  *   1. `_pumpDownloads()`：补发缺图的下载（每帧 ≤2 张、在册 ≤8、已解码待上传 ≤8）⇒ ⛔ 一批几十条 XHR 一起炸。
@@ -35,49 +40,49 @@
  *      到 GPU 里面去」）。这一趟**只上传、不画** ⇒ 上传与绘制永不落在同一拍（09-29 那句「两个大头别在同一
  *      帧」的延续），而且第 2 步天然只能画「上一帧及更早」传上去的图 ⇒ 每帧 = 1 上传 + 1 绘制（稳态）。
  *
- * ⚠️ 于是「一帧一片」的帧数随网格走：16 片 → 32 片（30ms/帧 ⇒ 全量到位约 1.0s）→ **9 片/组 = 9 帧**（约 0.27s，
- *    10-23 旨）。每格像素 = `RT_STITCH_SLOT_W/1 × RT_STITCH_SLOT_H/3` = **4096×2048**（原图切出来那片多大就多大，一比一）。
- *    且因为下面那条「先喂 shader」的旨意，第一格画完墙上就有东西了，不必等 9 帧。
+ * ⚠️ 于是「一帧一片」的帧数随网格走：16 片 → 32 片 → 9 片 → **18 片/组 = 18 帧**（30ms/帧 ⇒ 约 0.55s，
+ *    10-26 需求）。每格像素 = `RT_STITCH_SLOT_W/3 × RT_STITCH_SLOT_H/3` = **2048×2048**（原图切出来那片多大就多大，一比一）。
+ *    且因为下面那条「先喂 shader」的旨意，第一格画完墙上就有东西了，不必等 18 帧。
  *
  * ⭐ 部分就绪就先喂（同日旨「1. 需要先喂给 shader」）：`peek()` 不再等一个槽的 `cellsPerSlot` 格画满，
  *   **画过 ≥1 格就交出去**。为了保证交出去的那张 RT 里绝无未定义像素，RT 建好后的第一件事是
  *   整张涂成缺失灰（`_clearRt`）⇒ 观感 = 该象限从左上角起逐格显影，缺数据的格子一直是灰的。
  *
  * ── 画质四条（⛔ 改任何一条都是改画质，先请旨）──────────────────────────────
- *  1. **尺寸 / 格子几何**：槽 `RT_STITCH_SLOT_W/H` = **4096×6144**、每槽「横 1 格 × 竖 3 格」、原图**横 3 × 竖 3** 片，
+ *  1. **尺寸 / 格子几何**：槽 `RT_STITCH_SLOT_W/H` = **6144×6144**、每槽「横 3 格 × 竖 3 格」、原图**横 6 × 竖 3** 片，
  *     全在 `./mktShader`（单一来源）。⭐ 10-23 旨后格子尺寸 = 那片瓦片的尺寸 ⇒ **一比一**：11968×5984 那类原图
- *     切 3×3 得 ~3989×1994 的片，铺进 4096×2048 的格子几乎不缩（缩放比 0.97，上一版 8×4 是 1.46 = 缩小）
+ *     切 6×3 得 ~1995×1995 的片，铺进 2048×2048 的格子几乎不缩（缩放比 1.03，与上一版同一档）
  *     ⇒ 单全景有效分辨率 33.5Mpx → **75.5Mpx**，是**升**画质，与「千万不要降低质量」红线同向。
- *     ⛔ 不许把槽改回 4096² 正方形：那是上一版「每槽覆盖横 180°×竖 180°」的产物；现口径每槽只覆盖**横 120° × 竖 180°**，
- *     宽高比 2:3 必须与「原图一整列」一致，否则格子被强行拉伸 = 几何挤歪。
+ *     ⛔ 不许拿槽尺寸当省显存的旋钮：现口径每槽覆盖**横 180° × 竖 180°**（原图左/右半幅），
+ *     宽高比 1:1 与「半幅（3 列 × 3 行）」一致；上一版一槽装一整列时是 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`：10-23 旨后一片原图（~3989×1994）铺进 4096×2048
+ *     ① 瓦片纹理 `generateMipmaps` + `LinearMipmapLinearFilter`：一片原图（~1995×1995）铺进 2048×2048
  *        的格子是**一比一**，但墙面在远处仍会缩到格子以下 ⇒ ⛔ 单点双线性会采出锯齿，mipmap 照旧开
  *        （WebGL2 对 NPOT 也能生成 mipmap，three r163 起只支持 WebGL2）。
  *     ② 槽 RT 标 `generateMipmaps`：three 每次渲染进 RT 后自己 `glGenerateMipmap`（`WebGLRenderer.js`
  *        `updateRenderTargetMipmap`）⇒ 与当年 CanvasTexture 上传后生成 mipmap 同一口径。
  *        ⚠️ 代价：每格一次（旧版每格也是一次），都在 GPU 上、不占主线程。
- *  4. **接缝**：槽内「横 1 × 竖 3」⇒ 一张槽内部的格子线是 **2 横 0 竖**（上一版 4096² 是 3 横 3 竖）；
- *     槽与槽之间另有 u=1/3、u=2/3 两道**跨纹理**竖缝，那道治不了（见 `PanoTexMode` 说明②）。治法 = 上传时每片向四边**多切**
+ *  4. **接缝**：槽内「横 3 × 竖 3」⇒ 一张槽内部的格子线是 **2 横 2 竖**（上一版一槽一整列时只有 2 横 0 竖）；
+ *     槽与槽之间另有 u=1/2 **一道**跨纹理竖缝，那道治不了（见 `PanoTexMode` 说明②；上一版是两道）。治法 = 上传时每片向四边**多切**
  *     `RT_STITCH_SEAM_MARGIN_PX` 像素、拼合时**只采中间那块**（`uSrcRect`）⇒ 边界插值拿得到真邻居像素，
  *     不再复制自己的边缘。⛔ 这条不许「顺手简化」成直接铺满格子：几何会挤歪，缝也还在。
  *     详见 `./mktShader` 里那三个 `rtStitch*` 纯函数 —— **上传侧与拼合侧必须共用同一份几何**。
  *
- * 资源账（⚠️ 如实记；10-23 旨改 3×3=9 片 / 按列 3 槽 / 4096×6144 后重算）：
- *   - 常驻显存：3 槽 × (4096×**6144**×4B + mipmap≈33%) ≈ **384MB/全景**（不含 mipmap 288MB）
- *     —— 上一版 2 槽 4096² 是 **170MB/全景** ⇒ 单全景变成 **2.26 倍**，代价来自「槽与原图一比一」那次**升分辨率**，
+ * 资源账（⚠️ 如实记；10-26 需求改 6×3=18 片 / 左右 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）。同屏景点数虽收到 5，
- *     那只省 sampler 绑定、**不省显存**。⚠️ 这是本轮最大的风险项，已另记待皇上裁决（见「RT 不回收」）。
- *   - 上传总量：同一张原图切完 ⇒ **总像素与 32 片那版逐字节同量**，只是片数 32 → 9、单片边长 ~2.7 倍
- *     ⇒ 下载发起数减 72%、单请求变大。
+ *     ⚠️ 组**运行中不淘汰**（见文末那条需求）⇒ 13 张全景全常驻 ≈ **4.9GB**（上一版 2.2GB）。同屏景点数虽回到 8，
+ *     那只省 sampler 绑定、**不省显存**。⚠️ 这是这一轮最大的风险项，已另记待用户裁决（见「RT 不回收」）。
+ *   - 上传总量：同一张原图切完 ⇒ **总像素与上一版逐字节同量**，片数 9 → 18、每片 4096×2048 → 2048×2048（单片像素减半）
+ *     ⇒ 下载发起数比 9 片那版**翻倍**（仍比 32 片那版少 14 条）、单请求变小。
  *   - 瓦片纹理画完即弃 ⇒ 同时在册的只有「下载中 + 已解码待上传」那些，上限 8+8 片；
- *     ⚠️ 每片解码位图 4096×2048×4B = **32MB**（上一版每片 8.5MB）⇒ 峰值 CPU 侧 ≈ **512MB**（原 ~136MB）。
+ *     ⚠️ 每片解码位图 2048×2048×4B = **16MB**（上一版每片 4096×2048 = 32MB）⇒ 峰值 CPU 侧 ≈ **256MB**（原 512MB）。
  *
  * ⚠️ RT 是 GL 上下文私有资源：`pump(renderer)` 换 renderer 时整组作废（`_switchRenderer`），下一帧消费方
  *   照旧的 `ensure()` 重建（瓦片走浏览器 HTTP 缓存重新下载）。现况是**每个持有者一份拼合器 + 一个 renderer**
@@ -98,7 +103,7 @@ import { MISSING_TILE_GRAY, rtStitchBatchOf, rtStitchCellPos, rtStitchTileInset,
  *   ⛔ 别再拿它去写 budget 循环：那正是「一帧上传 2 张」的根因（消费方 onBeforeRender 里 pump 了两次）。
  */
 const PANO_STITCH_UPLOADS_PER_FRAME = 1;
-/** 每帧最多发起几张下载（10-23 起一批 9 片，⛔ 不加以限制就是一帧甩 9 条 XHR + 9 次 800 万像素解码） */
+/** 每帧最多发起几张下载（现行一批 18 片，⛔ 不加以限制就是一帧甩 18 条 XHR + 18 次 400 万像素解码） */
 const PANO_STITCH_DOWNLOADS_PER_FRAME = 2;
 /** 「下载中」的片数上限（跨所有批次） */
 const PANO_STITCH_MAX_INFLIGHT = 8;
@@ -199,11 +204,11 @@ export class PanoTileStitcher {
         this._blank.needsUpdate = true;
     }
     /** 确保批次已建组、加载已发起。幂等：同批已在册 ⇒ 直接返回（一片瓦片终身只下载、只解码一次）。
-     *  ⭐ 09-29 晚旨「不足的涂灰」+ 10-23 旨「3×3 = 9 片」：1~9 条皆可入组，内部补空串占位到 9；
+     *  ⭐ 09-29「不足的涂灰」+ 10-26「6×3 = 18 片」：1~18 条皆可入组，内部补空串占位到 18；
      *  空串 / 死链的格子拼合时涂灰（一眼看出该全景数据不全）。
-     *  ⛔ 旧版 16 条（4×4）、32 条（8×4）与 64 条（8×8）的数据**都不做兼容**（皇上「无须兼容正常使用, 有异常我会重传」）：
-     *  超 9 条会在上一行被判超限直接丢弃；真喂进来的短数据只占前几格 + 其余涂灰，那是**故意**让数据不全看得见。
-     *  ⚠️ 每槽数组长度由 `RT_STITCH_SLOT_COUNT` 派生（⛔ 不许手写 `[null,null,null]` —— 槽数再变会漏改）。 */
+     *  ⛔ 旧版 16 条（4×4）、32 条（8×4）、64 条（8×8）与 9 条（3×3）的数据**都不做兼容**（用户「无须兼容正常使用, 有异常我会重传」）：
+     *  超 18 条会在上一行被判超限直接丢弃；真喂进来的短数据只占前几格 + 其余涂灰，那是**故意**让数据不全看得见。
+     *  ⚠️ 每槽数组长度由 `RT_STITCH_SLOT_COUNT` 派生（⛔ 不许手写 `[null,null]` —— 槽数再变会漏改）。 */
     ensure(urls, layout) {
         const L = layout ?? PANO_TILE_LAYOUT;
         const maxTiles = tilesPerBatchOf(L);
@@ -437,14 +442,14 @@ export class PanoTileStitcher {
     }
     // ───────────────────────── 内部：单格绘制 ─────────────────────────
     /** 画一格：把那片瓦片的**中间那块**铺进该槽第 `cell` 格（每槽 `slotCellCols × slotCellRows` 格里的一格，
-     *  10-23 旨后全景是「横 1 × 竖 3」= 3 格、图片平面是 2×2 = 4 格）。
+     *  10-26 起全景是「横 3 × 竖 3」= 9 格、图片平面是 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-23 旨一槽 = 原图一整列 ⇒ 1 横 3 竖
+        // ⚠️ 横竖**分轴**缩放/摆位（旧的单一 `slotGrid` 方形假设整条作废）：10-26 起全景一槽 = 原图半幅 ⇒ 3 横 3 竖，图片平面那档 2 横 2 竖
         const cw = g.layout.slotCellCols;
         const ch = g.layout.slotCellRows;
         this._quad.scale.set(1 / cw, 1 / ch, 1);
@@ -558,7 +563,7 @@ export class PanoTileStitcher {
         this._fails.clear();
         this._dead.clear();
     }
-    /** 懒建某槽的渲染目标：尺寸取自 `g.layout.rtW/rtH`（全景档 = **4096×6144**，10-23 旨）、RGBA8 + sRGB + mipmap，
+    /** 懒建某槽的渲染目标：尺寸取自 `g.layout.rtW/rtH`（全景档 = **6144×6144**，10-26 需求）、RGBA8 + sRGB + mipmap，
      *  并**立刻整张涂缺失灰**（⛔ 未定义像素不许进 shader：`peek()` 现在画过 1 格就交出去）。
      *  ⚠️ 6144 这个数受本机 `MAX_TEXTURE_SIZE` / 最大渲染目标尺寸约束（ANGLE/D3D11 的 11_0 是 16384，远超；
      *     只有老 Intel 集显才可能卡 4096 —— 真建不出来 three 会报 `GL_INVALID_VALUE`，届时墙上整片缺失灰）。 */

package/MktMesh/panoTileStitcher.ts

@@ -1,5 +1,5 @@
 /*
- * @Description: 9 瓦片全景的「离屏拼合器」= **shader 逐格画进 WebGLRenderTarget**（本项目唯一一份拼合实现）。
+ * @Description: 18 瓦片全景的「离屏拼合器」= **shader 逐格画进 WebGLRenderTarget**（本项目唯一一份拼合实现）。
  *
  * 三道旨意叠成现在这一份：
  *   ① 2026-09-29：一张全景切多片（每片所有 GPU 都装得下），运行时离屏拼回若干张固定尺寸的「槽纹理」，
@@ -23,9 +23,14 @@
  *      ⇒ 改 **3×3=9 片 / 按列 3 槽**，每槽 = 原图一整列（横 1 格 × 竖 3 格）= **4096×6144**、与原图 1:1（不再缩小）。
  *      ⚠️ 代价（皇上在「A/B/C/D」里点了 **A**）：sampler = 同屏景点数 × 3，硬顶 16 ⇒ **同屏全景点数 8 → 5**（5×3=15）。
  *         单全景 RT 显存 170MB → **288MB**（含 mipmap ≈384MB）。旧存档 32 条地址**不兼容**，「有异常我会重传」。
+ *   ⑤ 2026-10-26（需求，逐字）：「目前的 全景球是 9片瓦片图的方案, 我想要换成6*3 的18片的方案呢, 就像之前一样的
+ *      方案一样 一个全景是 2个RT 每个 RT上面是 4*4 的方案, 现在我想要改成 2个RT 每个RT 上面 3*3=9 的方案」
+ *      ⇒ 改 **6×3=18 片 / 左右 2 槽**，每槽 = 原图半幅（横 3 格 × 竖 3 格）= **6144×6144**、与原图 1:1。
+ *      ⭐ 净效果：单全景有效分辨率与显存**一字未动**（仍是 75.5Mpx / ≈384MB），sampler = 点数 × 2 ⇒
+ *         **同屏全景点数 5 → 8**（8×2=16 正好用满硬顶）。旧存档 9 条地址**不兼容**，用户重传即可。
  *
  * ⚠️ **仍然有 canvas，但只在上传切图那一步**（`src/views/MktMeshEdit/panoramaUpload.ts` 用 2D 画布把原图
- *    切成 9 个 JPEG 传 OSS）—— 那是**离线、一次性、产出的是数据**；运行时这条路上一个 canvas 都没有。
+ *    切成 18 个 JPEG 传 OSS）—— 那是**离线、一次性、产出的是数据**；运行时这条路上一个 canvas 都没有。
  *
  * ── 每帧的三道工序（旨②那两句话逐条落地，顺序固定）────────────────────────────────
  *   1. `_pumpDownloads()`：补发缺图的下载（每帧 ≤2 张、在册 ≤8、已解码待上传 ≤8）⇒ ⛔ 一批几十条 XHR 一起炸。
@@ -35,49 +40,49 @@
  *      到 GPU 里面去」）。这一趟**只上传、不画** ⇒ 上传与绘制永不落在同一拍（09-29 那句「两个大头别在同一
  *      帧」的延续），而且第 2 步天然只能画「上一帧及更早」传上去的图 ⇒ 每帧 = 1 上传 + 1 绘制（稳态）。
  *
- * ⚠️ 于是「一帧一片」的帧数随网格走：16 片 → 32 片（30ms/帧 ⇒ 全量到位约 1.0s）→ **9 片/组 = 9 帧**（约 0.27s，
- *    10-23 旨）。每格像素 = `RT_STITCH_SLOT_W/1 × RT_STITCH_SLOT_H/3` = **4096×2048**（原图切出来那片多大就多大，一比一）。
- *    且因为下面那条「先喂 shader」的旨意，第一格画完墙上就有东西了，不必等 9 帧。
+ * ⚠️ 于是「一帧一片」的帧数随网格走：16 片 → 32 片 → 9 片 → **18 片/组 = 18 帧**（30ms/帧 ⇒ 约 0.55s，
+ *    10-26 需求）。每格像素 = `RT_STITCH_SLOT_W/3 × RT_STITCH_SLOT_H/3` = **2048×2048**（原图切出来那片多大就多大，一比一）。
+ *    且因为下面那条「先喂 shader」的旨意，第一格画完墙上就有东西了，不必等 18 帧。
  *
  * ⭐ 部分就绪就先喂（同日旨「1. 需要先喂给 shader」）：`peek()` 不再等一个槽的 `cellsPerSlot` 格画满，
  *   **画过 ≥1 格就交出去**。为了保证交出去的那张 RT 里绝无未定义像素，RT 建好后的第一件事是
  *   整张涂成缺失灰（`_clearRt`）⇒ 观感 = 该象限从左上角起逐格显影，缺数据的格子一直是灰的。
  *
  * ── 画质四条（⛔ 改任何一条都是改画质，先请旨）──────────────────────────────
- *  1. **尺寸 / 格子几何**：槽 `RT_STITCH_SLOT_W/H` = **4096×6144**、每槽「横 1 格 × 竖 3 格」、原图**横 3 × 竖 3** 片，
+ *  1. **尺寸 / 格子几何**：槽 `RT_STITCH_SLOT_W/H` = **6144×6144**、每槽「横 3 格 × 竖 3 格」、原图**横 6 × 竖 3** 片，
  *     全在 `./mktShader`（单一来源）。⭐ 10-23 旨后格子尺寸 = 那片瓦片的尺寸 ⇒ **一比一**：11968×5984 那类原图
- *     切 3×3 得 ~3989×1994 的片，铺进 4096×2048 的格子几乎不缩（缩放比 0.97，上一版 8×4 是 1.46 = 缩小）
+ *     切 6×3 得 ~1995×1995 的片，铺进 2048×2048 的格子几乎不缩（缩放比 1.03，与上一版同一档）
  *     ⇒ 单全景有效分辨率 33.5Mpx → **75.5Mpx**，是**升**画质，与「千万不要降低质量」红线同向。
- *     ⛔ 不许把槽改回 4096² 正方形：那是上一版「每槽覆盖横 180°×竖 180°」的产物；现口径每槽只覆盖**横 120° × 竖 180°**，
- *     宽高比 2:3 必须与「原图一整列」一致，否则格子被强行拉伸 = 几何挤歪。
+ *     ⛔ 不许拿槽尺寸当省显存的旋钮：现口径每槽覆盖**横 180° × 竖 180°**（原图左/右半幅），
+ *     宽高比 1:1 与「半幅（3 列 × 3 行）」一致；上一版一槽装一整列时是 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`：10-23 旨后一片原图（~3989×1994）铺进 4096×2048
+ *     ① 瓦片纹理 `generateMipmaps` + `LinearMipmapLinearFilter`：一片原图（~1995×1995）铺进 2048×2048
  *        的格子是**一比一**，但墙面在远处仍会缩到格子以下 ⇒ ⛔ 单点双线性会采出锯齿，mipmap 照旧开
  *        （WebGL2 对 NPOT 也能生成 mipmap，three r163 起只支持 WebGL2）。
  *     ② 槽 RT 标 `generateMipmaps`：three 每次渲染进 RT 后自己 `glGenerateMipmap`（`WebGLRenderer.js`
  *        `updateRenderTargetMipmap`）⇒ 与当年 CanvasTexture 上传后生成 mipmap 同一口径。
  *        ⚠️ 代价：每格一次（旧版每格也是一次），都在 GPU 上、不占主线程。
- *  4. **接缝**：槽内「横 1 × 竖 3」⇒ 一张槽内部的格子线是 **2 横 0 竖**（上一版 4096² 是 3 横 3 竖）；
- *     槽与槽之间另有 u=1/3、u=2/3 两道**跨纹理**竖缝，那道治不了（见 `PanoTexMode` 说明②）。治法 = 上传时每片向四边**多切**
+ *  4. **接缝**：槽内「横 3 × 竖 3」⇒ 一张槽内部的格子线是 **2 横 2 竖**（上一版一槽一整列时只有 2 横 0 竖）；
+ *     槽与槽之间另有 u=1/2 **一道**跨纹理竖缝，那道治不了（见 `PanoTexMode` 说明②；上一版是两道）。治法 = 上传时每片向四边**多切**
  *     `RT_STITCH_SEAM_MARGIN_PX` 像素、拼合时**只采中间那块**（`uSrcRect`）⇒ 边界插值拿得到真邻居像素，
  *     不再复制自己的边缘。⛔ 这条不许「顺手简化」成直接铺满格子：几何会挤歪，缝也还在。
  *     详见 `./mktShader` 里那三个 `rtStitch*` 纯函数 —— **上传侧与拼合侧必须共用同一份几何**。
  *
- * 资源账（⚠️ 如实记；10-23 旨改 3×3=9 片 / 按列 3 槽 / 4096×6144 后重算）：
- *   - 常驻显存：3 槽 × (4096×**6144**×4B + mipmap≈33%) ≈ **384MB/全景**（不含 mipmap 288MB）
- *     —— 上一版 2 槽 4096² 是 **170MB/全景** ⇒ 单全景变成 **2.26 倍**，代价来自「槽与原图一比一」那次**升分辨率**，
+ * 资源账（⚠️ 如实记；10-26 需求改 6×3=18 片 / 左右 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）。同屏景点数虽收到 5，
- *     那只省 sampler 绑定、**不省显存**。⚠️ 这是本轮最大的风险项，已另记待皇上裁决（见「RT 不回收」）。
- *   - 上传总量：同一张原图切完 ⇒ **总像素与 32 片那版逐字节同量**，只是片数 32 → 9、单片边长 ~2.7 倍
- *     ⇒ 下载发起数减 72%、单请求变大。
+ *     ⚠️ 组**运行中不淘汰**（见文末那条需求）⇒ 13 张全景全常驻 ≈ **4.9GB**（上一版 2.2GB）。同屏景点数虽回到 8，
+ *     那只省 sampler 绑定、**不省显存**。⚠️ 这是这一轮最大的风险项，已另记待用户裁决（见「RT 不回收」）。
+ *   - 上传总量：同一张原图切完 ⇒ **总像素与上一版逐字节同量**，片数 9 → 18、每片 4096×2048 → 2048×2048（单片像素减半）
+ *     ⇒ 下载发起数比 9 片那版**翻倍**（仍比 32 片那版少 14 条）、单请求变小。
  *   - 瓦片纹理画完即弃 ⇒ 同时在册的只有「下载中 + 已解码待上传」那些，上限 8+8 片；
- *     ⚠️ 每片解码位图 4096×2048×4B = **32MB**（上一版每片 8.5MB）⇒ 峰值 CPU 侧 ≈ **512MB**（原 ~136MB）。
+ *     ⚠️ 每片解码位图 2048×2048×4B = **16MB**（上一版每片 4096×2048 = 32MB）⇒ 峰值 CPU 侧 ≈ **256MB**（原 512MB）。
  *
  * ⚠️ RT 是 GL 上下文私有资源：`pump(renderer)` 换 renderer 时整组作废（`_switchRenderer`），下一帧消费方
  *   照旧的 `ensure()` 重建（瓦片走浏览器 HTTP 缓存重新下载）。现况是**每个持有者一份拼合器 + 一个 renderer**
@@ -130,7 +135,7 @@ import {
  */
 const PANO_STITCH_UPLOADS_PER_FRAME = 1;
 
-/** 每帧最多发起几张下载（10-23 起一批 9 片，⛔ 不加以限制就是一帧甩 9 条 XHR + 9 次 800 万像素解码） */
+/** 每帧最多发起几张下载（现行一批 18 片，⛔ 不加以限制就是一帧甩 18 条 XHR + 18 次 400 万像素解码） */
 const PANO_STITCH_DOWNLOADS_PER_FRAME = 2;
 
 /** 「下载中」的片数上限（跨所有批次） */
@@ -223,7 +228,7 @@ interface StitchGroup {
  */
 export interface PanoStitcher {
     /** 确保批次已在册并发起瓦片加载（幂等；同批已在册 ⇒ 什么都不做）。
-     *  新增可选 `layout` 参数：缺省 = PANO_TILE_LAYOUT（全景 3×3 / 3 槽 / 4096×6144，10-23 旨）；
+     *  新增可选 `layout` 参数：缺省 = PANO_TILE_LAYOUT（全景 6×3 / 2 槽 / 6144×6144，10-26 需求）；
      *  图片平面传 `imageTileLayout(natW, natH)`（2×2 / 1 槽 / RT 宽高比=原图）。 */
     ensure(urls: string[], layout?: TileLayout): void;
     /**
@@ -305,11 +310,11 @@ private _uploadQueued: Set<TileRec> = new Set();
     }
 
     /** 确保批次已建组、加载已发起。幂等：同批已在册 ⇒ 直接返回（一片瓦片终身只下载、只解码一次）。
-     *  ⭐ 09-29 晚旨「不足的涂灰」+ 10-23 旨「3×3 = 9 片」：1~9 条皆可入组，内部补空串占位到 9；
+     *  ⭐ 09-29「不足的涂灰」+ 10-26「6×3 = 18 片」：1~18 条皆可入组，内部补空串占位到 18；
      *  空串 / 死链的格子拼合时涂灰（一眼看出该全景数据不全）。
-     *  ⛔ 旧版 16 条（4×4）、32 条（8×4）与 64 条（8×8）的数据**都不做兼容**（皇上「无须兼容正常使用, 有异常我会重传」）：
-     *  超 9 条会在上一行被判超限直接丢弃；真喂进来的短数据只占前几格 + 其余涂灰，那是**故意**让数据不全看得见。
-     *  ⚠️ 每槽数组长度由 `RT_STITCH_SLOT_COUNT` 派生（⛔ 不许手写 `[null,null,null]` —— 槽数再变会漏改）。 */
+     *  ⛔ 旧版 16 条（4×4）、32 条（8×4）、64 条（8×8）与 9 条（3×3）的数据**都不做兼容**（用户「无须兼容正常使用, 有异常我会重传」）：
+     *  超 18 条会在上一行被判超限直接丢弃；真喂进来的短数据只占前几格 + 其余涂灰，那是**故意**让数据不全看得见。
+     *  ⚠️ 每槽数组长度由 `RT_STITCH_SLOT_COUNT` 派生（⛔ 不许手写 `[null,null]` —— 槽数再变会漏改）。 */
     ensure(urls: string[], layout?: TileLayout): void {
         const L = layout ?? PANO_TILE_LAYOUT;
         const maxTiles = tilesPerBatchOf(L);
@@ -528,14 +533,14 @@ private _uploadQueued: Set<TileRec> = new Set();
     // ───────────────────────── 内部：单格绘制 ─────────────────────────
 
     /** 画一格：把那片瓦片的**中间那块**铺进该槽第 `cell` 格（每槽 `slotCellCols × slotCellRows` 格里的一格，
-     *  10-23 旨后全景是「横 1 × 竖 3」= 3 格、图片平面是 2×2 = 4 格）。
+     *  10-26 起全景是「横 3 × 竖 3」= 9 格、图片平面是 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-23 旨一槽 = 原图一整列 ⇒ 1 横 3 竖
+        // ⚠️ 横竖**分轴**缩放/摆位（旧的单一 `slotGrid` 方形假设整条作废）：10-26 起全景一槽 = 原图半幅 ⇒ 3 横 3 竖，图片平面那档 2 横 2 竖
         const cw = g.layout.slotCellCols;
         const ch = g.layout.slotCellRows;
         this._quad.scale.set(1 / cw, 1 / ch, 1);
@@ -654,7 +659,7 @@ private _uploadQueued: Set<TileRec> = new Set();
         this._dead.clear();
     }
 
-    /** 懒建某槽的渲染目标：尺寸取自 `g.layout.rtW/rtH`（全景档 = **4096×6144**，10-23 旨）、RGBA8 + sRGB + mipmap，
+    /** 懒建某槽的渲染目标：尺寸取自 `g.layout.rtW/rtH`（全景档 = **6144×6144**，10-26 需求）、RGBA8 + sRGB + mipmap，
      *  并**立刻整张涂缺失灰**（⛔ 未定义像素不许进 shader：`peek()` 现在画过 1 格就交出去）。
      *  ⚠️ 6144 这个数受本机 `MAX_TEXTURE_SIZE` / 最大渲染目标尺寸约束（ANGLE/D3D11 的 11_0 是 16384，远超；
      *     只有老 Intel 集显才可能卡 4096 —— 真建不出来 three 会报 `GL_INVALID_VALUE`，届时墙上整片缺失灰）。 */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "three-base",
-  "version": "2.0.181",
+  "version": "2.0.187",
   "description": "A Three.js extension library providing common 3D components, animations, materials, and utilities",
   "author": "xiaosihan",
   "publishConfig": {