照着一张生成图做杯托：改用图片转 3D，绕开手工建模

接手一个做到一半的汽车出风口杯托。前一个 agent 在 ANSYS 里手搓的参数化模型和谷歌那张渲染图对不上，细节全丢。重做的思路是别在 CAD 里照图重画，改用图片转 3D 把生成图直接变成高细节网格，再在网格上做手术、逆向成实体、上有限元。顺手还拿两个生图模型做了个受力对照。

封面：汽车出风口杯托的产品渲染图，筒形杯体、竖槽、两个带齿挂钩、立柱和支撑脚 — 图 0：项目里的产品渲染图（nano banana 2 生成，不是实拍，也不是仿真结果），裁成 16:10 作封面。

这个汽车出风口杯托是另一个 agent（agy）做了一半交过来的。问题很直接：agy 在 ANSYS 里手搓了一个参数化模型，拿去和谷歌那张渲染图一比，「一点都不像」——齿纹挂钩、杯身的竖槽、沿口的小孔、那些圆角和浮雕，在手工建模里几乎全丢了。用户的定调就一句：重做，尽最大努力。

重做的关键不是把模型画得更细，而是换条路：别再在 CAD 里照着图一笔一笔重画，而是用图片转 3D 把那张生成图直接变成一个高细节网格，再在网格上做手术。

手工建模为什么对不上图

参数化建模的底子是基元：圆柱、盒子、倒角、拉伸。用这套东西去还原一张 AI 渲染图里的有机形状，先天就费劲——带齿的 C 形挂钩、杯身一圈竖槽、沿口浮雕式的过渡，拼基元拼不出来，硬拼出来也是「细节很差」的盒子。用户当时的描述是「照着 nano banana 2 生成的图，画出的 ANSYS，缺失大量细节」。

所以起点其实是承认手工这条路不划算，换工具。

从生成图到能仿真的实体：整条管线 — 图 1：正线是「渲染图 → 图片转 3D → 网格手术 → 逆向实体 / 有限元」；下面灰掉的是被废弃的手工参数化路线——本项目就是因为那条路行不通才换的。

图片转 3D：Tripo 的钱包坑，改走在线版

第一反应是找专用工具——rodin、Tripo 这类图生 3D 的服务，出来的结构细节比手搓强得多。先试了 Tripo3D 的 API，结果直接 403 "not enough credit"。排查下来是个容易踩的坑：Tripo 网页版的 credit 和 API 钱包不是一个池子，网页版当时有 500 credit，API 钱包却是 0，image_to_model 自然没额度。要走 API 得单独给 API 钱包充值。

于是改走在线生成后下载：用混元在线版把那张 nano banana 2 的渲染图转成 CUP.stl，约 150 万面、水密。这里还有一条硬规矩——不在这台机器上部署混元这类图生 3D 大模型。之前顺手下过混元权重和 CUDA 版 PyTorch，用户要求全删（连 pip 缓存一起清了约 25 GB），往后图生 3D 一律走在线服务，本地只留管线来处理下载回来的 STL/GLB。

网格到手之后：做手术，不是重画

水密的 150 万面网格直接拿去仿真是不行的，要先收拾。这一段是几个小脚本串起来的：

prep_mesh.py：把网格转正、按「体外径定到 80mm」定标，顺便量出各处特征写进 cup_dims.json。顺带说一句，中途一度纠结要不要把它做成水密体，用户直接点醒——「这是杯托，不是杯子」，杯托本就是镂空带槽的，不该强求水密。
round_mouth.py：杯口本该是正圆，但生成网格的内口有约 1.2 mm 的径向偏差。这个脚本做「内口圆整化」手术，把偏差压到 0，而其余细节零损伤——对应用户那句「注意杯托口是圆的」。

收拾干净的基准网格再分两支走：一支进 SpaceClaim（无头模式）逆向成实体 CAD，导出 .x_t / .stp；一支用 pymeshfix 修表面、tetgen 生二阶四面体、转 CDB 喂给 MAPDL 做有限元。

混元网格在 pyvista 里的重建 — 图 2：图片转 3D 得到的网格在 pyvista 里的样子——竖槽、带齿挂钩、立柱、支撑脚都在，和渲染图对得上，这正是手工建模丢掉的那些细节。

工况和结果

材料按 PC/ABS 算：E=2400 MPa、ν=0.38、ρ=1.15e-9 t/mm³，单位统一 mm-N-MPa。约束是挂钩孔固定 + 脚垫背面 UY=0；载荷是重力 + 5 N 的饮料重量 + 上部内壁径向撑开 1.5 mm（模拟硬塞一个大杯）。首轮算出来最大变形 2.53 mm、p99 应力 38.9 MPa；把内口圆整化之后再算，降到 2.43 mm / 36.3 MPa。

nano banana 2 版杯托的总变形云图 — 图 3：圆口优化后这一版的总变形云图，MAPDL 读数 DMX=2.426 mm。挂钩一侧（蓝）固定，杯身受力处变形最大。

顺手做的一个对照：两个生图模型谁更「懂受力」

做完正线，用户起了个念头——「用 codex 同样的提示词，生成一张图看看」。于是先去 agy 的对话记录里考古，把当年喂给 nano banana 2 的那段原始英文提示词挖出来，再用 codex CLI（内置生图）用同一段提示词生成 codex_render.png，同样走混元转成 codex.stl，再上同一条管线、同一个工况仿真。

结果挺有意思：codex 这版最大变形 5.03 mm，差不多是 nano banana 2 版（2.43 mm）的两倍，整个杯子绕着那段细颈连接处摆。拆开看是结构差异——codex/GPT 那版画的是 J 形挂钩 + 双层壁 + 小脚垫，而 nano banana 2 画的是 C 形挂钩 + 全高背板。后者在受力上明显更合理。

codex 版杯托的总变形云图 — 图 4：同款提示词、codex 生图、同一条管线和工况跑出来的变形，比 nano banana 2 版大了近一倍。结论：至少做结构件，nano banana 2 对「受力」的理解更靠谱。

机器、坑、以及做到哪

算得快是因为硬件压得住：这台机器 14 物理核 + RTX A5500，而且有 ANSYS HPC 许可证，所以 MAPDL 显式给了 nproc=12、挂 A5500 做 GPU 加速（pymapdl 默认只给 2 核，不手动指定就白搭）。GPU 优先级也被钉死成独显 > 多核 CPU > 绝不用核显——用户在这点上反复强调过。一路上的环境坑都收在项目 memory 里（SpaceClaim 把 STL 当英寸读、MAPDL 布尔运算复用已删除的体编号、崩溃后留 file.lock、PNG 驱动有一帧缓冲滞后……），和主线无关就不展开了。

做到哪为止：nano banana 2 和 codex 两版都跑完了仿真、都导出了实体 CAD，手里有了可比的数字，和一套「渲染图 → 图片转 3D → 网格手术 → 仿真 / 逆向」能复用的流程。没做的也说清楚——后续的热 / 结构、控制那些工况没开；这套杯托是不是最终形态、还要不要继续优化，得用户来定。

最后交代事实边界：这两天的会话全文没留下来，上面的数字和步骤来自项目 memory、本地文件和脚本；封面那张是 AI 生成的渲染图（图注已注明），不是实拍、也不是仿真结果。