Meshy AI 图生3D实测：网格更粗糙，输在哪？

一张图能变成3D模型吗？我拿同一个Voronoi蛋壳图片，分别跑完Meshy和SupaVoxel，然后放入同一离线浏览器、相同灯光、相同相机角度逐一对比。结论直接说：这次Meshy 61分，SupaVoxel 90分。

Meshy AI 图生3D实测对比

每项评分都是主观的，只针对这一个任务。但下面这些数字，全部来自两个工具自己的导出文件。

谁更还原原图？

从正面看，两个都过关。多孔外壳、交错骨架、蛋形轮廓——Meshy和SupaVoxel都抓住了照片里的物体。缩略图下，你可能分不出胜负。

这是诚实的基线。参考图能证明的是正面像不像，不能证明背面、内部、壁厚或颜色准不准——因为照片里没有这些信息，我也没测量。

值得一提的是，Meshy和SupaVoxel都导出GLB格式。几何和图片打包在一起，所以下面的差异不是格式带来的。

GLB（Graphics Language Binary） 是 glTF 2.0 规范的二进制封装格式，由 Khronos Group 维护，被称为“3D 界的 JPEG”。它把场景结构、几何网格、材质定义、贴图与动画打包进单个 .glb 文件，避免 .gltf + .bin + 纹理 多文件散落的问题。与 OBJ、FBX 等传统格式相比，GLB 对 PBR 材质、顶点压缩扩展和运行时加载更友好，因此被 Three.js、Babylon.js、Unity、Unreal 以及各类在线查看器广泛支持。

在实际使用中，GLB 的关键优势是“自包含”：几何和图片同处一个容器，导出后不会出现贴图丢失。但这也意味着文件大小同时受网格精度和纹理体积影响——本例中 Meshy 与 SupaVoxel 均为 GLB，因此 27.4MB 对 9.0MB 的差异不能归因于格式，而只能来自网格与贴图本身。此外，GLB 支持 extensionsUsed / extensionsRequired 字段声明扩展，接收端若无法识别必需扩展就会拒绝或降级加载，这正是后文解码器问题的根源。

网格密度决定肋条清晰度

放大之后，平局结束。

Meshy的肋条更宽、更钝，缝隙更少更圆。SupaVoxel的肋条网络在同样放大倍数下保留了更多结构。数字支撑这个观感：

指标	Meshy	SupaVoxel
三角形数	779,020	1,500,000
角点数	424,152	865,508
120mm高度下平均边长	0.306 mm	0.295 mm

每根肋条都是一根细细的扭转管。两倍的三角形意味着两倍的切面来保持管状圆润。Meshy用一半的材料描述同一个形状。

对于0.4mm的打印喷嘴，0.306mm的步长是更粗糙的曲线描述——在肋条只有几颗珠子厚的灯罩上，这就是棱角最先暴露的地方。

渲染图和三角形数量说的完全是一回事，这也是我敢信任任何一方的唯一原因。

背面全靠编——谁也没法验证

这是图生3D评测很少明说的事实：你的图片只展示了一面，背面全是编造的——Meshy编，SupaVoxel也编。没有参考物，所以当Meshy的背面看起来可信时，那是“合理”，不是“准确”。SupaVoxel同理。

能测的是：两个文件在清理后都完全封闭——零开放边、没有三个面共享的边、表面方向一致、各自一个连通壳体。没有哪一个是带洞的空壳。这一点是实测的，其余都是想象，两边都一样。

有个意外的细节：清理前，Meshy报告67,946条松散边，SupaVoxel报告225,446条。这些都是把平面图片包裹到3D形状上的接缝记账，合并同位置点后全部消失。别被某些查看器里的原始边计数吓到。

开放边（open edge） 指只被一个三角形使用的边，通常意味着网格表面存在裂缝或孔洞；流形（manifold） 则要求每条边恰好被两个三角形共享、每个顶点邻域可展平为圆盘。非流形几何——比如三个或更多面共享同一条边——会让切片软件和有限元工具无法判断“哪一侧是实体内部”，从而产生错误或直接报错。

松散边（loose edge） 是不属于任何三角形的孤立边，常由图片包裹到 3D 曲面时的接缝记账产生。它们不构成实体，但在某些查看器的统计面板里会显示为惊人的数字，容易让人误判模型质量。合并同位置顶点（weld vertices）后，这些接缝边通常全部消失。因此评估一个图生 3D 模型是否“可用”时，真正该看的是清理后的开放边、非流形边数量和连通壳体数，而不是原始松散边计数。

文件大小：Meshy重了三倍

