一句话结论：法线贴图生成器只有两个真正需要你决定的参数——强度和绿色通道方向。其余（算法、模糊、是否 16 位）都有默认值可循。本文把这两个参数量化出来：强度 1 到 100 对应多大的倾斜角，绿通道反了会有多大差别。

一、先说原理（一行公式）

法线贴图不改变几何，只改写"这个像素朝哪边"。核心公式：

n = normalize( -dx·strength, -dy·strength, 1 )
RGB = n * 0.5 + 0.5

• dx / dy 是高度图在水平/垂直方向的梯度（相邻像素的高度差）；
• 平地上梯度为 0 → n = (0,0,1) → RGB = (127.5, 127.5, 255)，这就是法线贴图那种淡蓝紫色；
• 越陡的地方，R/G 越偏离 127，B 越暗。

所以"强度"实际是梯度的倍数：强度越大，同一个高度差被解释得越陡。

二、强度到底该调到几（实测）

1,024×1,024 高度图（一个球顶 + 一个 45° 台阶 + 一个方块凸起），用 Sobel 卷积生成：

怎么读这张表：

• 强度 1 ≈ 没效果。最大倾斜才 14°，肉眼几乎看不出凹凸——很多人以为"工具坏了"，其实只是强度太低。
• 强度 20 是多数场景的甜点（78°），既有明显立体感又不至于像塑料。
• 强度 100 已经接近饱和（83°，RGB 打到 0/254 的边界），细节会被削平、边缘出现硬边。
• 耗时都在 0.15 秒级（1,024²，单线程 CPU）。所以"在线生成要等很久"通常是上传/下载图片，不是算法。

经验值：贴图尺寸 512² 用 10–20；1,024² 用 15–25；2,048² 用 25–40。凹凸越细（布料、木纹）强度越低，越粗（砖墙、浮雕）强度越高。

三、Sobel 还是 Scharr

肉眼差别极小，方向性细节（斜 45° 的边缘）用 Scharr 更平滑一点。所以：没有特别理由就用默认的 Sobel，Scharr 是"斜边特别多"时的微调项，不是升级版。

四、最隐蔽的坑：绿色通道（OpenGL vs DirectX）

法线贴图的 G 通道有两种约定：

实测：同一张图把 G 通道翻转，最大像素差 248/255、平均差 2.4。平均差很小意味着——大部分像素看起来一样，只有曲面的受光方向整体反了。所以这类问题极少被当成"贴图错了"，通常被误判为"灯光没打好"。

判断方法：找一个明显的凸起，光从左上来时，左侧应该亮。如果左侧变暗、右侧亮，就是绿通道反了。修法：生成器里勾/去掉"翻转 Y / DirectX 模式"，或在 Photoshop 里反相 G 通道。

五、五个常见翻车点

① 高度图是 8 位、且有大面积平滑渐变。8 位只有 256 级，缓坡上会出现阶梯状波纹。修法：模糊高度图（1–2 px）再生成，或用 16 位高度图。

② 把法线贴图当凹凸/位移贴图用。- 凹凸贴图（bump）：灰度，只影响光照，最简单； - 法线贴图（normal）：RGB，能表达方向，性能好、效果比 bump 强； - 位移贴图（displacement）：真的改几何，最贵最真实。 需要"轮廓也变"就必须用位移，法线永远改不了轮廓。

③ 尺寸不是 2 的幂。1,000×1,000 的贴图在 GPU 上会被重采样，"看起来糊"多半是这个原因。用 512/1024/2048。

④ 当成 sRGB 图片存/读。法线贴图存的是方向，不是颜色。被当作 sRGB 做颜色管理后，方向会整体偏移。引擎里的导入设置要选 "Normal map"（Linear）。

⑤ 只做了一张贴图，却忘了平铺（tiling）。 砖墙、布料这类重复材质，边缘必须无缝；否则贴到模型上会出现一条明显的接缝。做法：生成前把高度图做成无缝（偏移 50% 再修补）。

六、在线生成的实际流程（BimAnt）

1. 打开 高度图转法线贴图，拖入灰度高度图（PNG / JPG / TGA 都行）；
2. 先把强度拉到 20 左右看效果，再按细节微调（参考上面的表）；
3. 需要判断绿通道方向：勾/取消"翻转 Y"，看凸起受光是否左右一致；
4. 导出 PNG（要 PBR 流程的话可同时导出 AO / 位移贴图）；
5. 把贴图贴到模型上看真实效果——3D 模型在线查看 可以直接预览带贴图的模型。

有现成照片（而不是高度图）时，用 照片生成法线贴图：四张不同光照方向的照片反解出法线，适合实物表面。

常见问题

Q：法线贴图和置换贴图能混用吗？能，而且常见：法线贴图管细节光照，位移贴图管大轮廓。注意位移需要足够细分的网格。

Q：为什么我的法线贴图偏紫/偏绿？偏紫是正常的（(127,127,255)）；偏绿说明 B 通道被压太低，通常是强度过大或高度图本身对比过强。

Q：生成的贴图能商用吗？可以。贴图由你的高度图生成，本站不上传服务器、不保留文件；请自行确认高度图本身的版权。

Q：强度调大就"更真实"吗？不是。真实感来自凹凸与材质尺度匹配：1 米宽的墙用 20 合适，10 厘米的按键用 20 就过了。先确定贴图在模型上的实际覆盖尺寸，再调强度。

Q：批量处理几十张高度图？用 法线贴图批量生成，一次拖入多张，按同一套参数导出。

实测说明：1,024×1024 高度图（球顶 + 45° 台阶 + 方块），Sobel/Scharr 3×3 卷积（symm 边界），单线程 CPU；强度扫描与 G 通道翻转对照在 Python 3.10 + numpy/scipy 下完成；输出 PNG 体积：高度图 24,127 字节 → 法线图 46,166 字节。数字均为 2026-10-25 本地实测。

相关阅读：SculptGL 在线三维雕刻 ｜ 3D 模型在线查看工具 ｜ 3D 逆向工程实战 ｜ 3D 格式与在线查看完全指南

本文由 BimAnt 整理，含本地实测数据，转载请注明出处。最后更新：2026-10-25

查看专题全部文章 →

按格式打开：高度图转法线贴图在线 ｜ 照片生成法线贴图 ｜ 法线贴图批量生成（浏览器直接打开，不上传服务器）

一句话结论：.gltf 不是"模型文件"，而是一张清单 + 几个同目录的零件。几何在 .bin，贴图在 .png/.jpg，.gltf 里只有文字描述。所以：搬文件要整目录搬；双击打开一定要有本地 HTTP 服务。

一、三种打开方式

别双击 .gltf：Chrome/Edge 会用文本方式显示 JSON，或者报 Failed to fetch——这不是文件坏了，是浏览器的安全策略不允许从 file:// 读旁边的 .bin。

二、结构实测：一句话就能看懂

官方样本 BoxTextured.gltf（同一模型也有 GLB 版本）：

{
  "asset": { "version": "2.0", "generator": "COLLADA2GLTF" },
  "buffers": [ { "uri": "BoxTextured0.bin", "byteLength": 840 } ],
  "images":  [ { "uri": "CesiumLogoFlat.png" } ]
}

accessor 里的 min/max 是 glTF 的独特优势：不用解析二进制就能知道包围盒。写校验脚本时，读 JSON 就够了。

三、打不开的五类原因

① 只拷了 .gltf，没拷 .bin / 贴图。实测报错信息非常友好：

FileNotFoundError: ... only-gltf\BoxTextured0.bin

报错里点名的文件，就是缺的那个。按报错补文件，别急着重下模型。

② 用 file:// 打开，浏览器拦截。Failed to fetch / CORS policy 是同一个原因。解决：在目录里跑一个静态服务

cd 模型所在目录
python -m http.server 8000
# 浏览器打开 http://localhost:8000/xxx.gltf

③ 路径大小写 / 中文名 / 空格。JSON 里的 uri 是大小写敏感的字符串。服务器（Linux）与本地（Windows）不一致时，本地能开、上传就 404。中文名还会遇到 URL 编码问题。

④ 缺扩展支持。看 extensionsRequired：KHR_draco_mesh_compression、KHR_meshopt_compression、KHR_texture_basisu —— 列表非空就必须用支持它的加载器，否则加载器会直接拒绝而不是显示灰模。

⑤ 单位与朝向被忽略。glTF 规范：米、Y-up、右手系。但导出器经常写 nodes[].scale 或根节点旋转来"凑"尺寸。所以查看器里看到的尺寸是对的、进引擎后却变形 —— 这时要看 nodes 的 matrix/scale/rotation，而不是 accessor 的 min/max。

四、在线打开的实际流程（BimAnt）

1. 打开 glTF 在线查看，把 .gltf 和同目录的 .bin、贴图一起选中/拖入；
2. 先看贴图是否正常（灰模 = 贴图没带上或 uri 路径不对）；
3. 再看包围盒：对照 accessor.min/max 与你要的尺寸，能立刻发现单位错；
4. 需要更严格的检查（缺失资源、非法索引、扩展声明）用 glTF Viewer 的验证报告。

五、.gltf 还是 .glb

体积优化同理：.gltf 的优化手段与 GLB 一致（减面、合并材质、压缩纹理），见 3D 模型在线轻量化。

常见问题

Q：为什么我的 .gltf 只有几 KB？因为它是清单。模型本体在 .bin 里，贴图在旁边的图片文件里。

Q：能不能把 .gltf 变成一个文件？两种做法：① 导出成 .glb；② 把资源改成 base64 的 data: URI 写回 JSON（体积会变成 GLB 的 1.4 倍左右）。

Q：.gltf 里有动画吗？可以有，animations 数组。动画数据一般也在 .bin 里。

Q：报 "Unexpected token" 是什么问题？说明你把 GLB 当 .gltf 打开了（GLB 开头是 glTF 二进制头）。改名回去用 GLB 打开即可。

Q：线上的 .gltf 为什么能直接打开，本地的不能？线上是 HTTP 服务，浏览器允许加载同源资源；本地 file:// 不允许。这就是必须起本地服务的原因。

样本与复现：Khronos glTF-Sample-Assets/Models/BoxTextured/glTF（3 件套）；缺失文件、base64 自包含、GLB 体积对照均在 Python 3.10 下实测。数字均为 2026-10-25。

相关阅读：glTF / GLB 尺寸朝向校验与体积优化 ｜ 3D 模型在线查看工具 ｜ 3D 模型在线轻量化 ｜ 3D 格式与在线查看完全指南

本文由 BimAnt 整理，含本地实测数据，转载请注明出处。最后更新：2026-10-25

查看专题全部文章 →

按格式打开：glTF 文件怎么打开 ｜ GLB 在线查看（浏览器直接打开，不上传服务器）

一句话结论：FBX 不是"带材质的 STL"，它是 Autodesk 的私有工程格式——骨骼、蒙皮、动画、材质、贴图路径、单位、坐标系全塞在里面，而且读取要靠官方 SDK。所以你遇到的"打不开"，通常是 ① 用错了工具 ② 版本太新 ③ 里面是 NURBS/细分体而不是多边形 ④ 贴图根本没打进文件。

一、四种打开方式，按成功率排

Python 脚本批量处理是最容易踩坑的一条：我实测 trimesh 4.0.5 读 FBX，直接返回 ValueError: File type: fbx not supported。原因是 FBX 没有开放规范的解析器，要么装 Autodesk FBX SDK，要么用 Assimp 编译带 FBX 的版本。"几行 Python 读所有 3D 格式"在 FBX 这里不成立。

二、文件里到底有什么（实测）

拿 three.js 官方示例 Samba Dancing.fbx（3.7MB）做二进制解剖：

三点解读：

1. 头 21 字节是二分法：以 Kaydara FBX Binary  \x00 开头是二进制；以 ; FBX 7.x.0 project file 开头的是 ASCII FBX（文本，能直接打开看节点树）。
2. 版本号是兼容性的第一道门：7400 是 7.4，7700 是 2020。老软件的导入器遇到新版本常直接失败或丢动画。
3. 有动画不等于有贴图：这个文件带 AnimStack 和 Deformer，但没有 Video 节点 —— 贴图是外部路径引用，拷给别人必然丢。

三、打不开的五类原因

① 工具本身不支持 FBX。先确认：你的工具是"网格库"还是"DCC/引擎"。网格库（trimesh、部分在线转换器）通常不解析 FBX 的骨骼与动画。

② 版本太新。FBX 版本不向下兼容。判定方法：读偏移 23 起的 4 字节 uint32 —— 7400（7.4，Blender/Maya 默认常见）、7500（7.5）、7700（2020）。导入方支持的最高版本低于它，就会失败或丢动画。

③ 里面不是多边形。FBX 可以装 NURBS 曲面、细分体（Subdiv）、甚至摄像机灯光。打开只看到空场景或几个空物体，多半是这个原因——需要在导出时"转换为多边形网格（Convert to Polygon Mesh）"。

④ 贴图是绝对路径。Video 节点里存的是 D 盘路径，换机器必然灰模。正确做法：导出时勾选 Embed Media（嵌入媒体）或统一用相对路径并整目录拷贝。

⑤ 单位与坐标系不对。FBX 默认单位是厘米、向上轴是 Y。很多导出的"模型变成 100 倍大/躺着"，就是 cm↔m 与 Z-up↔Y-up 换算没做。

四、在线打开的实际流程（BimAnt）

1. 打开 FBX 在线预览，拖入 .fbx；
2. 先确认是不是"能看"：能看到网格 + 材质说明文件完整；只有网格没材质 = 贴图外链（原因 ④）；
3. 再看动画：有动画的 FBX 一般能播放第一个 take；如果你需要特定 take，还是在 Blender/引擎里选；
4. 最后看尺寸与朝向：显示值对不对，决定你要不要在导出端改单位。

如果模型是扫描件、雕刻件导出成 FBX，通常还会遇到面数过高：先用 3D 模型在线轻量化 减面，再回来看是否还有问题。

五、FBX / GLB / OBJ 怎么选

一句话：FBX 走"编辑与动画管线"，GLB 走"交付与展示"，STL 走"打印"。

常见问题

Q：FBX 能转成 STL 吗？能，但只保留几何（三角面），材质、动画、骨骼全丢。做 3D 打印时这是正常操作。

Q：为什么 Blender 导入 FBX 后模型特别大/特别小？导入面板的 Scale 默认 1.0，而 FBX 内部单位是 cm。导入后按 0.01 缩放、或导入时手动改 Scale，就能对齐。

Q：FBX 文件能不能直接嵌贴图？能，导出时选 Embed Media。代价是文件变大；好处是单文件交付不会丢图。

Q：在线查看器打不开某些 FBX，是网站的问题吗？多数是版本或扩展（NURBS、自定义插件数据）。先在 Autodesk FBX Review 里试一次，能开就是查看器版本问题，不能开就是文件问题。

Q：为什么"FBX 比 STL 难十倍"这个说法成立？STL 只有三角面列表，格式只有几十行；FBX 是带节点树、属性、动画曲线的私有二进制，要正确处理必须实现 SDK 的语义。难的不是"读字节"，是"还原语义"。

