4 ms·

> Opus 5 is just as good for this tbh and cheaper. It depends on the fidelity, there's a threshold slightly over "low poly" that Opus cannot get over. Once you

by avaer 14d ago

> Opus 5 is just as good for this tbh and cheaper. It depends on the fidelity, there's a threshold slightly over "low poly" that Opus cannot get over. Once you get into creating foliage l-systems, or physical mob animation, or a house with realistic appliances, Opus is under the convergence threshold for a world model no matter how much time you give it, it will flail around and say it's done even though it's nowhere close to plausible. Fable takes forever but knows how to zoom in and out on the abstractions. > They don't generate optimized 3d models. They have high poly count for simple geometries. By default LLMs will do the quick prototype thing and slap some primitives into a THREE.js scene. Which is probably correct because most users don't know or care. But if prompted Fable will connect the manifolds/sculpt with a mesher, instance out the pieces, etc. and make you an efficient art pipeline. You can make it optimized. Just not in 10 minutes. > A better approach I've utilized for game ready assets is to use the model to create low poly silhouettes You can also let Meshy make the geo and then fit it back to the world with PCA + BB's. Diffusion models are still 10x better at making physically plausible geometries than LLMs, plus they are faster all things considered. One technique I've found that works well is socketing; let the LLM generate the high level structure with blockouts for sockets, then slot in the higher poly objects that fit. Which is closer to the professional approach for world design.

kodefreeze 14d ago
> then fit it back to the world with PCA + BB's Can you expand on this? I've tried several AI 3d generators that claim low-poly output, and they're all far off. None of them decide what belongs in the mesh vs. what should be baked in with the texture, so the poly budget lands in the wrong places.
- Intermernet 14d ago
  This seemed to have been accidentally downvoted to death. Just vouched for it, as it's a normal comment
- avaer 14d ago
  What I'm suggesting is if you want a certain semantic part of the scene to have a specific design or fidelity (say an interactive object, point of interest, character, or parts thereof), you can generate it via image and then use principal component analysis, bounding boxes, and a physics engine like Jolt to place and orient it programmatically into the right "socket" in your world so it aligns and joins correctly. The LLM can generate the high level spatial/semantic structure, and you can plug the assets into the right space. That works both at scene level and more locally (say a character's equipment they are wearing or holding). This kind of decomposition helps to get the art composed the way you want it, though it won't help with a runtime poly budget. But if you are intentionally doing low-poly style, it is doubtful you are (at least technologically) limited by having too many vertices on assets; you're limited by draws and submits and rendering architecture. You can push millions of animated polys with bells and whistles, postprocessing, physics etc, in the browser, at 90 FPS, on a macbook. You can have thousands of objects, but you have to cull/instance/share materials/atlas/etc, you can't just do `new THREE.Mesh` for each object -- which is what the LLMs will naively do by default unless you ask otherwise. If resource size is a problem, meshes compress/quantize well with things like meshopt/DRACO.

by avaer 14d ago

kodefreeze 14d ago

> then fit it back to the world with PCA + BB's Can you expand on this? I've tried several AI 3d generators that claim low-poly output, and they're all far off. None of them decide what belongs in the mesh vs. what should be baked in with the texture, so the poly budget lands in the wrong places.

Intermernet 14d ago
This seemed to have been accidentally downvoted to death. Just vouched for it, as it's a normal comment
avaer 14d ago
What I'm suggesting is if you want a certain semantic part of the scene to have a specific design or fidelity (say an interactive object, point of interest, character, or parts thereof), you can generate it via image and then use principal component analysis, bounding boxes, and a physics engine like Jolt to place and orient it programmatically into the right "socket" in your world so it aligns and joins correctly. The LLM can generate the high level spatial/semantic structure, and you can plug the assets into the right space. That works both at scene level and more locally (say a character's equipment they are wearing or holding). This kind of decomposition helps to get the art composed the way you want it, though it won't help with a runtime poly budget. But if you are intentionally doing low-poly style, it is doubtful you are (at least technologically) limited by having too many vertices on assets; you're limited by draws and submits and rendering architecture. You can push millions of animated polys with bells and whistles, postprocessing, physics etc, in the browser, at 90 FPS, on a macbook. You can have thousands of objects, but you have to cull/instance/share materials/atlas/etc, you can't just do `new THREE.Mesh` for each object -- which is what the LLMs will naively do by default unless you ask otherwise. If resource size is a problem, meshes compress/quantize well with things like meshopt/DRACO.