Live data from Hacker News

Code-native generation of highly programmable 3D assets (2026)

arxiv.org

41–42 of 42 posts

Re: Code-native generation of highly programmable 3D assets (2026)

#41
post #10
post #2

I co-authored this paper. It's a new technique to generate 3D graphics as source code instead of a point cloud. Under the hood, it generates 3D objects with separate, sophisticated internal assembly, producing an editable "kit of parts" (instead of monolithic blobs). E.g. imagine you generated a 3D washing machine via this approach. It's not merely going to be just "geometry" that looks like a washing machine. We act…

Have you explored optimizing the assets to be game-ready? This kind of decomposition works if you have a single object on screen, and it's super artist + programmer friendly. But the generated assets have ~50 mesh parts, which means importing just a couple of these into a scene and you've blown your entire draw call budget for a shippable game; once you start adding things like shadowing it's game over. It's the bric…

If all of these meshes use the same shader (which they do, its just PBR) they can be all drawn with a single multidraw indirect call.

Edit: thinking more about it, since the objects are small they could be rendered with mesh shaders achieving further perf improvements. Also fine grained decomposition helps with culling. IMO the real problem is that rendering in game engines does not map well to modern hardware. Unreal engine went full software rendering with nanite replacing the whole pipeline (which brings significant drawbacks) and everyone else is using graphics with techniques 15 years out of date which leads to this mismatch between what is possible with hardware and what is good practice with game engines.

Re: Code-native generation of highly programmable 3D assets (2026)

#42
I was thinking about this approach, and this paper basically validates it.

The inference cost must be extremely high compared to diffusion based approaches. I wonder if this would ever be useful for more organic sculpting type workflows. E.g. for organic non-hard surface models, use a diffusion model for generation, and leverage this LLM codegen and tool call approach for retopology and cleanup.

Post reply on HN