样本与复现：three.js 官方示例 Samba Dancing.fbx（3,681,360 字节，FBX 7.4）；头部与版本用 Python 3.10 + struct 直接读偏移 0/21/23；AnimStack/Deformer/Video 用字节串检索确认；trimesh 4.0.5 的 FBX 支持情况为实测。数字均为 2026-10-25。

相关阅读：3D 模型在线查看工具 ｜ SculptGL 在线三维雕刻 ｜ glTF / GLB 尺寸朝向校验 ｜ 3D 格式与在线查看完全指南

本文由 BimAnt 整理，含本地实测数据，转载请注明出处。最后更新：2026-10-25

查看专题全部文章 →

按格式打开：FBX 在线预览 ｜ GLB 在线查看 ｜ STL 在线查看（浏览器直接打开，不上传服务器）

一句话结论：GLB 就是一个 ZIP 式思路的"单文件 3D"——JSON 描述 + 二进制数据 + 贴图，全在一个盒子里。所以它天然不会出现"打开是灰模、贴图丢了"，那类问题属于 .gltf（外部引用）。反过来说，你打不开 GLB，通常只有两个原因：后缀被改过，或者版本/扩展不支持。

一、先给结论：三种打开方式

二、GLB 的结构：12 字节头 + 若干分块

对 Khronos 官方示例 BoxTextured.glb 做二进制解剖：

注意那个 24 顶点：同样 12 个三角面，STL 要存 36 个顶点，GLB 只存 24 个（8 个角 × 3 个法线方向）。索引复用是 GLB 更小的第一个原因，贴图编码是第二个。

三种"同一个模型"的体积对照

结论很直接：要单文件，就用 GLB；要人能读、要 diff、要手改，才用 .gltf。

三、打不开的两类原因（其余都很罕见）