指标	Meshy	SupaVoxel
导出文件大小	27,408,396字节	9,044,340字节
屏幕专用贴图	2,826,340字节	235,772字节
颜色图片	1,658,610字节	519,966字节
纹理数量	3	3

两者都带了3张纹理图，平局。但重量差远了。Meshy的两张屏幕专用贴图（凹凸细节和光泽）加起来2,826,340字节，而SupaVoxel只有235,772。对于纯打印来说，这是12倍的无用负载。

加上颜色图片，Meshy的文件里图片占4,484,950字节，SupaVoxel占755,738字节——分别占各自文件的16.4%和8.4%。这说明：Meshy的体量不是纹理撑起来的，其余全是未压缩的网格数据。

如果放在网页上旋转展示，12Mbps手机连接下，Meshy要等18.3秒，SupaVoxel等6.0秒。100Mbps下是2.19秒对0.72秒。这些是按字节数算的算术，不是实测页面加载。

加载后排名反转：按每点32字节、每索引4字节估算，Meshy几何在内存中约占22.9MB，SupaVoxel约45.7MB。压缩缩小的是下载量，不是加载后的网格。同样是算术，不是实测内存。

Meshy的版本只有在没人需要下载的时候才更漂亮。

EXT_meshopt_compression 是 glTF 的几何压缩扩展，由 meshoptimizer 项目提供，可对顶点属性、索引和动画数据做有损或无损压缩，显著减小 GLB 体积。它通常与 KHR_mesh_quantization 配合使用：后者把 32 位浮点坐标量化成 16 位甚至 8 位整数，进一步缩小数据量，代价是引入极小的精度误差。

这两个扩展属于“必需扩展”（required extensions），声明在 GLB 的 extensionsRequired 字段。支持它们的加载器（如 Three.js 的 GLTFLoader 配合 meshopt_decoder）能透明解压；不支持的接收端则会直接拒绝加载或抛出错误。因此压缩 GLB 在网页传输场景下胜出，但在需要最大化兼容性的离线管线、老旧引擎或严格校验环境中，原始尺寸导出仍是更稳妥的选择。本例中 SupaVoxel 同时输出了压缩版和原始版，正是为了兼顾这两类下游。

Meshy真正赢的地方

两行，都真实。

颜色数据更多。 Meshy的颜色图1,658,610字节，SupaVoxel的519,966字节。同一灯罩，三倍多的颜色数据。如果你要的是屏幕上的丰富纹理模型，更多颜色信息是正确方向。但我必须说实话——我没测量任何一方的颜色准确度。所以我能说的是Meshy的颜色图“更大”，不是“更好”。

网格更干净。 会让修复软件头疼的拉伸细长三角形，Meshy有419个，SupaVoxel有2,849个。Meshy也没有退化、近零面积的面，SupaVoxel有两个。部分原因是简单的算术——更多三角形，更多变细长的机会——但如果你的工作流过一遍挑剔的清理步骤，Meshy给你的文件更好处理。

第三点不是外观问题：Meshy的GLB声明没有必需扩展，SupaVoxel的压缩GLB声明了EXT_meshopt_compression和KHR_mesh_quantization，接收端程序需要解码器。SupaVoxel那边切换到原始尺寸导出，解码器问题就消失了——同一次运行已经生成了两个文件，一个给网页，一个给拒绝解码的环境。

渲染图不能告诉你的事

没有颜色测量，没有两模型之间的像素级配准，没有纹理分辨率，没有切片、壁厚或实际打印。

还有两个空白：两次运行都没有记录失败或重试次数，Meshy的生成时间完全没有捕获。SupaVoxel的记录是274.715秒，Meshy是空白，所以本文没有任何速度主张。

列出这些缺口，是因为可视化文章最容易让印象冒充测量。这里所有数字都来自Meshy和SupaVoxel的文件，所有视觉都是你可以用自己眼睛判断的、标注了相机参数的渲染图。

最终判决

Meshy把一个图片变成了可辨认的Voronoi蛋壳，四周完全封闭，从每个拍摄角度都能看清网格。任务完成了，这不简单。

但Meshy用了少48%的三角形和更粗糙的平均边长，所以每个特写里Meshy的肋条都更钝。Meshy带来了三倍多的颜色数据，如果灯罩放在屏幕上而不是打印板上，这是真实优势。

我的要放在打印板上。所以这次我保留了SupaVoxel的1,500,000三角形模型——压缩版给网页，同一运行的原始尺寸GLB给更挑剔的用途。

但别把我的蛋壳当成你的答案。拿你自己的图片跑一遍Meshy和SupaVoxel，自己看裁剪对比。不同物体会表现不同，一次运行就是一次运行。