① 后缀被改过：xxx.glb 其实是 .gltf，或反过来。实测：把 BoxTextured.glb 改名成 .gltf，再按 JSON 解析 → UnicodeDecodeError。因为文件开头是 glTF 二进制头（67 6C 54 46），不是 {。

一行判定：

head = open(path,'rb').read(4)
is_glb  = head == b'glTF'
is_gltf = head.lstrip().startswith(b'{')

② 版本或扩展不支持。GLB 头部第 2 个 4 字节是版本号，只见过 2（glTF 1.0 的 GLB 极少）。真正会卡住你的是 extensionsRequired 里的扩展：Draco 压缩（KHR_draco_mesh_compression）、meshopt、Basis 纹理（KHR_texture_basisu）。老的/精简的查看器遇到"必需扩展"会直接拒绝加载，而不是显示灰模。

判定：把 GLB 的 JSON 分块读出来看 extensionsRequired（有内容就必须用支持它的加载器）。

顺带说一个反常识的点：GLB 里也能放外部文件。规范允许 image.uri 指向外部贴图，只是导出器默认内嵌。所以"GLB 一定不会丢贴图"这句话要加个"通常"。

四、在线打开的实际流程（BimAnt）

1. 打开 GLB 在线查看，拖入 .glb；
2. 看朝向：glTF 规范是 Y 轴向上、右手系、单位米。如果模型躺着，是导出器没按规范写，不是查看器的问题；
3. 看尺寸：显示 0.01 米的汽车模型，就是导出时按 cm 建模却没转换；
4. 看贴图：正常应该直接带纹理。灰模说明该文件确实是"无材质 GLB"（text-to-3D 常见）。

需要更细的结构检查（缺资源、非法索引、扩展声明）可以用 glTF Viewer 2.0 的验证报告。

五、GLB 和相邻格式怎么选

体积太大时，先做几何优化再考虑压缩：见 3D 模型在线轻量化。

常见问题

Q：GLB 和 glTF 是两种格式吗？一种格式、两种封装。.gltf 是 JSON + 外部资源，.glb 是二进制单文件。内容模型完全一致。

Q：为什么 text-to-3D 工具都导出 GLB？因为要"一个文件丢进网页就能显示"。STL 不能带材质，OBJ 要一堆配套文件，FBX 浏览器里基本没法直接读。

Q：GLB 能转回 STL 吗？能，但会丢掉 UV、材质和动画——STL 只有三角面。做 3D 打印时这是正常取舍。

Q：打开 GLB 提示"不支持的扩展"怎么办？先看扩展名：Draco 需要用支持 Draco 的加载器（本站在线查看器按可用扩展处理），或者用 Blender 重新导出为不压缩的 GLB。

Q：GLB 里能塞几个模型？一个文件可以有多 mesh / 多 node / 多个场景。常见是"一个场景多个零件"，不是"一个文件一个模型"。

样本与复现：Khronos glTF-Sample-Assets/Models/BoxTextured（glTF 与 GLB 两种封装）；分块解析用 Python 3.10 + struct + json；体积对照由 base64 内嵌脚本生成。数字均为 2026-10-25 实测。

相关阅读：glTF / GLB 尺寸朝向校验与体积优化 ｜ 3D 模型在线轻量化 ｜ 3D 模型在线查看工具 ｜ 3D 格式与在线查看完全指南

本文由 BimAnt 整理，含本地实测数据，转载请注明出处。最后更新：2026-10-25

查看专题全部文章 →

按格式打开：GLB 在线查看 ｜ glTF 文件怎么打开 ｜ OBJ 文件在线预览（浏览器直接打开，不上传服务器）

一句话结论：STL 是"三角面列表"，不是模型文件——它没有单位、没有颜色、没有索引、没有拓扑。所以你遇到的"打不开"，八成不是文件坏了，而是 ① 拿 ASCII/二进制判错了 ② 尺寸单位猜错了 ③ 想让它带贴图。

下面所有数字都是 2026-10-25 在本地对真实文件实测的（样本与复现命令见文末），不是抄来的。

一、先给结论：三种打开方式

如果你的目的只是"确认这是个什么东西"，第一种就够了，不用装软件。

二、文件里到底有什么（字节级实测）

拿 three.js 仓库里的 pr2_head_pan.stl（PR2 机器人头部云台零件）做解剖，1,000 个三角面：

同一批三角面导成 ASCII 版本：306,160 字节，是二进制的 6.11 倍。这就是为什么网上下载的 STL 大多是二进制——ASCII 只是"能用文本编辑器看"。

一个真实的坑：以 solid 开头 ≠ ASCII

网上流传的判定方法是"看前 5 个字节是不是 solid"。我按这个思路做了个实验：把一个二进制 STL 的 80 字节头改写成 solid made-by-naive-exporter。

前 5 字节 == b'solid'          → True   （朴素判定：ASCII，错了）
(size - 84) % 50 == 0          → True   （二进制，对的）
头里声明的三角面数              → 1000   （二进制，对的）

二进制 STL 的头是任意 80 字节，导出器想写什么都行。正确判定只需要两行：

n = os.path.getsize(path)
is_binary = (n - 84) % 50 == 0 and struct.unpack('<I', open(path,'rb').read(84)[80:84])[0] == (n-84)//50

ASCII 版本则一定以 solid 开头、以 endsolid 结尾，中间是 facet normal / outer loop / vertex 三件套。

三、打不开的五类原因（按发生频率排）

① 文件其实是别的格式，改了后缀冒充 STL。打开是乱码或直接报"unsupported"，第一条永远是查文件头。STL 二进制头没有魔数，所以最可靠的还是 (size−84)%50；ASCII 看 solid/facet。

② 文件被截断（下载中断 / 微信传大文件）。(size−84)%50 ≠ 0 就是铁证。这时候不用找工具，让发件人重传或用压缩包。

③ 单位错了，模型看起来"极小"或"巨大"。STL 不含单位信息。同样是 0.254，按米读是 25 厘米的零件，按毫米读就是 0.25 毫米的粉尘。行业惯例是 mm，但 3D 打印店常收到 inch 导出的件。先问一句导出单位，比在软件里瞎缩放心。

④ 面数太多，浏览器/软件卡死。一个 100 万面的 STL 是 50MB。移动端浏览器超过 20–30 万面就会明显掉帧。这时候要的不是"打开"，而是减面或分块。

⑤ 想要颜色和贴图 —— STL 没有。STL 只存几何。如果你的模型需要材质，正确路线是 转成 3MF（打印）或 GLB/glTF（展示），不是继续折腾 STL。

四、在线打开的实际流程（BimAnt 3D Viewer）

1. 打开 STL 在线查看器，把 .stl 拖进去（不上传服务器，浏览器本地解析）；
2. 先转一圈看朝向：STL 惯例是 Z 轴向上，如果模型躺着，说明导出器按 Y-up 导出；
3. 再看包围盒尺寸——如果显示 0.254，而你期望的是 254 mm，就是单位问题，不是模型问题；
4. 需要分享就截图或用线框模式看拓扑密度。

同一套查看器也支持 OBJ / GLB / glTF / FBX，方便"客户发来三个格式"时对比：3D 模型在线查看。

五、该不该转格式

切割或减面可以先用 STL 在线分割 处理；如果最终目标是"变回可编辑实体"，那是另一门手艺，见 STL 变回可编辑 CAD。

常见问题

Q：手机能打开 STL 吗？能。iOS/Android 的浏览器用在线查看器即可；大文件建议先在电脑上减面。

Q：STL 里为什么一个顶点存了好几遍？因为 STL 是"三角面汤"（triangle soup）：每个三角面独立存 3 个顶点，没有索引表。好处是格式极简、任何软件都能读；坏处是文件大、没有拓扑关系。

Q：二进制 STL 那个 2 字节的"属性"字段是什么？规范里是"属性字节数"，实际被很多导出器用来塞颜色（VisCAM/SolidView 的非标准扩展）。所以你会看到某些 STL 在切片器里有颜色、在另一个软件里变灰。

Q：为什么查看器显示的面数比我以为的少？查看器一般显示的是"三角面数"，而建模软件里显示的是"四边形面数"。一个四边形会被拆成两个三角面，所以数字大约是 2 倍。

Q：STL 能带动画吗？不能。要动画就得换 FBX/GLB，或把动画单独做。

样本与复现：pr2_head_pan.stl（three.js 官方示例，二进制 1,000 面）；ASCII 版本由 trimesh 4.0.5 导出；字节级校验与"solid 头陷阱"在 Python 3.10 + struct 下复现。数字全部为 2026-10-25 本地实测。

相关阅读：3D 模型在线查看工具 ｜ STL 模型在线分割 ｜ STL 变回可编辑 CAD ｜ 3D 格式与在线查看完全指南

本文由 BimAnt 整理，含本地实测数据，转载请注明出处。最后更新：2026-10-25

查看专题全部文章 →

按格式打开：STL 在线查看 ｜ OBJ 文件在线预览 ｜ GLB 在线查看（浏览器直接打开，不上传服务器）

一句话结论：2026 年 10 月，英伟达把自家用了二十多年的 SMLib 几何内核开源了——不是丢一份压缩包，而是连C++/Python API、OpenUSD 读写、三角化、修补、桌面 GUI、示例模型一起放进仓库 NVIDIA-Omniverse/usd-brep，许可 Apache 2.0（可商用嵌入，带明确的专利授权）。对做 CAD/BIM 的人来说，这件事的分量在于："精确几何"这条长期被 Parasolid / ACIS 商业授权把住的路，第一次有了一个能直接拿进产品的开源 B-Rep 内核，而且它天生就说 USD。 但它才刚开源两周多：贡献不接收、12 个未修 issue、几何内核的坑写得比功能还长——现在适合评估与小工具试水，不适合把主力建模链路换过来。

想在浏览器里先看看 B-Rep 与三角网格长什么样的，可以拿一个 在线 CAD 查看器 打开手上的 STEP / IGES 对照着读下文。

披露：本文完整编译英文源文 CloudNavi 2026-10-13《NVIDIA Open-Sources the SMLib CAD Kernel Under Apache 2.0》 的全部要点，并用英伟达官方仓库的 README、CHANGELOG.md、KNOWN_ISSUES.md、proposals/ 两份设计文档逐条核对与补全（数据截至 2026-10-23）。我们没有本地编译源码、没有跑布尔/圆角实测，所有数字与行为都来自官方文档与 release 说明；英伟达与本站在产品上没有任何利益关系。

一、这次开源了什么

把这件事推到台面上的，是做 ClassCAD / Buerligons.IO 的开发者 @0xca0a 在 2026-10-12 发的帖子：「对 CAD 来说是大新闻——英伟达的 NURBS 内核 SMLib 终于开源了」，他说自己和 SMLib 及其团队打交道二十多年，他的 headless CAD、GUI、AI/MCP 与 PDM 产品都建立在它之上。也就是说：内核本身不是新东西，新的是它能被任何人下载、编译、塞进自己的产品里。

二、先分清两层：SMLib 是内核，USD BRep 是"外壳"

这是最容易读错的一点：

• SMLib（source/SMLib）= 几何内核。NURBS 与多边形建模、布尔、圆角、扫掠、偏移、抽壳、特征删除、三角化、几何与拓扑校验（AssertValid）、修补（healer）。英伟达官方把它描述为"一整套 NURBS 与多边形建模工具的全尺度库"，也就是别人可以拿它盖 3D 应用的引擎/内核。再往下是 NLib——由 Wayne Tiller 与 Les Piegl（NURBS 标准参考书《The NURBS Book》的作者）开发的曲线曲面库。
• USD BRep（source/SM_API_USD 等）= 让内核住在 USD 里的那一层。定义 BrepArray prim（schema 名 omniSolid）、SMLib ↔ USD 的导入导出、healer、三角化、Hydra 插件、转换器。

所以"英伟达开源了一个几何内核"和"USD 终于能装精确几何"是同一件事的两面：内核给了能力，schema 给了载体。

顺带补一句价格坐标：CAD 内核长期是商业授权的（西门子 Parasolid、达索 ACIS，开源侧是 OpenCASCADE）。一个原本按源码许可卖的商用内核改成 Apache 2.0，对"想做 headless CAD、桌面 GUI、AI/Agent+MCP 流水线、PDM"的团队来说，就是多了一个可嵌入的底座。

三、为什么 USD 需要 B-Rep：显示几何 vs 精确几何

仓库里 proposals/cad_geometry/README.md 是 AOUSD（Alliance for OpenUSD）几何工作组的问题陈述（v0.1 DRAFT，2026），开篇一句就能解释整件事：

USD has no mechanism for representing mathematically exact geometry.（USD 没有任何表示数学上精确几何的机制。）

网格是近似，细分曲面是近似，NURBS patch 最接近但裁剪支持有限、没有拓扑连通性、控制点还是单精度，解析体只覆盖少数几种标准形状。而工业界交换精确几何的主流表示是 B-Rep：用边界曲面、边、顶点加上显式拓扑关系描述一个实体。

两份文档里最值得 BIM 从业者读的，是两个 hero 场景：

场景 1：厂区/工地规划里的测量与碰撞检测。 规划方把几十个来源的几何塞进一个 USD stage——设备供应商只给三角化网格，拿不到原始 CAD。于是两个问题必然出现：

• 测量不可靠：机器人底座与其安装面的间隙、螺栓孔的中心距、风管与结构梁的净距——三角化几何没有参数化身份：圆柱没有轴、孔没有标称直径，任何测量的精度都被三角化容差卡死，而这个容差不是你选的、你可能也不知道。
• 碰撞模棱两可：当测出的距离正好落在三角化容差的量级上，就分不清是真相交还是网格假象。工作组用例文档的原话是："如果两物体间的测量距离与三角化所用容差同一量级，那么排除碰撞是不安全的。" 想解决这种"软碰撞"，要么把网格重划到离谱的密度，要么换成精确几何要一个确定性答案。

场景 2：数据质量由消费方决定，而不是导出方。 今天谁导出 USD，谁就一次性决定了三角化密度，下游全盘接收。但可视化只想砍掉螺纹小孔、结构工程师要边界层加密的 FEA 网格、工艺规划要精确参数曲面出刀路——三个消费者要三种表示。有 B-Rep 在 stage 里，各自派生各自的表示即可，不改源、也不用回去找原作者。

此外还有 AECO 的参考模型交换（不同公司之间交换建筑/基础设施模型，精确几何才能保住跨交换边界的尺寸精度）、制造侧的装配约束与 PMI（螺纹孔以"圆柱 + PMI 元数据"存储，精确几何能重建螺纹）、机器人侧的仿真预处理（FEA/CFD/多体动力学各自从精确边界划分网格），以及线框与 IP 保护（B-Rep 的边本身就是一等实体，剥掉解析曲面只留线框是常见的对外交付第一步）。

四、仓库里到底有什么

README 把内容分成三块，都能直接拿来用：

两点值得单独说：

1. 测试模型是 STEP / IGES / JT 格式、走 Git LFS——说明它真的拿别的 CAD 系统的数据在做回归，而不是自产自销。
2. 仓库自带"给编码 Agent 的说明书"。一个几何内核把错误码解释、操作指南、调试 skill 写进仓库给 Agent 读，是 2026 年的新常态：内核不只要对人友好，还要对 Agent 友好。这个方向的另一面就是 cldnavi 记录的演示视频第二幕——用自然语言让 Agent 驱动内核加约束，直到状态变成 SOLVED。

五、上手：三条路径

A. 最省事：PyPI + 五行代码

pip install usd-brep        # CPython 3.12；Linux x86_64/aarch64、Windows

import usd_brep

sphere = usd_brep.primitives.create_sphere((0.0, 0.0, 0.0), 1.0)
box    = usd_brep.primitives.create_box((0.0, 0.0, 0.0), 1.0, 1.0, 1.0)
cut    = usd_brep.booleans.boolean_difference(sphere, box)   # 球缺一个卦限

usd_brep.usd.export_brep(cut, "cut.usda")
(brep,) = usd_brep.usd.import_breps("cut.usda")

B. 修一个别人给的 USD 场景（这是最实用的入口）：

import usd_brep
usd_brep.usd.heal_file("input.usdc", "input_healed.usdc")

heal_file 会修补场景所用图层里的 BrepArray 几何，并保留图层、引用、原生实例化、变换与材质写出——也就是说它不会把你辛苦搭的 USD 组合结构拍平。

C. 自己编译 + 桌面 GUI

# Linux / macOS
./prebuild.sh && ./repo.sh build     # macOS Apple Silicon 加 -p macos-universal
# Windows
prebuild.bat && repo.bat build
./repo.sh test && ./repo.sh format

# 桌面 GUI（走 uv）
uv run --locked --group gui python tools/scripts/smlib_gui.py           # 默认 Debug
uv run --locked --group gui python tools/scripts/smlib_gui.py --release # Release

四个环境坑先记下：Windows 钉在 VS2019（VS2022 用户要另装 MSVC v142 工具集 + Windows SDK）；macOS 只支持 Apple Silicon；Git LFS 必须装（否则 STEP/IGES/JT 测试模型是空壳）；Packman 会联网拉包，内网/被墙环境要先做代理准备。

六、1.0.1 修了什么：好内核和"能用的内核"的差距

CHANGELOG 的 1.0.1（2026-10-21）是这份开源最有信息量的部分——它把"开源第二天就有多少人踩坑"直接摊开。挑几条对使用者最要命的：

读法：一个几何内核的成熟度不看它能不能做布尔（三十年前就能），而看边界条件怎么失败。1.0.1 这一版里，"报成功但其实没做"（remove_fillet）、"容差被悄悄放大到毁掉下游结果"、"同输入不同进程结果不同"——三条都是 CAD 里最贵的失败类型，两周内被点名并修掉，是好事；但也说明这类问题在这个内核里还在持续被发现。

七、还没修的坑（KNOWN_ISSUES 摘译）

这些是官方自己列的，用之前必须知道：

• heal_brep 会报成功但实际没修：修复各阶段（含 seam 插入）的失败不上报。兜底：修完用 is_manifold_solid() 或导出到 USD 后跑 bin/brep_geometry_validator 复核。周期曲面（环面、球、圆柱）缺 seam 或 seam 重合时的误修、极点附近丢面等一批问题都还没有 workaround。
• stitch_brep_with_face 任何输入都崩进程（盒子的一个面、平面片的面都试过）。改用 stitch_brep / stitch_into_shell / stitch_into_solid。
• 浅重叠会被判成 touching：brep_relationship 只在顶点、面上一采样点、边上的点找重叠；半径 1 的球压进 create_box((0,0,0),20,20,10) 的 x=20 面 0.2 深，结果仍是 touching 而不是 interpenetrating——碰撞判断在这种量级上不可信。
• 圆角旁边三角形绕序反（渲染内翻），圆柱端盖与圆角旁的圆锥上都出现过。临时解：把 surface_angle_tolerance_deg 设成 15°，作者说没再遇到。
• 球极点处的细长三角形、抽壳后不是实体（仓库自带 problemShell4.smb 外偏 5.08、第 2 面开口 → 3 个面不成实体）等问题仍在列表上。

再叠上三条非技术限制：不收外部贡献、bundled 第三方组件另有条款（见 THIRD_PARTY_NOTICES.md）、Apple Silicon only。

八、对 BIM / IFC 意味着什么

先把不该说的说清楚：它不是 IFC 工具。仓库里只有 OpenCASCADE 与 STEP/IGES/JT 方向，没有 IFC 读写；几何内核开源也不等于认证（IFC 认证视图、算量规则、规范合规都不在里面）；它两周大、12 个 open issue、贡献冻结。

但它解决的问题，恰好是 BIM 里最老的那一个：

1. 碰撞检测的"软碰撞"终于有确定答案的路。上面场景 1 说的"测量距离与三角化容差同量级时排除碰撞不安全"，就是 BIM 协同里跨专业硬碰撞的日常。IFC 本身有 B-Rep 表达（IfcAdvancedBrep 等），但实际流转到 USD/glTF 里的大多是三角化结果——精确几何能不能活到浏览器/协同平台，决定了碰撞报告能不能上会。
2. "一个文件、多种精度" 是 BIM 协同的刚需：业主要看模型、结构要算、施工要净距、算量要边界。提案把这个诉求写成"消费方各自派生、不改源"，正是 IFC 流转里最难做到的一件事。
3. USD 正在成为 AEC 的事实底座（Omniverse 侧的数字孪生、施工模拟）。AOUSD 的工作组文档里 AECO 是被单列的一节——这次开源让"USD 里只有壳、精确几何留在各家原生格式"这个长期妥协有了替代方案。

现在能做什么：拿一个 IFC 查看器 或 在线 CAD 查看器 看模型，同时用 smlib_gui 打开同一个零件的精确几何对照——你会直观看到"三角化容差吃掉了多少净距"这件事到底有多大。这比读十篇评测有用。

九、该不该试：三条判断

值得现在动手：① 你在给产品找可商用嵌入的几何内核，且能接受早期内核的坑——Apache 2.0 + 专利授权这条比 CC 类许可干净得多；② 你的管线已经决定押 USD，需要一个能读能写 B-Rep 的 USD 工具链（转换、heal、三角化、校验都现成）；③ 你想给 Agent 一套"能算精确几何"的手，而不是只会数三角面。

再等等：① 要替代 Parasolid/ACIS 做主力建模——12 个 open issue 与贡献冻结意味着你踩到的坑得自己修（许可允许，但你得有 C++ 几何工程师）；② 需要成熟曲面（Class-A）、大装配性能、长期 API 稳定性承诺；③ 走 IFC 全流程、要认证与合规。

上手三步：① pip install usd-brep 跑上面五行代码，确认在你的 Python 3.12 环境里能装上；② 拿一个你自己的 STEP 用 occt_to_usd 转成 USD B-Rep，view_usd.py 打开看拓扑对不对；③ 故意做一个退化件（缝隙 1e-4、圆角半径 1e-4）看它怎么失败——内核选型的关键从来不是成功路径，而是失败路径。

图：proposals/UsdSolid 里"带内部空腔的立方体"示例的几何示意——这种"外盒 + 内球腔"在网格里要靠壳体判据才能看出来，在 B-Rep 里是显式拓扑。原图：cubevoid.png（Apache-2.0）

Sources

• 主源文：CloudNavi《NVIDIA Open-Sources the SMLib CAD Kernel Under Apache 2.0》（2026-10-13）https://cldnavi.com/en/blog/nvidia-smlib-usd-brep-2026/
• 仓库与 README：https://github.com/NVIDIA-Omniverse/usd-brep
• 官方文档站（Python / C++ API）：https://nvidia-omniverse.github.io/usd-brep/
• 变更记录（v1.0.0 → v1.0.1）：https://github.com/NVIDIA-Omniverse/usd-brep/blob/main/CHANGELOG.md
• 已知问题：https://github.com/NVIDIA-Omniverse/usd-brep/blob/main/KNOWN_ISSUES.md
• B-Rep 问题陈述（AOUSD 几何工作组，v0.1 DRAFT）：https://github.com/NVIDIA-Omniverse/usd-brep/blob/main/proposals/cad_geometry/README.md
• omniSolid / BrepArray schema 提案：https://github.com/NVIDIA-Omniverse/usd-brep/blob/main/proposals/UsdSolid/README.md
• PyPI：https://pypi.org/project/usd-brep/
• 原始发布帖（@0xca0a，ClassCAD / Buerligons.IO，2026-10-12，经主源文转述）
• 相关第三方项目：awv-informatik/smlibpy（MIT，SMLib 的 Python 绑定）https://smlibpy.classcad.ch ｜ tangency-labs/solidcore（Rust 重写 SMLib 的 CAD 子集）

同主题阅读

• SolidCraft：纯 Rust 的开源参数化 3D CAD
• STL 变回可编辑 CAD：mesh2cad 的平面/圆柱拟合
• 别人发来的 3D 文件怎么验收：STEP 翻译与网格拓扑

本文属于「CAD / 制造 / G-Code」专题。BimAnt 编译整理，转载请注明出处。文中版本、star 数与 issue 数截至 2026-10-23；本文未做本地编译与几何实测，行为描述以官方 README / CHANGELOG / KNOWN_ISSUES 为准，请以你自己的零件复测。

本文属于「CAD / 制造」专题。查看专题全部文章 →

一句话结论：免费 AI 3D 交付的常常不是"带材质的模型"，而是一堆三角面。一份 Meshy 免费账号导出的葡萄风信子 GLB 有 784,708 字节、21,781 顶点、43,546 三角形，唯一的网格属性是 POSITION——没有 UV、没有法线、没有贴图、没有 PBR。它能进 Houdini、能过 glTF 校验、能在 Three.js 里 33 毫秒加载完（本地预热），但它不是可直接用的资产。全文最值钱的一条教训是：把模型归一化到 0.6 单位高之后，照默认参数做清理，细叶被删掉近一半（43,546 → 23,817 三角形，边界边 0 → 11,625）。

披露：本文编译自 Alicia / Digital Garden 的免费工作流实测（dev.to 2026-10-20），原文由 Codex 操作 Meshy 网页、Houdini 22.0.429 与 Three.js 验收页完成，作者保留了失败项与未测边界。模型以 CC BY 4.0 发布，署名"model created with Meshy by Alicia"，派生件附修改说明。我们没有复跑；免费额度与面板文案是 2026-10-20 的界面观察，平台随时可能改。

一、先确认"能不能导出"，再花时间生成

这份实测的第一个坑不在几何，在账号权限：

作者的做法值得抄：先用一次真下载验证权限，再谈批量生成。选择器里有某个模型，不等于这个账号能把它导出来；"先生成 20 个，最后发现一个都下不了"是最贵的失败。

二、下载下来的文件里到底有什么

三点必须分清：

1. 颜色不是"贴图丢了"，而是从来没生成过。提示词里写的紫色花、绿色茎，只存在于提示词里；交付物是纯几何。要颜色，后面得自己做 UV、材质或顶点色。
2. 0 边界边 + 0 非流形边，只证明"每个壳闭合、没有三面共边"。它不证明无自交、不证明 13 个组件是一个整体、更不证明可打印。网站上的 printable 徽章不能替代测量。
3. 13 个组件对植物是合理的（叶片、花、茎可能各自成件），但进引擎后就是 13 个可分离对象：合并、命名、碰撞体、LOD 都要额外处理。

三、一次失败的清理，把"尺度"问题暴露出来

作者的处理顺序：保留原始文件 → 派生件居中到 X/Z、落到地面、归一化到 0.6 单位高 → 进 Houdini 清理。

第一版清理用默认参数，结果：

• 只剩 23,817 三角形
• 边界边 11,625
• 组件 69

文件确实变小了，但洞更多了——作者直接拒绝："更小的文件 + 更多的洞不是清理"。

原因在 Houdini 的 Clean 参数语义：Degeneracy Tolerance 是"边长"量纲，其平方与面积比较（SideFX 文档原话）。所以模型被缩放后，"什么算退化"的物理阈值也跟着变了：把 0.6 单位高的小模型交给默认容差，等于用别人的尺度标准删你的细节。

接受版的做法：

• 把退化容差降到 1e-12
• 可能的重叠/自交条件只标记、不自动修
• 结果：43,546 三角形、0 边界边、0 非流形边、13 组件全部保留

这条经验比任何参数表都重要：先固定尺度策略（原始单位，还是统一归一化），再调容差；每跑一步都记录三角数 / 边界边 / 组件数，数字变了就要问"这是我想要的吗"。

四、减面与重网格：参数要落在"真正生效的字段"上

• PolyReduce：用 Output Polygon Count 目标，finalcount=3000。 注意：只把数字写成 3000、但目标类型还停在 percentage，这个值不会生效。
• Remesh 分支：target size 0.006，5 次迭代。

两个诚实的点：

• remesh 丢了一部分叶宽，与包围盒的变化一致，所以不能叫"视觉一致"。
• 三个分支在导出 GLB 前都做了六面投影 UV + 计算法线。这产生的是"可检视的 UV"，不是手工低畸变的 UV 布局；源文件没有 PBR 图像可烘，作者也没有伪造"贴图烘焙成功"。HIP 保存、重开、重算过一遍。

五、浏览器验收：四个候选，两组数字

• glTF 校验：源文件与最终 GLB 均 0 error / 0 warning（信息级与 bufferView 提示保留在回执里）。
• Three.js 0.186.1：每个候选都通过 5 个不同的 localhost URL 加载；计时包含解析、编译与提交一帧，是预热后的本地时间，不是公网或冷启动时间。

最容易误读的一行是第二行：给全分辨率派生件补上 UV 和法线后，它比"只有 POSITION"的原始文件更大。减面与补属性是两件不同的事，不能指望"清理一下文件就小了"。

实例化测试：把 3,000 三角形的候选复制 1,000 份，用 InstancedMesh，回执记录 2 次 render call、3,000,001 个三角形（含节点渲染器的输出 pass）。实例化共享数据，但不减少重复的三角形工作量。WebGPU 与强制 WebGL2 回退都测过。

glTF 查看器

六、可直接抄的验收清单（AI 3D → 引擎 / 打印）

1. 许可与署名：平台条款 + 导出许可（本例 CC BY 4.0）；派生件保留署名与修改说明。
2. 账号权限：当前计划能下载哪些模型？先做一次真下载验证。
3. 字节 / 三角形 / 顶点：先记账，再谈优化。
4. 属性清单：POSITION / NORMAL / TEXCOORD / 材质图像 / 扩展。
5. 组件数：几个壳？是否需要合并、命名、分组。
6. 边界边与非流形边：焊接后测，别把 UV 缝当边界边。
7. 绕序与法线：导入后是否统一朝外。
8. 尺度 / 单位 / 原点 / 朝向：包围盒 vs 实物尺寸。
9. 清理容差与尺度的绑定：归一化后重设容差；每一步记录计数。
10. UV 来源：投影 UV 可用于检视，不等于可交付 UV。
11. glTF 校验：0 error 是底线，warning 也要看。
12. 运行预算：加载时间、draw call、三角形/实例预算。

七、这条路什么时候够用，什么时候不够

够用：概念图、道具、远景、白模打印前的形状探索、给程序化场景做参考件。

不够用：

• 替换生产资产：缺材质、UV、变形属性，也没有场景级验收；
• 直接打印：细叶/薄壁、最小壁厚、支撑面都还没验（水密不等于能打印）；
• 继续编辑：三角面不是 B-rep，要参数化得走 STL → 可编辑 CAD。

作者最后放了一株独立编写的 Houdini 风信子做几何预算与结构可见性的参照，并明确说明：它不是植物学真值，也不是盲测审美对比。这个态度值得学——参考件只用来对齐预算，不用来证明"AI 做得对不对"。

一句话：免费额度买到的是几何起点，不是资产交付。 把它当草稿，后面的 UV、材质、尺度、拓扑与场景验收，每一步都要自己补。

Sources

• Alicia lu, Meshy Free to Houdini: What the GLB Actually Contained，dev.to，2026-10-20：https://dev.to/alicia_lu/meshy-free-to-houdini-what-the-glb-actually-contained-1jf0
• 原文（Digital Garden）：https://digitalgarden.si/blog/meshy-3d-agent-houdini-cleanup/
• 复现包（原始下载、派生网格、Houdini 脚本、查看器与结果）：https://digitalgarden.si/marketing/research/comparisons-20261020/assets-tests.zip
• SideFX, Clean SOP（Degeneracy Tolerance 的量纲说明）：https://www.sidefx.com/docs/houdini/nodes/sop/clean.html
• SideFX, PolyReduce SOP：https://www.sidefx.com/docs/houdini/nodes/sop/polyreduce.html

同主题阅读

• AI 3D 资产的交付重量：62.89 MB 与 5.63 MB，差在哪
• AI 生成 3D 资产的五项交接检查：Meshy 物件与地图上下文
• 水密不等于能打印：AI 3D 资产的验收清单

主工具：拿到一个 GLB 先别急着进引擎——拖进在线 glTF 查看器 看一眼有没有法线、材质和贴图，再决定要不要清理。要看三角形数量与包围盒，用 3D 模型查看器 也行。

本文属于「AI × 3D / 生成式 AI」专题。BimAnt 编译整理，转载请注明出处。原文为免费额度下的单模型、单文件测试（由 Codex 操作），加载时间为本地预热数据；模型以 CC BY 4.0 发布，转载时请保留署名。

本文属于「AI × 3D」专题。查看专题全部文章 →

一句话结论：Blender MCP 不是 token 黑洞。72 次运行里，日常任务 $0.16–$0.23，一个带赛道、120 帧动画和追尾相机的完整赛车场景 $0.47；唯一贵到离谱的是"把 580 个对象的全部属性打印出来"——$0.87，比日常任务贵四倍多。钱不是花在 Blender 上，是花在步数和长输出上：每次请求约 24,916 token 的固定开销，其中大部分是 Claude Code 自己的指令，每一步都会重发；MCP 服务器返回的场景摘要其实已经很克制（默认每次 20 个对象、截图 768 px）。

披露：本文编译自 TokenSave 的公开实测（2026-10-22，数据以 CC BY 4.0 发布，DOI 10.5281/zenodo.23562484）。作者同时也是 tokensave-mcp-diet 这个结果代理的作者，所以"代理省 81%"这条结论有立场；本文保留其原始数据、以及作者自己标注的噪声区间（<8% 当噪声）。我们没有复跑。文中"成本"是 Claude Code 按 Opus 5.5 API 价目报告的账单，不是订阅套餐折算，也不含事后渲染时间。

一、实验怎么做的：72 次运行，每次读回 .blend 验证

先记下"为什么强调读回文件"：截图好看不算通过。这一点和我们此前那篇验证 3D 输出的口径一致——验收要落在产物上，不落在预览上。

二、日常任务：$0.16–$0.23

三个观察：

1. 输入 token 从 7 万到 12.6 万，成本只差 7 美分。日常任务之间的差异，基本被"这次走了几步"吃掉了。
2. 图像 token 占比很小。最多的一次是 1,322（估算），放在 11 万输入里约 1.2%。所以"少截图"不是一个有效的省钱手段。
3. 服务器本身已经在收敛。25 次日常运行里最大的文本结果是 2,347 字符——场景信息默认每次只列 20 个对象，截图默认 768 px。换句话说，传闻里"Blender MCP 会灌爆上下文"的情形，在这套默认值下没有出现。

三、完整场景：$0.47

任务是：自行设计一台低多边形赛车、一条带弯道的赛道、一段 5 秒 / 120 帧的过弯动画，再加一个追尾相机。

• 平均 9.6 次请求、约 93 秒、$0.47（5 次区间 $0.42–$0.56）
• 10 次运行（5 次原样 + 5 次加代理）全部产出可工作的动画
• 事后用 EEVEE 渲染约 90 秒/条，不计入这 $0.47

图注：每个赛车和赛道都是 Claude 在那次运行里自己设计的。原图见 tokensave.app。

这条结果的含义是：一个能看、能动、能渲的小场景，成本约等于两次日常任务。真正的变量是"这次任务需要几步"，而不是场景本身有多复杂。

四、唯一失控的场景：把 580 个对象的属性全打印出来

过程很典型：

1. 提示词要求打印 580 个对象的全部属性；
2. 脚本返回 122,373 字符；
3. Claude Code 以"结果太大"拒绝；
4. Claude 自己改成分 4 段、每段约 32,000 字符重跑；
5. 四段全部留在上下文里 → 242,782 输入 token、$0.87，是日常任务的 4 倍以上。

对照组是"打印一个 19,042 顶点球的全部顶点"：Claude Code 直接拒绝，Claude 报告"已打印"然后停止 → 91,572 token、$0.17。代价低了，但结果其实没看到——这是另一种失败：便宜，但不可用。

所以，"print 一切"是 token 账单的头号放大器。正确姿势是要计数、要摘要、要写文件再按需读，而不是让工具把中间结果原样倒进上下文。

五、钱到底花在哪

• 固定开销：每个请求约 24,916 token 是客户端自己的系统提示与工具定义，每一步都重发。任务成本大致随步数线性增长。
• 工具输出：正常场景摘要很小（最大 2,347 字符），但脚本的 print 可以一次塞进 12 万字符。
• 图像：按"宽 × 高 ÷ 750"估算 token；一张 1,024 × 768 约 1,049 token。多图任务会累积，但通常不是主项。
• 缓存：作者统计的"输入 token"是未缓存 + 缓存读 + 缓存写的合计，不是一次全新的量。

一个够用的估算法：先数步数，再单列长输出。步数 × 2.5 万 token 是底盘，长输出和图片是附加项。想省钱的顺序应当是"减少步数 → 禁止长输出 → 最后才动图片尺寸"。

六、一个结果代理能省 81%，但只在长输出场景

tokensave-mcp-diet 0.3（MIT）放在服务器前面，做两件事：

1. 长文本结果（超过 8,000 字符）只保留前 2,000 + 后 1,000 字符，中间给摘要；全文留在内存，用新工具 result_detail 按行号或搜索取回。
2. 图片默认降尺寸：带 max_size 的工具默认 512 px，除非模型明确要求大于 1,000。

配置写法：

{
  "mcpServers": {
    "blender": {
      "command": "npx",
      "args": ["-y", "github:johnisking/tokensave-mcp-diet", "--", "uvx", "mcp-for-blender"]
    }
  }
}

作者自己拆台的部分最值得读：赛车场景的图像 token 降了 62%，但图像只占输入的小头，所以成本只降 6%，落在运行间噪声里；房间描述那项代理什么都没改，也降了 4%。结论：小于 8% 的差异都当噪声。代理是"长输出的保险"，不是"每次都打折"。

还踩了一个值得记的 bug：MCP for Blender 同时把结果放在 structuredContent 里，而 Claude Code 显示的是那个字段，所以 0.3 之前的长输出压根没被截断；0.3 修好后才重跑了对应用例。

七、把结论用到自己的 3D 流水线上：五条纪律

1. 先量再优化。日常任务之间只差 7 美分，先找出"贵的那一类"——通常是长输出或"改一步、截一张、再改"的循环。
2. 禁止 print 全量。要 counts、要 summary、要落文件；要明细就用分页/搜索工具取。
3. 截图默认值别乱调。768 → 512 只对多图任务有意义，别指望它降大账。
4. 步数就是成本。把"改—看—再改"压成一次可验证的脚本，比抠 token 更有效。
5. 验收看文件。72/72 是通过读回 .blend 得出的；"Claude 说完成了"不是证据。

八、边界：这些数字不能直接搬到你的项目

• 单模型、单机器、单客户端：Opus 5.5 + Claude Code + Windows；换模型、换客户端、换价目都会变。
• 样本小：每个任务 5 次（最坏情况 3 次），成本随每次走的步数波动，作者给的是区间而不是定值。
• 图像 token 是估算（按宽高算），输入总数是精确值。
• 工具在快速变化：blender-mcp 在 PyPI 上已改名为 mcp-for-blender（2026-10-22 查为 2.2.2），默认值和工具集会继续漂。
• 没有测生成类工具：3D 生成、资产下载这些按次计费的工具被刻意关掉了，所以这里只有"操作 Blender"的成本，不含模型生成费用。那部分账要另算，见Agent 按次付费做 3D。

九、什么时候这条路不值得

• 要精确尺寸的零件：自然语言 + Python 不是参数化建模的正确入口。要可编辑几何，走 Mesh2CAD 那类路线。
• 要一次跑几十个变体：按步计费的代理不如写死脚本 + 渲染农场，四台笔记本的账我们算过（SheepIt 外包渲染）。
• 要稳定复现：同一提示两次走的步数不同，成本和结果都会漂；把关键步骤固化成 Python 更靠谱。
• 要交付资产：粗模只是起点，材质、UV、尺度、水密性、引擎预算都还在后面（AI 3D 资产的交付重量）。

一句话：Blender MCP 适合把想法变成可看的粗模和场景，不适合把粗模变成可交付的零件。 72 次账单告诉我们，前者其实很便宜；贵的是那些你没意识到的长输出。

Sources

• TokenSave, How many tokens does Blender MCP cost? 72 Claude Code runs, and a racing scene for $0.47，2026-10-22：https://dev.to/jaehyun_cho_0dff271e0d2e5/how-many-tokens-does-blender-mcp-really-use-72-claude-code-runs-and-a-racing-scene-for-047-5hl3
• 完整数据与方法（CSV / JSON，CC BY 4.0，DOI 10.5281/zenodo.23562484）：https://tokensave.app/data/blender-mcp-token-cost
• 结果代理 tokensave-mcp-diet（MIT）：https://github.com/johnisking/tokensave-mcp-diet
• MCP for Blender（原 blender-mcp，MIT）：https://github.com/ahujasid/blender-mcp

同主题阅读

• Blender 接 AI Agent：MCP 横评与云渲染实测
• CAD 工作站别为 64 核买单：配置实测与 AI 3D 账单
• 验证 3D 输出：支撑探测与网格审计

主工具：想直接看 Claude 或 Blender 导出的 GLB 长什么样？把文件拖进在线 3D 模型查看器，在浏览器里转着看，不用装软件，也不用上传到第三方账号。

本文属于「AI × 3D / 生成式 AI」专题。BimAnt 编译整理，转载请注明出处。文中数据来自第三方实测（数据以 CC BY 4.0 发布），成本为 API 价目下的单次账单，不含渲染；作者与代理工具存在利益关系，已在文内披露。

本文属于「AI × 3D」专题。查看专题全部文章 →

一句话结论：image-blaster 不是一个"文生 3D 模型"，而是把一张图拆成"静态环境 + 动态物件 + 音效"的四个模型编排——静态环境交给 World Labs 的 Marble（出 .spz 高斯泼溅），每个动态物件交给 Hunyuan 3D v3.1（出 .glb/.obj），环境与冲击音效交给 ElevenLabs（出 .mp3），中间用 nano-banana-2 做底版清理与物件抠图。它自称"一张图到完整网格化环境 < 5 分钟"——这句话没错，但它说的是时间，不是钱：世界生成固定约 $1.34，之后每多一个物件约 +$0.46，钱全花在物件数量上。真正的坑在最后一步：导出的 .spz 与 collider 网格不带 Marble 的尺度修正，直接拖进引擎会出现尺寸与地面都不对。

披露：本文编译自该项目仓库（neilsonnn/image-blaster，MIT）的 README 与 .claude/ 下的 skill 与脚本（截至 2026-10-21 的 main 分支），以及 World Labs 官方文档（docs.worldlabs.ai）、FAL 各模型页的公开价目（2026-10-21 实查）。本文没有做端到端实测：成本数字是按管线结构与公开单价推算的账单估算，不是我们的实测账单；面数与兼容性结论来自官方文档，非我们逐项复现。作者是 World Labs 团队成员，因此对 Marble 的描述带有作者视角——这不是 World Labs 的官方产品。本站与该团队无利益关系。

一、它到底做了什么

它是一套给 Claude Code 用的 skill 包（不是一个独立 App）：你在本地 clone 仓库，在仓库目录里启动 claude，把两张图之外的东西——两把 API key——交给 Claude，然后放一张图进 input/，说一句 blast it and confirm each step with me。之后每一步由 Claude 调仓库里的脚本完成，并在每步停下来向你确认。

产物三件套——注意这三样的"性质"完全不同，这是后面所有问题的根源：

另外一个容易被忽略的产物是collider 网格：脚本会把 Marble 返回的 assets.mesh.collider_mesh_url 一起下载存成 -world.glb。它是给物理碰撞用的粗网格（官方文档：GLB、10–20 万三角面，"为简单物理计算优化"），不是给渲染用的高模。

二、管线：四个模型，一条链

从仓库脚本里读到的真实调用（比 README 细一档）：

input/ 一张图
  │
  ├─① 底版清理 / 物件抠图     fal-ai/nano-banana-2/edit         $0.08/张
  │                           （可切 openai/gpt-image-2/edit）
  │
  ├─② 静态环境               World Labs  marble-1.1             1,500 credits
  │      └→ .spz（full_res / 500k / 100k / 150k 全部下载）
  │      └→ collider 网格 .glb（10–20 万面）
  │
  ├─③ 每个动态物件           fal-ai/hunyuan-3d/v3.1/pro/image-to-3d   $0.375/次
  │                           （可切 .../rapid $0.225、fal-ai/meshy/v6 $0.80）
  │
  └─④ 音效                   fal-ai/elevenlabs/sound-effects/v2  $0.002/秒
          环境循环 2×10s + 每物件冲击音 4×1s

对应脚本：

2.1 为什么第一步是"再画一遍图"

image-blast-3d 的 skill 说明书要求：在生成任何物件之前，先为这个物件写一条抠图提示——"把这个物件从图里单独隔离出来，同样的颜色/材质/比例，白底、居中、紧裁切、棚拍光、无其他物体"。

所以一个物件的真实流程是 "1 次图像编辑 → 1 次 3D 生成"，不是"1 次 3D 生成"。这一步在设计上很合理（3D 模型只吃单一物件，混着背景只会更糊），但它是计费翻倍的隐藏项——第三节会算。

2.2 静态与动态，是"分工"不是"分离"

Marble 出的世界已经包含了整张图的内容（泼溅是把整幅画面三维化）。image-blaster 再让 Claude 把图里会动的东西（椅子、箱子、机器人、车）一个个抠出来做成真网格，叠在这个泼溅世界上。

这个思路很实用（泼溅便宜、网格贵），代价是：泼溅与网格之间的边界会露馅——泼溅是"看得见摸不着"的，网格是实的，两者在接触面上的遮挡、阴影、色彩响应不会自动一致。这一条所有介绍文都没提，而它是实际拼装时第一个会崩的地方。

2.3 "每步确认"是默认姿态

quickstart 的最后一句话是 blast it and confirm each step with me——不是可选项，是设计的一部分。每一步都是付费 API 调用，确认一次就是省一次钱；而 Claude 在"这张图里哪些算动态物件"上的判断，本来就需要人来拍板（判断错了，钱花了、东西不是你要的）。

三、四个参数，决定产物质量与成本

物件生成走 Hunyuan 的参数（README 原文）：

两个容易踩的点：

1. 50,000 是这套 skill 自己的默认，不是 API 默认。习惯 Hunyuan API 的人会以为是 500k，实际这里砍到了 1/10。好处是快、省算力；代价是近景主角一放大就露，得手动画 --face-count 重跑（重跑 = 再付一次 $0.375）。
2. Geometry 不是"低模"，是"白模"：不要贴图、只要形体时用它，配合之后在 Blender 里自己展 UV——但那样就比 Normal 多一道工序。

按场景选（经验口径，非实测）：

四、成本：世界是固定的，钱在物件上

先给价目（全部 2026-10-21 从官方页面实查）：

由此得到这次要的结构：

每次跑的固定成本 = 世界 1,264（1,500 + 80 credits） + 底版编辑 0.08      ≈ $1.34
每个动态物件     = 抠图编辑 0.08 + 3D 0.375 + 冲击音 4s × 0.002 = 0.008  ≈ $0.46

三个反直觉的地方：

1. "5 分钟"最贵的一步不是那个"世界"。Marble 出整个世界只要 $1.26，而 5 个小物件就要 $2.3。一个场景值不值，取决于物件数，不取决于画幅。
2. 官方那个 $2.80 的 HQ 网格导出，这套流程没买。脚本只取 collider_mesh_url（10–20 万面的粗碰撞网格）。所以：如果你要"能看的静态网格"，得自己回 Marble 单独导 HQ——那一步是按次 $2.80 起，且最长要等 1 小时、限每小时 4 次。这一条是本项目最容易被忽略的隐性成本。
3. 失败即付费。面数不满意重跑、抠图不满意重抠、某个物件切错了重切——每一次都是完整的一次计费。所以 skill 才强制"每步确认"。

口径：以上是按管线结构与公开单价推算的账单估算，2026-10-21 价目，不是我们的实跑账单；未计失败重试、未计 Marble 订阅计划差异（免费计划可生成但不可导出，导出需 Standard 起；HQ 网格与商用权在 Pro）。

五、产物能不能用：先修尺度，再谈引擎

这一节是全文最实用的部分，也是最容易被跳过的一步。

5.1 自带查看器是对的，导出的文件不是

World Labs 官方文档里有一条专门给第三方引擎的说明（api/rendering-spz）：

Marble 的 SPZ 文件是在"生成资产坐标系"里导出的。在 Marble 之外渲染时，必须用 assets.splats.semantics_metadata 把高斯中心与高斯尺寸换算成米制、地面贴齐的坐标。

这条元数据里有两个数，外加一个可选的朝向位：

官方给的换算就这么几行：

def to_metric_gaussian(center, linear_scale, semantics):
    scale = semantics["metric_scale_factor"]
    metric_center = center * scale
    metric_center[..., 1] -= semantics["ground_plane_offset"]
    metric_linear_scale = linear_scale * scale

关键点：这个修正是渲染时做的，.spz 文件本身不带。

那 image-blaster 有没有处理它？把仓库拉下来 grep 一遍（2026-10-21，main 分支）：

于是问题就清楚了：在自带查看器里比例是对的，因为它替你补了修正；而落进 worlds/<name>/output/ 的 .spz 和 collider .glb 里没有这个修正。 你把它们拖进 Unity / Unreal / Blender / three.js，拿到的是一套"看起来像"、但单位不是米、地面不在 y=0 的场景。

5.2 错误长什么样，怎么修

症状很好认：

• 不是米制：一扇门可能是 30 多个单位高，按 1 单位 = 1 米摆摄像机，你会在桌面高度看到地板。
• 地面不在 0：所有物件要么浮空，要么半个身子陷进泼溅地面。
• 物件与泼溅错位：两者都出自同一个世界坐标系，一个修了一个没修，接触面就必然错开——这也是后面"边界露馅"的主要成因之一。

修法三步（顺序不能反）：

1. 从世界响应里取 assets.splats.semantics_metadata。仓库脚本把 world 响应存成了 JSON（worlds/<name>/ 下），也可以直接用同一个 world_id 重新 GET 一次。
2. 按 metric_scale_factor 缩放高斯中心与尺寸，再减去 ground_plane_offset 把地面压到 y=0。
3. collider 网格用同一个 metric_scale_factor 缩放（这一步是推断：官方文档只写了 splat 的修正，没有提网格；但两者是同一个生成坐标系，不缩放就必然对不上）。

// three.js：加载完再统一修正，SPZLoader 只负责读文件，不做尺度换算
const world = await new SPZLoader().loadAsync(url);
const m = semantics.metric_scale_factor;
world.scale.setScalar(m);
world.position.y -= semantics.ground_plane_offset;

5.3 引擎支持面：这是"能不能用"的硬约束

先分清两样东西，它们的规模与兼容性完全不同：

两个容易漏的技术细节：

• 坐标系：SPZ 默认是 RUB（OpenGL 习惯的 Y-up 右手系），与 Unreal 的 Z-up 不一致——所以元数据里才有 flip_y 这种可选位。
• HQ 网格不是你想要就有：官方写明最长要 1 小时、每小时限 4 次、只能对自己拥有的世界生成、且属于 Pro 计划；Free 计划能生成世界但不能导出（导出需 Standard 起）。

上图这张全景值得单独说一句：当你的输入不是全景图时，Marble 会先由这张图生成一张全景，再从全景生成世界——这就是价目表里那笔 +80 credits 的来源，也是"一张图"和"一个世界"之间的中间产物。

5.4 十分钟验收清单（可直接抄）

拿到产物后按顺序过一遍，任何一条不过，先别进引擎：

六、四个要先知道的坑

尺度修好只是第一步。下面四个是拼装时真正会卡住人的地方，按"出现的早晚"排序。

6.1 静态 / 动态切分错了 → 重影

泼溅世界已经把整张图都三维化了，包括那些椅子、箱子、车。当你再让模型给"椅子"生成一个真网格叠上去，两把椅子就会同时存在：一把是泼溅里模糊的，一把是网格的。位置稍微差一点，就是重影。

而且这个循环很贵：物件清单是 Claude 看图像之后提的，它多算一个你不需要的物件，就是多付 $0.46；少算一个，那个东西就永远只是一团泼溅。

救法：在跑 3D 之前先拿到物件清单人过一遍（这正是 skill 默认 confirm each step with me 的意义）；被网格替换掉的那块泼溅，接受它被网格遮住，或用简单遮罩挡一下。

6.2 泼溅与网格的边界会露馅

泼溅是"看得见摸不着"的：没有几何、不参与光照、不投影。网格是实体的。两者相交的地方，接触阴影、遮挡关系、色彩响应都不会自动一致。在静帧里看不出来，一进引擎转两圈就明显。

救法（推断，无实测）：给网格物件底部加一张接触阴影贴片（AO blob），或让靠地的接触带直接用网格盖住泼溅；另外避开贴地仰拍的角度。这是所有"泼溅环境 + 生成物件"方案共同的代价，不是 image-blaster 独有的缺陷。

6.3 默认 50k 面，近景会糊

如第三节所说，50,000 面是这套 skill 自己的默认，Hunyuan API 的默认是 500,000。背景道具完全够用，但玩家会走到跟前的东西一眼能看出是生成的。重跑不便宜（每次 $0.375），所以先估好哪些物件会被走近，再一次性把 --face-count 调对。

6.4 音效只是"素材"，不是"音频系统"

看它的默认参数（SKILL.md 原文）：环境音 --loop --count 2 --duration-seconds 10，每个物件 --count 4 --duration-seconds 1。也就是说：

• 环境音是 2 条 10 秒的循环，而且脚本对循环输出保留原始音频（不剪静音，为了接缝），接缝好不好要你自己听；
• 物件音是 4 条 1 秒的冲击声，只有"撞一下"，没有持续声、没有滚动声、没有材质变化；
• 非循环输出会被 ffprobe/ffmpeg 剪掉首尾静音并做响度归一化——这是好事，但也意味着你拿到的已经不是模型原始输出的动态范围。

救法：把这 4 条当占位素材，上线前自己配；或者只用环境音，物件音自己录。

七、什么时候别用它

这套流程解决的问题很窄：快速拿到一个"能进去看"的场景原型。下面这些需求它不合适：

反过来说，它真正好用的场景只有一个：你手上有一张图（概念图、剧照、实拍房间、场景设计稿），想在五分钟内拿到一个能进去走两圈的原型——对齐空间感、定构图、给甲方看 Demo。做这个，它比你从头摆场景快太多。

八、相关阅读

如果你在评估"图片 / 文本 → 3D"这条路，下面几篇能接着看：

更多 AI 3D 内容在专题页：AI × 3D / 生成式 AI 完全指南

九、来源与边界

来源（均为 2026-10-21 访问）：

1. 仓库 neilsonnn/image-blaster（MIT）：README.md；.claude/skills/image-blast-3d/SKILL.md；.claude/skills/image-blast-sfx/SKILL.md；.claude/scripts/world/generate-world.mjs；.claude/scripts/asset-pipeline/{nano-banana-edit,gpt-image-2-edit,hunyuan-3d,meshy-3d,generate-single-asset}.mjs；.claude/scripts/sfx/fal-elevenlabs-sfx.mjs；app/src/components/WorldViewer.tsx
2. World Labs 官方文档：api/pricing（额度与 usage events）、marble/export/specs（spz/ply/collider/HQ 网格规格）、marble/export/gaussian-splat（导出计划限制）、api/rendering-spz（尺度修正）
3. FAL 模型页：fal-ai/hunyuan-3d/v3.1/pro/image-to-3d（$0.375）、.../rapid/image-to-3d（$0.225）、fal-ai/meshy/v6/image-to-3d（$0.80）、fal-ai/nano-banana-2/edit（$0.08）、fal-ai/elevenlabs/sound-effects/v2（$0.002/s）
4. 格式规范：Niantic spz（约比 PLY 小 10 倍、默认 RUB 坐标系）、three.js examples/jsm/loaders/SPZLoader.js
5. 示例图：Marble 官方示例导出（wlt-ai-cdn.art/example_exports/*_pano.png）；image-blaster 官方演示动图（GitHub）

边界（请当真的边界看）

• 本文没有做端到端实测：没跑过真实 blast，没有自己的账单；所有金额是按管线结构与官方单价推算的估算。
• 面数、引擎兼容性、许可证限制来自官方文档与仓库代码，未逐项复现（尤其各引擎的 splat 插件支持度变化很快，以你用的版本为准）。
• 标注为"推断"的两处（collider 网格需同比例缩放、边界露馅的救法）没有官方文档背书，属于经验外推。
• 项目归属：作者是 World Labs 团队成员，但不是 World Labs 官方产品；本文对 Marble 的描述相应带有作者视角。
• 价格会变：尤其是 FAL 的模型单价与 World Labs 的 credits 表；商用前请以当日官网价目与你自己的账单为准。

本文由 BimAnt 编译整理，转载请注明出处。

一句话结论：SolidCraft 是同名项目从 SolveCraft 改名并迁到 tangency-labs 之后的版本：纯 Rust 写的开源参数化 CAD（草图 → 约束 → 特征时间线 → 改一个尺寸就重建），同一套代码跑在 桌面（Windows / macOS / Linux）、浏览器（WebGPU，带 WebGL2 回退） 和 headless CLI，并且自带 MCP 服务器——Agent 可以和人一样，用同一批命令建模、测量、截图、导出。截至 2026-10-19：GitHub 6,549 star、36 次 release / 16 个 minor（v0.1.0 是 10-09，v0.16.2 是 10-19）、release 资产累计下载 112,847 次（含各类安装包，不等于用户数）、中文语言包 1,598 条键值全覆盖。它还很早期：官方标的是 "early but usable for simple parts"，没有 CAM、没有仿真、没有工程图。

披露：本文编译自 SolidCraft 官方仓库的 README、docs/features.md、ROADMAP.md、docs/mcp.md、docs/oracle.md、兼容性说明与 v0.16.x 发布说明（均截至 2026-10-19），并只对"导出 STEP"这一步做了本地实测（见第六节，Windows 便携版 + 仓库自带 examples/bracket.json）；其余流程与数字来自官方文档与仓库统计，未做逐项复现。项目由 Tangency Labs 维护，本站在其中没有任何利益关系。

一、它是什么：一个"三种入口、一套命令"的 CAD

用户真正会碰到的三条入口，共用同一套引擎命令：

# 桌面：打开示例零件
solidcraft --sample
# 桌面：开控制通道，让 MCP 服务器接管当前窗口（能看到 Agent 在建模）
solidcraft --control 7878
# 别处：接上去
solidcraft-cli mcp --connect 127.0.0.1:7878

# 无窗口：跑脚本、导出
solidcraft-cli run examples/bracket.json --out bracket.step

二、三个值得注意的设计决定

1）"一切都是命令"（everything is a command）

这一条决定了它和大多数桌面 CAD 的根本差别：工具栏按钮、命令面板（按 S）、JSON 脚本、控制通道、MCP 工具，调用的都是同一张命令注册表。solidcraft-cli commands 打印整张表的 id、参数文档和当前是否可用；docs/features.md 就是由这张表生成的。

好处很实际：

• 你手点一遍的操作，可以原样录成 JSON，交给脚本或 Agent 重放；
• Agent 失败时读到的是引擎的结构化报错，不是"截图里看起来不对"；
• 界面上有的能力，自动化里就有；反之，自动化能做的，人也能点出来。

代价也很清楚：命令粒度很细（草图约束就几十条命令），纯手写脚本前得先熟悉 id 与参数形状。

2）约束求解器不靠"拖到差不多就行"

官方说明了求解器的分工：能被约束唯一确定的点，用几何构造直接放准（轨迹求交 + 刚性簇分解，参考 Owen 1991、Fudos–Hoffmann 1997），其余交给 Levenberg–Marquardt，剩余自由度由 雅可比的秩给出。于是：

• 过约束的编辑会被拒绝，而不是悄悄变形；
• 完全约束的草图变黑；
• 拖动时每帧求解，松手才重建模型（不会每帧跑一次布尔）。

对实际绘图的意义是"改尺寸不会把草图搞乱"——这也是参数化 CAD 最容易被忽略的基本功。

3）文件与格式是开放的

设计文件是 .solidcraft 容器（网格载荷是无损二进制，纯 JSON 仍然支持）；导出覆盖 STEP AP242（带实体名、颜色、装配体）、IGES 5.3、3MF / STL（二进制与 ASCII）/ OBJ、URDF（带关节的装配体给机器人仿真）和当前视图 DXF；导入支持 STEP（AP203/214/242）、IGES、3MF/STL/OBJ/glTF，桌面版还能通过 cadmpeg 读 FreeCAD .FCStd 与 Rhino .3dm 的实体。

对下游（切片、仿真、PLM、渲染）来说，STEP AP242 是那个"能交出去"的口子；对 Web/游戏一侧，glTF 与 OBJ 至少有路可走。

三、上手：一个树莓派 4 外壳的六步

官方演示是最能说明工作流的一段：从空设计到可打印的树莓派 4 外壳，每一步都留在时间线上，改一个参数整条链重建。

然后回到参数表，把高度 24 → 32 mm，整条时间线重建，外壳、孔位、槽口、刻字全部跟着走——演示视频里这一步是连续的，不是"重新画一遍"。

上面这张是同一套软件的另一面：社区项目 SELENE 用 SolidCraft 的 MCP 服务器建模，时间线 3,323 步、重建零错误，模型可以下载回来继续改（来源：0xlillith/solidcraft-rover）。

四、中文与桌面体验

• 界面语言：assets/locales/ 里 18 个语种，中文 1,598 条键值与英文一一对应（只有 4 条与英文相同，基本等于全覆盖）；v0.16.0 又补了意大利语、波兰语与中/日/法/西的更新。
• 3D 鼠标：Windows / macOS / Linux 都能读 3Dconnexion SpaceMouse / SpaceNavigator（HID 多轴），浏览器侧走 Gamepad API（Firefox 需要先用 3DxWare 的配置文件把设备暴露成虚拟手柄）。
• 浏览器版能装成应用：Chromium 系有"安装应用…"，首次访问后离线可用；团队要内网部署可以用官方镜像 ghcr.io/tangency-labs/solidcraft-web（nginx + 8080，设计存在访客浏览器里，服务器不存东西）。
• 崩溃与恢复：自动保存 + 崩溃恢复，报错对话框能直接生成 GitHub issue 草稿（带上下文，是否提交由你决定）。

五、MCP：让 Claude Code 直接画零件

这是 2026 年这类工具真正的新东西：不是"聊天框贴代码"，而是 Agent 调 CAD 的命令。

启动

# headless：自带一个设计会话，没有窗口
solidcraft-cli mcp

# 从已有设计或脚本起步
solidcraft-cli mcp --in part.solidcraft

# 桥接到正在运行的 App：能看见 Agent 一步步建模
solidcraft --control 7878
solidcraft-cli mcp --connect 127.0.0.1:7878

Claude Code 一行接上：

claude mcp add solidcraft -- solidcraft-cli mcp

15 个工具

磁贴之外还有两个资源：solidcraft://design（带测量的 inspection JSON）与 solidcraft://commands（命令目录）。

文件访问是被关起来的

Agent 只能碰：当前设计所在目录（且必须严格在 home 之下、不能是隐藏目录）、SolidCraft 自己的恢复目录、服务器私有暂存目录，以及显式 --allow-path DIR 给的目录。~/.ssh、~/.aws、.env 默认不可达；Windows 上 UNC、设备名、短文件名（PROGRA~1）等在落盘前就被拒。这个设计比"给 Agent 一个 shell"安全得多——但也意味着你要主动把工作目录划给它。

配套的四个 Skill

仓库 skills/ 下有四个 Agent Skill（Agent Skills 格式）：solidcraft-modeling（新建零件）、solidcraft-editing（改已有设计）、solidcraft-checking（补 SolidCraft 不报的检查、回归与移植）、solidcraft-mechanisms（装配：关节、运动链接、接触集、运动研究）。它们把"命令怎么摆、怎么用 measure 自检、已知的坑"写成了可加载的说明书——这正是 Agent 建模能不能稳住的关键，而不是模型本身有多强。

边界（官方的说法，也是我的建议）

• Agent 建模必须人复核：几何对不对，看体积/面积/质心这些客观量，再看剖面与配合，别只看渲染图；
• headless 截图在无 GPU 时会退到 CPU 光栅（回复里 renderer 会写 cpu，并带 warning），颜色分析类信息会缺失；
• MCP 里没有"运行/停止"这类危险语义，但 execute/batch/export/open/save 都能读写文件，客户端的自动批准策略要自己收（官方把它们的 destructiveHint/openWorldHint 标成了 true）。

六、把模型交出去：STEP 导出（本地实测）

只说"能导出"没意义，我拿 0.16.2 的 Windows 便携版跑了一遍仓库自带的 examples/bracket.json：

solidcraft-cli run examples/bracket.json --out bracket.step

结果：

这一步只证明"脚本 → 内核 → STEP 写出"是通的。没有验证复杂件、装配、颜色与名称是否在别的 CAD 里保真——那需要你在自己的零件上过一遍。收到 STEP 之后的检查项，可以照着 CAD STEP 到网格的拓扑验收 那篇的六步走。

导出物想快速看一眼（不装 CAD），直接把 STEP / IGES 丢进 在线三维 CAD 查看器；只有 STL / OBJ / GLB 的话用 3D 模型查看器 更省事。

七、现状与限制：先看清它"还不是什么"

官方 README 自己写的是 "early but usable for simple parts"。几个必须知道的点：

验证口径：参考测试 83/83 通过（62 个解析解 + 21 个 FreeCAD 1.1.4 独立算出的期望值），比的是体积、面积、质心、包围盒、面数与采样 Hausdorff 距离，且每个件都导出 STEP 再读回。官方明确写了：这些检查不构成完整的几何或工作流等价性证明。

没有的东西（ROADMAP 的"暂缓"清单）：MESH、FORM（T-Spline）、超出实体需要的 SURFACE、PCB / 3D PCB、Render（只有简单的 PBR 预览）、Animation、Simulation、Manufacture / CAM、Drawings（工程图）。也就是说：能做零件，不能出图、不能仿真、不能生成刀路。

已知的技术限制（摘几条对交付有影响的）：

• STEP 导入的装配体被拍平成实体，自由曲面 offset 与只有 pcurve 的边还没读；
• 布尔在"同半径轴线相交"等特殊相切情形会明确拒绝，而不是给一个坏结果（官方立场是"能拒就拒"）；
• G2 圆角只覆盖"平面之间直边"的组合，曲面边、斜端、角接头还不支持；
• 下载尚未代码签名：Windows SmartScreen 会拦，macOS 首次要右键"打开"；
• 0.11–0.14 的"应用内更新"装不上 0.15+（仓库搬家），得手动下一次新版。

换代速度快 ≠ 稳定：11 天 16 个 minor，意味着接口、设计文件格式（0.16 是 format 27）和行为的变动都很快。生产件要用，先钉版本、留 STEP 作为交换物，别把 .solidcraft 当唯一存档。

八、和现有方案怎么比

九、该不该试：三条判断

适合马上试：① 想把"建模"接进脚本/CI/Agent 流水线；② 需要浏览器里打开就改、不想装 CAD 的轻量场景；③ 想给团队找一个可自托管、数据不外发的参数化建模工具（浏览器设计存在本地，桌面版天然本地）。

再等等：① 要出工程图、做 FEA、生成刀路；② 交付对象只认 .sldprt/.f3d，且不接受 STEP 作为中间格式；③ 需要成熟曲面（Class-A）、T-Spline 造型。

上手三步：① 浏览器直接开，用 ?sample 看示例件，确认操作习惯；② 桌面装 0.16.2，跟着演示把一个你自己的小件（板 + 孔 + 圆角 + 抽壳）走完参数化；③ 导出 STEP，用 在线 CAD 查看器 或你现有的 CAD 复核尺寸与颜色，再决定要不要接进流程。

Sources

• 仓库与 README：https://github.com/tangency-labs/solidcraft
• 功能清单（命令注册表）：https://github.com/tangency-labs/solidcraft/blob/main/docs/features.md
• 路线图与限制：https://github.com/tangency-labs/solidcraft/blob/main/ROADMAP.md
• 参考测试口径：https://github.com/tangency-labs/solidcraft/blob/main/docs/oracle.md
• MCP 服务器与文件访问规则：https://github.com/tangency-labs/solidcraft/blob/main/docs/mcp.md
• 兼容性（SolveCraft → SolidCraft）：https://github.com/tangency-labs/solidcraft/blob/main/docs/compatibility.md
• 发布说明 v0.16.0 / v0.16.2：https://github.com/tangency-labs/solidcraft/releases
• 官网与文档：https://solidcraft.io/ ｜ https://docs.solidcraft.io/
• SELENE 火星车（MCP 建模示例）：https://github.com/0xlillith/solidcraft-rover

同主题阅读

• Text-to-CAD：让 coding agent 写参数化 Python 产 STEP
• STL 转可编辑 CAD：mesh2cad 的平面/圆柱拟合
• CAD STEP 到网格的拓扑验收：缝合公差与六步检查

本文属于「CAD / 制造 / G-Code」专题。BimAnt 编译整理，转载请注明出处。文中版本与统计数字截至 2026-10-19；实测仅覆盖示例脚本的 STEP 导出，其余请以你自己的零件复测为准。

本文属于「CAD / 制造」专题。查看专题全部文章 →

一句话结论：AI 生成 3D 的评测很容易停在"像不像"，但真正决定它能不能上线的，往往是交付重量：文件多大、首屏几秒、CDN 账单多少、低端手机扛不扛得住。2026 年 10 月的一份对比用同一张桌面机械臂照片、默认参数各跑一次：两个结果在"像不像"上各有胜负，但在交付上差了一个数量级——Tripo 62,888,224 字节，SupaVoxel 5,627,132 字节，11.18 倍；12 Mbps 手机首屏 41.93 秒 vs 3.75 秒。

披露：本文编译自 meiferreira 的独立实测（dev.to，2026-10-18）。作者声明两份结果都用自己的免费/付费账号、没有厂商账号权限；但原文含 SupaVoxel 的推广链接与 UTM，属于厂商推广内容。62/100 与 89/100 是作者自己的打分，不是行业标准。数据为单张输入、单次生成、stock 默认参数，换图换参数会变。

一、先把数字摆出来

测试方法很干净：一张照片（1,403,490 字节，只有正面），两个工具各跑一次、默认参数，然后把两个结果放进相同相机、相同灯光离线渲染对比。

每三角形字节是这张表里最有用的一个指标。它把"文件为什么大"从玄学变成算术：Tripo 32.18 B/三角，SupaVoxel 5.64 B/三角。这个差距不是几何——两者面数只差 1.96 倍——而是贴图策略 + 是否压缩。

看一眼 glTF 扩展就明白了：

作者还踩了个具体的坑：SupaVoxel 的 UV 是 uint16 归一化的，采样前必须除以 65535，否则所有颜色测试都会"读不到"——他的电缆检测一度因此误判为"没有电缆"。这是压缩换来的隐性成本：省了字节，多了适配。

二、62.89 MB 买到了什么

作者没有一边倒。逐项拆开，Tripo 确实赢了几行：

Tripo 的 957,156 个额外三角形和 57.26 MB，买到的是三根可分开的线束、两个环而不是一个环、更高分辨率的贴图；没有买到更大的孔、更快的加载、更低的 CDN 账单，也没有买到线框图里能看出来的结构差异。

关于"发明"这件事，作者的表述很克制，也值得抄下来：输入只有一面，背面的任何东西都是产品编的，"没有正确答案"；但只有一家在没有任何参考的面里，加了一个没人支持的零件。 对工业件、备件、需要装配的东西，这就是硬伤——不是因为丑，而是因为它会让你以为那里真有个东西。

三、贴图的账：61.3% 的字节永远不会被打印机读到

Tripo 的贴图总量 6,773,618 字节，其中：

对渲染，4096² 是优势；对打印，切片器最多看 baseColor，其余 61.3% 的贴图负载永远用不上；而 Tripo 的 normal map 单个就有 2,676,872 字节，是 SupaVoxel 整套贴图的 4.56 倍。一句更扎心的：白模打印时，两张 baseColor 都价值为零，其中一张还要你多付 2.62 MB。

这不是说"高分辨率贴图没用"，而是说同一个资产，网页展示和打印交付应该用两份不同的文件。很多团队只导一份，然后两头都将就。

四、线框图在高面数下证明不了任何事

作者做了一组对照：在 ~100 万面和 ~195 万面下各渲染一张线框特写。结果看起来几乎一样——SupaVoxel 的 44.7 KB PNG 基本是黑的，Tripo 的更黑更平，PNG 反而只有 32.6 KB，因为均匀噪声压缩率高。

这段的意义是方法论：线框图不是"面数合理性"的证据。要判断多出来的三角形花在哪，得看具体部位的对照渲染（线束、环、孔洞），或者直接算"每三角形字节"和"关键特征处的面密度"。

五、上线前的"交付重量"验收表

把这篇的结论压成一张可以照着用的表。阈值不是标准，是按"移动端首屏 < 5 秒、单页 CDN 成本可控"倒推的经验值，按你的实际流量调整：

再加两条不写在表里但更重要的：

1. 同一资产准备两份交付物：网页用的轻量 GLB（压缩 + 2K 贴图）、制造用的高精度文件（含完整贴图/STEP）。混用一定有一头吃亏。
2. 把"打开兼容性"当功能而不是细节。SupaVoxel 的压缩让文件小了 11 倍，但旧工具链要先转一次；Tripo 到处能打开，但代价是 11 倍流量。没有免费的选择，只有你愿意付在哪一头。

六、边界

• 单张输入、单次生成、默认参数：换一张图、换一次种子，结论可能不同。作者的分数是主观加权，不是可复现的基准。
• "像不像"没有正确答案：背面、内部、被遮挡处都是模型编的；评测只能判断"编得是否合理"，不能判断"是否正确"。
• 作者有推广关系：原文带 SupaVoxel 的 UTM 链接，本文保留其数据与结论，但请你按自己的素材重跑一遍。
• CDN 单价是假设：$0.085/GB 只是示例，实际价格与区域、缓存命中率、压缩传输都有关。

一句话收尾：AI 3D 的第一道门槛是"能不能生成"，第二道是"像不像"，第三道是"交不交得出去"。 前两道靠模型，第三道靠你自己算账。

Sources

• meiferreira, Tripo AI 3D Review 2026: 62.89 MB and a 41.9-Second Download（Tripo × SupaVoxel 机械臂对照），dev.to, 2026-10-18：https://dev.to/meiferreira/tripo-ai-3d-review-2026-6289-mb-and-a-419-second-download-1fil
• 作者同系列其他样本（台灯、骷髅、针织托盘等）：dev.to @meiferreira

同主题阅读

• AI 3D 资产的数字验收：水密≠可打印
• AI 生成 3D 资产的五项交接检查
• STL 转可编辑 CAD：平面/圆柱/圆锥拟合与验收

主工具：想自己核对文件的三角形数、贴图与包围盒？把 GLB 拖进在线 3D 模型查看器，在浏览器里直接看，不用上传到第三方服务。

本文属于「AI × 3D / 生成式 AI」专题。BimAnt 编译整理，转载请注明出处。文中对比含厂商推广成分，数据为作者单次实测，请按自己的素材与目标平台复核。

一句话结论：文生 3D 的默认路线是"上传图片到云、等排队、下载模型"。2026 年 10 月的一个开源实现把整条流水线搬进了浏览器标签页：提示词或照片 → 4B 参数的 TRELLIS.2 → 带 PBR 的 GLB，全程用 WebGPU 在你自己的显卡上跑，不经过服务器。在 RTX 4070 + Chrome、权重已缓存的情况下：照片转 GLB 148 秒，第二次 134 秒，提示词转 GLB 180 秒。第一版要 712 秒。

披露：本文编译自 LostBeard（SpawnDev.ILGPU.ML 作者）的发布文（dev.to，2026-10-17）。作者是项目维护者，时间数据来自其本机单次测量；模型许可证各不相同（TRELLIS.2 为 MIT，DINOv3 / SD Turbo / RMBG-1.4 各有自己的许可），商用时需逐个核对。

一、它不是"又一个在线生成器"

先看它到底做了什么：

TRELLIS.2 内部的结构值得记一下：先用 DINOv3 提图像特征，再用三个 1.3B 参数的 flow transformer 分别生成稀疏结构、形状和贴图，然后由稀疏 VAE 解码器解出双网格（dual-grid）mesh。整条链路跑完约 3 分钟，输出可以拖进任何支持 glTF 2.0 的工具。

关键差别在"不上传"：你的草稿图、产品照、未公开的模型参考，不会离开本机。对需要保密的工业件、还没发布的产品，这一点比"快 30 秒"重要得多。

二、三个数字：712 秒 → 148 秒

作者在 RTX 4070 + Chrome、权重已缓存的条件下测了三种情况：

从 712 秒压到 148 秒，靠的不是换模型，而是五个工程改动。这五条对任何"把大模型塞进浏览器"的项目都通用。

三、五个工程问题，五条可复用的解法

1. GPU kernel 用 C# 写，编译成 WGSL

每个 kernel 都是一个 C# 方法，由 SpawnDev.ILGPU 编译成 WGSL（桌面端还能编成 CUDA / OpenCL / CPU），同一份源码多目标。两个关键 kernel：

• 寄存器分块的 GEMM：128×128 输出块、256 线程、每线程 8×8 累加器；一个 kernel 同时覆盖 bf16 与 f16 权重，并支持 gather 行。
• Flash attention：8 个 lane 共享一个 query、每线程 4 个 query，用 subgroup shuffle 做归约；不支持 subgroup 的设备走共享内存变体。

在 4070 的 WebGPU 上，这组 kernel 跑到 GEMM 约 8 TFLOPS、attention 约 5.6 TFLOPS。

这条对工程选型的含义：WebGPU 不是"只能跑小模型"。真正的门槛是你能不能把 kernel 写对，而不是算力上限。

2. 10 GB 权重 vs 浏览器存储配额

浏览器的站点存储配额经常小于模型本身。RangeStreamModelSource.PlanCacheAsync 的做法是：算出一个"最能填满配额"的权重文件子集，缓存进 OPFS；剩下的每次运行用 HTTP Range 流式拉取——4 个 16 MB 请求并发，从 fetch 直接进 GPU buffer，不经过 .NET 堆。

var ranged = new RangeStreamModelSource(hubModelSource);
await ranged.PlanCacheAsync(Trellis2Weights.HubWeightFiles(), freeQuotaBytes - 300_000_000L);

using var gen = new Trellis2ImageTo3D(accelerator, Trellis2Weights.FromModelSource(ranged));
byte[] glb = await gen.GenerateGlbAsync(rgbaPixels, width, height);

注意 - 300_000_000L 这个尾巴：给配额留安全余量。浏览器配额会被其他标签页、缓存、清理策略影响，留 300 MB 是保守但必要的做法。

3. Shader 编译是串行的

WebGPU 在首次使用时编译 pipeline，一次一个。GEMM 与 attention 这种大 kernel 每个都要几秒，而它们在运行开头全挤在一起。WebGPUAccelerator.PrecompileAsync（5.3.8 新增）用 createComputePipelineAsync 在加载权重的同时后台编译：4 个 shader 从串行 1571 ms 降到并行 511 ms。

4. 300 万面的网格不能直接简化

双网格输出的面数约 300 万。把这么多三角形直接喂给边折叠（edge collapse）简化器，在浏览器里会卡死。解法是两级：

1. 先在 GPU 上做自适应八叉树 + 二次误差聚类，把面数降到约 50 万；
2. 再做边折叠，最终输出约 15 万面。

5. Blazor WASM AOT

非 GPU 的阶段（简化、UV 图集打包）是纯 C#，在 .NET 解释器下很慢。开 AOT 之后：

代价是体积：GitHub Pages 拒绝 100 MB 以上的文件，而 AOT 后的 dotnet.native.wasm 超过这个限制。部署方案是只保留 gzip 副本，再用一个小的 loadBootResource 钩子配合 DecompressionStream 在浏览器里解压。

四、怎么用：三条现实建议

1）先确认硬件。 官方建议桌面独显；移动端和集显不在推荐范围。10 GB 权重是可选下载并会缓存，第一次打开会明显更慢。

2）把它当"草稿生成器"，不是"资产生产线"。 输出是约 15 万面的 GLB，带 PBR 贴图，适合概念稿、场景占位、产品页 360 预览；不适合直接做精密零件或需要严格尺寸的模型。生成结果仍要走一遍验收：面数、法线朝向、UV 是否重叠、贴图是否齐全。

3）注意许可证是分层的。 代码是 MIT，但 TRELLIS.2 / DINOv3 / SD Turbo / RMBG-1.4 各有各的许可，权重不随包分发、首次使用时从 Hugging Face 下载。"代码开源"不等于"生成结果可随便商用"，这条在 AI 3D 里尤其容易踩。

五、它改变了什么，没改变什么

改变了：生成 3D 草稿的隐私边界。以前"不上传"只能用本地桌面软件；现在一个标签页就能做到，这对工业、医疗、还没发布的产品设计是实质差别。

没改变：3D 资产能不能交付仍然取决于生成之后的事——拓扑是否干净、尺度是否正确、贴图是否按预期打包、有没有在看不见的面上"发明"结构。这些检查我们此前在 AI 3D 资产的数字验收 和 五项交接检查 里写过，工具换成浏览器也一样要过。

一句话收尾："在浏览器里跑 4B 模型"已经不是演示，而是能用的工程。 下一步的竞争点不在"能不能生成"，而在"生成完的东西，能不能被下游放心接走"。

Sources

• LostBeard, Text to 3D, 100% in the browser: TRELLIS.2 on WebGPU from C#, dev.to, 2026-10-17：https://dev.to/lostbeard/text-to-3d-100-in-the-browser-trellis2-on-webgpu-from-c-21d3
• 演示：https://lostbeard.github.io/SpawnDev.ILGPU.ML/text-to-3d（约 10 GB 权重为可选下载并缓存）
• 源码（MIT）：https://github.com/LostBeard/SpawnDev.ILGPU.ML

同主题阅读

• WAMR3D：Rust→WASM 内核与自研 WebGPU 渲染器的基准
• AI 3D 资产能不能打印：水密≠可交付
• glTF / GLB 完全指南：在线查看、校验与转换

主工具：生成的 GLB 想先看一眼？用在线 3D 模型查看器 直接打开，支持 STL / OBJ / GLB / FBX，文件在浏览器里解析。

本文属于「Web3D / 游戏引擎 / 元宇宙」专题。BimAnt 编译整理，转载请注明出处。文中时间数据为作者单机单次测量，你的显卡与浏览器版本会得到不同结果。

一句话结论：AI 生成 3D 资产的问题，通常不在生成那一刻，而在交接那一刻——文件打开时尺度不对、贴图路径丢了、把"地图上下文"当成可用的生产几何。2026 年 10 月的一份实践记录用一个虚构的美国交通广场场景，把 Meshy（按提示词/图片生成单个模型，可加贴图、绑定、动画）与 Shapezo（从地图选区生成模型）放进同一条管线，给出五项交接检查：文件代表什么、尺度与原点、贴图行为、拓扑与性能、归属与替换路径。结论很实用：两者可以出现在同一个场景里，但不是同一种交付物——把名字叫准、把尺度材质查清、让每个资产可替换，AI 生成才能进入正常生产流程。

披露：本文编译自 generatebuild 的实践文（dev.to，2026-10-16）。作者使用并评述 Shapezo，属于厂商/工具推广内容；文中对比方法（五项检查、manifest、测试资产）可独立复现，具体产品能力请按你自己的版本核对。

一、为什么"交接"比"生成"更容易出事

作者的原话："我通常是在交接时发现建模问题，而不是在模型生成的那一刻。" 文件在错误的尺度下打开、贴图路径丢了、把上下文导出误当成生产几何。

为了把对比做实，作者搭了一个小型的虚构美国游戏环境：一个交通广场。然后：

"生成的上下文"这个标签非常重要：它告诉接收方，建筑和道路边缘对定位有用，但不自动等于已批准的游戏碰撞体或施工数据。这是整篇文章最值钱的一句话。

二、五项交接检查

1. 定义文件代表什么

• Shapezo 的产物标为上下文：用于辨向、体量、周边环境，不是最终美术方向，也不是碰撞/施工数据。
• Meshy 的产物是物件：每个都有独立名字、提示词、源图、修订号。

检查动作：在 manifest 里给每个文件写一行"这是什么、能用来干什么、不能用来干什么"。没有这行，接收方只能猜。

2. 检查尺度与原点

这是最无聊、也最必要的检查。确认：

• 单位制（米 / 厘米 / 英尺）；
• 物体缩放；
• 场景原点；
• 向上轴（Y-up / Z-up）；
• 导出设置。

一个在 Meshy 里看起来正常的售票亭，如果接收引擎以为是厘米而不是米，导入后会巨大。Shapezo 的上下文模型也可能漂移——如果地图导出和游戏场景用了不同的坐标约定。

一个便宜又有效的办法：在导出整个场景之前，先在广场某个已知特征附近放一个小测试资产，导入后量它。作者说这一步能抓住惊人数量的错误。

3. 检查贴图行为

Meshy 的贴图生成在道具需要特定表面时很有用，但仍要检查：

• 图片尺寸；
• 通道使用；
• 命名；
• 相对路径。

优先测 GLB，因为材质包作为一个文件更容易携带；如果管线需要分离材质，再测 FBX 或 OBJ，并确认接收软件找得到贴图。

Shapezo 的上下文表面处理方式不同：保持视觉简单，不要把它的贴图当成最终美术方向。它们的作用是展示体量与周边，近景资产的细节由物件自己承担。

4. 检查拓扑与性能

对每个 Meshy 资产检查：

• 多边形数量；
• 隐藏几何；
• 薄面；
• 碰撞需求。

一个在静帧里好看的模型，作为重复出现的道具可能太重。售票亭或花箱如果出现几十次，就做一个轻量版本。

对 STL / 3MF 输出，还要检查网格是否足够闭合、能不能打印。

Shapezo 的模型做另一种性能决策：可以作为远景保留，也可以把部分建筑替换成简单体块，或者只加载相机区域内的部分。正确做法取决于玩家能看到多少上下文。

5. 检查归属与替换路径

作者维护一份小型 manifest，记录：

• 提示词笔记；
• 生成日期；
• 清理决定；
• 导出/修订版本；
• Shapezo 的上下文版本与地图边界；
• Meshy 的资产级记录。

这样当某个模型变化时，下一个人可以只替换一个对象，而不必重建整个环境。

作者的原话："制作团队很少保留第一个生成版本。" 改材质、减面、移动路缘、替换建筑体块都是常态；能记录这些变化的工作流，才让 AI 生成成为正常生产的一部分，而不是一次性的视觉实验。

三、两类交付物的分工表

四、一个可直接照做的交接清单

在把包交给另一个开发者之前，逐项打勾：

快速目检：把导出的 GLB 丢进 glTF 查看器 看材质与贴图是否完整，再用 3D 查看器 检查朝向、尺度与整体外观。目检不能替代引擎内验证，但能在交接前抓住大多数"打开就不对"的问题。

五、什么时候该把两者放进同一条管线

一句话：AI 生成让"有东西可看"变便宜了，但"能交付"仍然要靠命名、尺度、材质和替换路径这四件事。

Sources

• generatebuild, Meshy vs Shapezo in a Production Pipeline: Five Handoff Checks, dev.to, 2026-10-16：https://dev.to/generatebuild/meshy-vs-shapezo-in-a-production-pipeline-five-handoff-checks-4dih

同主题阅读

• AI 3D 资产的数字验收：水密≠可打印
• 渲染前后的支撑检查：44 行射线探针与网格体检
• glTF / GLB 完全指南：在线查看、校验与转换

本文属于「AI × 3D / 生成式 AI」专题。BimAnt 编译整理，转载请注明出处。文中工具对比含厂商推广成分，请按实际版本与授权自行核对。

一句话结论：three.js 场景一旦上到几千个动态对象，帧预算常常花在 JavaScript 的对象更新、矩阵运算和把 draw call 交给 GPU 上。2026 年 10 月出现的开源引擎 WAMR3D 换了个分工：把场景图、世界矩阵、视锥剔除、绘制排序、射线检测放进用 Rust 编译的 WebAssembly 内核，再配一套从零写的 WebGPU 渲染器，外层保留一套读起来像 three.js 的 API。作者公布的基准里，10,000 个独立动画网格 @1920×1080：WAMR3D 两种 API 都跑满 60 fps、CPU 提交约 12.2–12.3 ms；three.js WebGPU 9.5 fps / 100.5 ms，three.js WebGL 33.7 fps / 23.7 ms。同一份基准也写了反面：细粒度小调用比 three.js 慢 1.3–3.8 倍。

披露：本文编译自 WAMR3D 作者 Aymen 的发布文（dev.to，2026-10-14）。作者是引擎维护者；基准来自其仓库记录（单机、单次、中位数），文中的所有性能数字都应按你自己的场景复测。

一、它是什么：不是 three.js 的包装

WAMR3D 是一个 WebAssembly 3D 渲染引擎：Rust 内核 + 独立的 WebGPU 渲染器。它不是 three.js 的封装，也不是成熟的替代品——项目很年轻，README 自己就这么写。

三个组成部分：

许可 MIT，无运行时依赖，Wasm 模块约 488 KiB。

二、为什么把内核放进 Wasm

在大多数 three.js 应用里，场景状态存在于 JavaScript 对象上。每一次 position.set()、rotation.y +=、矩阵更新都是 JS 的工作，垃圾回收最终会介入。

WAMR3D 的做法不同：

• 场景存在引擎内存里。 对象在 WebAssembly 里显式创建和销毁，引擎本身不引入 GC 暂停。
• 分代句柄（generational handles）。 指向已销毁对象的句柄，不会悄悄指向另一个对象。
• 零拷贝几何。 通过 typed array 视图直接读写引擎内存中的顶点属性。
• 批量同步。 对象 API 里 position/rotation/scale 仍留在 JS，但每帧把改动一次性发送给引擎。

结果是一个明确的取舍：批量工作时 WAMR3D 赢，大量细碎调用时它输。项目把两面都写进了文档。

三、基准：先看清条件

数字来自仓库的基准记录，2026-10-14，headless Chrome、Windows x64、RTX 2070 SUPER，每种分辨率单次运行的中位数。作者明确说：这只是起点，请在自己的场景里测。

10,000 个独立动画网格 @1920×1080

50,000 个实例化物体，场景在 CPU 上更新

换成作者的话：在这个 showcase 里，WAMR3D 的 draw 提交 CPU 时间大约是 three.js WebGPU 的 1/8、three.js WebGL 的 1/1.9。帧率封顶 60 是 showcase 的显示限制。

反面：小调用更慢

项目也公布了另一面：做很少工作的调用（例如单次向量运算、一次改一个属性），比 three.js 慢 1.3 到 3.8 倍，因为进入 WebAssembly 有固定开销。GPU 时间没有单独测，只体现在帧率里。

读法：这不是"全面更快"，而是"批量提交快、单点调用慢"。你的场景越像"几万个对象、每帧整体更新"，越适合；越像"每帧对几十个对象做几百次细粒度 getter/setter"，越不适合。

四、正确性：7,600 个对照用例

速度只有在输出正确时才有意义。WAMR3D 用 three.js r186 源码生成的 7,600 多个参照用例回归它的 Rust 实现：

• 单个操作的结果一致到约百万分之一；
• 23 个渲染器测试用例与保存的 three.js 图像逐像素比对；
• 643 个 Rust 测试覆盖单元、行为一致性（parity）与内存分配；
• 仓库还有一个视觉一致性页面，把 WAMR3D 渲染结果、three.js 图像和像素差异并排显示。

这套做法的价值在于："像 three.js"不是口头承诺，而是可回归的对照。它也划出了边界——对照的是 three.js r186 的语义，不是所有 three.js 生态插件。

五、两分钟上手

npm install wamr3d

改 import、初始化一次、切到 WebGPU 渲染器：

- import * as THREE from 'three';
+ import * as THREE from 'wamr3d/compat';
+ await THREE.init();

- const renderer = new THREE.WebGLRenderer({ antialias: true });
+ const renderer = new THREE.WebGPURenderer({ antialias: true });
+ await renderer.init();

一个完整例子：

import * as WAMR3D from 'wamr3d/compat';

await WAMR3D.init();

const scene = new WAMR3D.Scene();
const camera = new WAMR3D.PerspectiveCamera(50, innerWidth / innerHeight, 0.1, 100);
camera.position.set(3, 2, 5);
camera.lookAt(0, 0, 0);

const cube = new WAMR3D.Mesh(
  new WAMR3D.BoxGeometry(),
  new WAMR3D.MeshLambertMaterial({ color: 0x4f8cff })
);
scene.add(cube, new WAMR3D.DirectionalLight(0xffffff, 2));

const renderer = new WAMR3D.WebGPURenderer({ antialias: true });
await renderer.init();
renderer.setSize(innerWidth, innerHeight);
document.body.appendChild(renderer.domElement);

renderer.setAnimationLoop((time) => {
  cube.rotation.y = time / 1000;
  renderer.render(scene, camera);
});

对 WAMR3D 支持的类，scene.add、position.set、rotation.y +=、lookAt、射线检测都按原样工作。迁移指南列出了具体有哪些类、要注意什么。

要求：支持 WebGPU 的浏览器（当前 Chrome 或 Edge），通过 HTTP 而不是 file:// 提供页面；Node.js 18+ 可以在没有渲染器的情况下跑数学与场景图。

六、大场景用批量 API

对象超过几百个之后，收益主要来自批量 API：句柄与 setRotations 之类的调用一次跨进 WebAssembly，更新成千上万个对象；世界矩阵通过 typed array 视图读取，不复制。

低层 API 直接从 wamr3d 导出：

import { init, World } from 'wamr3d';

await init();

const world = new World();
const scene = world.createObject();
const arm = world.createObject();
const hand = world.createObject();
world.add(scene, arm);
world.add(arm, hand);

world.setPosition(arm, 10, 0, 0);
world.setRotation(arm, 0, 0, Math.PI / 2, 'XYZ');
world.setPosition(hand, 1, 0, 0);

world.updateMatrixWorld(scene, false);
console.log(world.matrixWorld(hand)); // Float32Array(16), column-major

七、什么时候选它，什么时候别选

八、一个可复现的评估流程

1. 先跑官方 showcase（wamr3d.org/examples/showcase），四种渲染器同页对比，确认在你的机器上确实有差距。
2. 换成你自己的模型：GLB 走一遍加载、材质、阴影、实例化。可以先用 glTF 查看器 确认模型本身没有材质/贴图问题，再进引擎。
3. 记录三个数：draw 提交 CPU 时间、场景更新 CPU 时间、帧率；同时记分辨率、对象数、是否实例化。
4. 测最差路径：每帧对单个对象做几十次属性读写，看是否掉到 three.js 以下。
5. 验收视觉：把同一相机角度的渲染结果与 three.js 对比；必要时用 3D 查看器 打开源模型作为参照。
6. 确认部署条件：WebGPU 可用性、页面必须走 HTTP(S)、Wasm 488 KiB 的加载预算。

九、结论

WAMR3D 的价值不在于"打败 three.js"，而在于把 Web 3D 的性能瓶颈换个位置：把每帧的 JavaScript 场景管理搬进 Wasm，把绘制交给自研 WebGPU 渲染器，用 60 fps vs 9.5 fps 这类数字证明路线可行；同时用 小调用慢 1.3–3.8 倍 提醒你它不是万能。

如果你的项目是"大场景 + 批量更新 + 愿意接受年轻引擎"，它值得一个下午的实测；如果你要的是"成熟生态 + 细粒度控制 + 全平台兼容"，three.js 仍然是更稳的默认选项。

Sources

• Aymen, WAMR3D: A Native WebAssembly 3D Engine with a three.js-Style API and Its Own WebGPU Renderer, dev.to, 2026-10-14：https://dev.to/aymen94/wamr3d-a-native-webassembly-3d-engine-with-a-threejs-style-api-and-its-own-webgpu-renderer-9ok
• 官网 / 基准展示：https://wamr3d.org/ ｜ 仓库：https://github.com/aymen94/wamr3d

同主题阅读

• CAD STEP 到网格的拓扑验收：缝合公差与六步检查
• glTF / GLB 完全指南：在线查看、校验与转换
• Blender MCP 与云渲染：两条路线与成本

本文属于「Web3D / 游戏引擎」专题。BimAnt 编译整理，转载请注明出处。基准为单机单次中位数，实际性能请以你的场景复测为准。

一句话结论：从 Printables / Thingiverse 下载一个支架 STL，想把其中一个孔放大 2 mm，你会发现没有"孔"可改——STL 只是一堆三角面，CAD 把它读成成千上万个碎面。2026 年 10 月开源的 mesh2cad 专门解决这类简单机械件：它从三角面里找出平面、圆柱、球、圆锥，生成真正的 B-rep STEP；对简单的板类零件，还能输出一份每个尺寸都是命名变量的 CadQuery 脚本——把 hole_1_d = 6.0 改成 8.0，重跑脚本就得到新的 STEP。它还提供一个诚实的失败模式：拟合不出来就什么都不写，并告诉你原因。

披露：本文编译自 mesh2cad 作者 Emir Mrkaljević 的发布文（dev.to，2026-10-16）。作者是工具维护者，基准数据与限制均来自其公开 README 与自测；文中所有数字以其仓库记录为准，建议按自己的零件复测。

一、问题：STL 里没有"孔"

下载的支架、法兰、外壳，通常只有 STL。CAD 打开它，得到的是：

• 平面被切成很多狭长三角面；
• 圆孔变成一圈多边形；
• 圆柱面是几十条窄带；
• 没有特征树、没有草图、没有可编辑的孔径参数。

于是"把孔放大 2 mm"这件事，在传统流程里只有三条路：

mesh2cad 走的是第四条：把三角面重新拟合回解析曲面，再缝合成实体。

二、它到底做什么

输入 STL / OBJ / PLY，输出：

1. B-rep STEP：可以进任意 CAD/CAM；
2. 参数化 CadQuery 脚本（仅简单板类件）：每个尺寸是命名变量，改完重跑即生成新 STEP；
3. 一份报告：双边 Hausdorff、RMS 偏差、体积误差，以及本次用的是精确 B-rep 还是回退的 faceted solid。

命令行：

pip install mesh2cad
mesh2cad convert part.stl -o part.step --tol 0.1 --report report.md

--tol 0.1 是拟合容差（毫米）。孔径的"取整"也受它约束：

取整后仍能落在 --tol 内5.9976.0

生成的参数段长这样：

# --- parameters ---
base_x           = 40.0  # base length (X)
base_y           = 30.0  # base width (Y)
base_t           = 6.0   # base thickness (Z)
hole_1_d         = 6.0   # diameter
hole_1_csk_d     = 12.0  # countersink diameter
hole_1_csk_angle = 90.0  # countersink angle

把 hole_1_d 改成 8.0，python bracket.py，得到新 STEP。在脚本写出来之前，mesh2cad 会先运行它，并把结果与输入网格比对；如果零件不符合支持的形状，或脚本结果偏离网格，它什么都不写，并告诉你为什么。 作者的原话是："我宁愿拒绝，也不愿给你一份看起来对、其实不对的脚本。"

三、五步原理

四、噪声下的基准：0.2 mm 是什么水平

真实扫描与导出的网格都有噪声，所以作者用已知真值的 CadQuery 零件做基准：先离散化，再叠加高斯顶点噪声，每个用例跑 3 个随机种子，取最差的一次。

两个值得记住的细节：

1. 窄圆锥最难。 0.2 mm 噪声下，2 mm 倒角或沉头会碎成一圈平面条带，圆锥拟合器根本看不到圆锥。0.4.2 版把这些条带重新聚成一个圆锥，并锁定到相邻孔/凸台的轴线上——带倒角凸台现在在 0.2 mm 噪声、3 个种子上都精确。
2. 90° 沉头在 0.2 mm 噪声下只有 1/3 种子精确。 另外两个种子得到的是有效的 faceted solid，不是解析曲面。这不是"失败"，而是报告会告诉你的降级——能不能接受，取决于你要拿它做什么。

五、四条限制（作者自己列的）

• 只支持平面、圆柱、球、圆锥。 没有圆角，没有自由曲面——有机模型和大多数手办不在范围内。
• 圆柱必须在垂直于其轴线的平面上结束（通孔、凸台、销）。
• CadQuery 脚本路径只覆盖 Z 向上的盒/板 + 凸台、竖直孔、竖直凸台。 其它形状只给 STEP。
• 沉头在 0.2 mm 噪声下不保证解析精确（见上表）。

这四条决定了它适合什么：支架、法兰、垫块、简单外壳、带孔板件这类"工程件"；不适合人物、雕塑、有机曲面。

六、从 AI 助手里调用：MCP

mesh2cad 同时是一个 MCP 服务器，Claude Desktop、Cursor 或任意 MCP 客户端可以调用 convert、analyze、report、to_cadquery：

{ "mcpServers": { "mesh2cad": { "command": "mesh2cad", "args": ["mcp"] } } }

安装：pip install "mesh2cad[mcp]"。

这意味着一个常见工作流可以变成：Agent 拿到 STL → 调 analyze 看拟合可行性 → 调 convert 出 STEP → 调 report 读偏差 → 你只做验收。但要注意：这仍然是几何转换，不是"AI 帮你改设计"；改参数、判断装配是否合理，仍然要人。

七、收到 STEP 之后：验收清单

转换工具最容易骗人的地方，是"文件能打开"被当成"转换正确"。建议按下面顺序验收：

在浏览器里快速看一眼：把生成的 STEP 或原始 STL 丢进 CAD 查看器 检查外形与孔位；如果是打印件，再用 3D 查看器 看网格是否有翻面、非流形边。浏览器查看不能替代 CAD 校验，但能在三十秒内发现"孔变成六边形""单位错十倍"这类明显问题。

八、和另外两条路线怎么选

一句话：mesh2cad 把"重画一遍"变成"改几个变量"，代价是它只认四类解析曲面，并且会在做不到时明确拒绝。

Sources

• Emir Mrkaljević, Turning an STL back into editable CAD: fitting planes, cylinders and cones to noisy meshes in Python, dev.to, 2026-10-16：https://dev.to/emirmrkaljevic/turning-an-stl-back-into-editable-cad-fitting-planes-cylinders-and-cones-to-noisy-meshes-in-python-2eia
• 仓库与完整基准：https://github.com/emirmrkaljevic/mesh2cad

同主题阅读

• CAD STEP 到网格的拓扑验收：缝合公差与六步检查
• 水密≠可打印：AI 3D 资产的数字验收
• 图纸不上传：DWG 版本自查与照片元数据清理

本文属于「CAD / 制造」专题。BimAnt 编译整理，转载请注明出处。转换结果与公差是否可接受，需按你的零件与下游工序自行验收。

按格式打开：STL 在线查看（浏览器直接打开，不上传服务器）