Live data from Hacker News

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

arxiv.org

11–20 of 42 posts

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

#11
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…

Cool. Do the individual parts still use point clouds? Or are they meshes or CSG?

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

#12
post #6
post #4

Earlier quoted context omitted.

GameCube-era game (with full synchronous multiplayer play): 1-2 quarters. Early "self-generating" Metaverse: ~ 3-6 quarters. The Matrix: ~5-7 years

I am doubtful about the timeline. Not because AI can't do it; it totally can. LLMs have been able to run the full artist + code pipeline at least since the beginning of the year. I've built several physics-synced network simulation stacks without reading a single line of code. Agents playtest my games overnight and I wake up to a list of technical issues fixed, and FPS boosted. If you know how to ask the shaders will…

> Agents playtest my games overnight

I'm curious if you want to elaborate. What kind of games? Turn based? Do you just feed it repeated screenshots?

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

#13
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…

So fucking cool.

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

#14
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…

How does this compare to parametric modeling tools like Fusion/Solidworks/ProE ? Is it more about the integration with game specific tools?

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

#15
@baigy Huh. Interesting. I was just doing the final clean-up for something convergent to this research that I had been working on for the past few months. I think I arrived at your thesis (code first semantics from a different direction in CAD, so I think it'd be interesting for us to compare notes.

Have you formalized this into a compiler infrastructure yet? I think Python on its own would be too slow to build complex parts, especially since for triangle mesh, accuracy inversely correlates to performance.

Vision is generally not the most reliable form of checks for LLMs, even on GPT 5.6 Sol, so a recommendation I would have is to instead emit JSON or CSV of the color/topology data for the LLM to inspect directly, and this is the instance where ray query for topology checking will greatly improve accuracy in general. SDFs are a bit more complicated right now, I have a full implementation designed for 3D analysis

My own experimental compiler generated mesh suffers from the spiderweb effect: it's very polygon efficient but not very friendly towards UV unwrapping in general, and I'm struggling to find the correct approach for that. If you have any suggestions, I'd love if you can point me towards the correct approach.

Definitely very interesting though.

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

#16
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…

> there's a showcase (+ github repo) you can play around with: https://nova3d.xyz/

Before anyone else bothers giving them your Google account, there's zero free generations, something they conveniently don't disclose until after funneling you to sign up.

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

#17
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…

hey, first author here. This is a very fair point. rn we’re optimizing more for editability than runtime. the ~50 parts are basically the source code representation, not necessarily what should ship. since we give you the code as well as the glb, my thinking is you should be able to say “keep the wheels and doors separate, merge everything else, optimize for mobile” or change those rules directly in code, then rebuild a leaner glb. the same source could compile differently for web, mobile or desktop. but honestly we haven’t built or properly benchmarked that optimization pass yet. we still need to test mesh fusion, atlasing, LODs, collision proxies and material/PSO limits in a properly populated scene, not just on a single object. your comment is making me think this should be an explicit part of generation/export, not cleanup we leave to the gamedev afterwards. appreciate you raising it.

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

#18
post #12
post #6

Earlier quoted context omitted.

I am doubtful about the timeline. Not because AI can't do it; it totally can. LLMs have been able to run the full artist + code pipeline at least since the beginning of the year. I've built several physics-synced network simulation stacks without reading a single line of code. Agents playtest my games overnight and I wake up to a list of technical issues fixed, and FPS boosted. If you know how to ask the shaders will…

> Agents playtest my games overnight I'm curious if you want to elaborate. What kind of games? Turn based? Do you just feed it repeated screenshots?

> Agents playtest my games overnight I'm curious if you want to elaborate. What kind of games? Turn based? Do you just feed it repeated screenshots?

3D ARPG with dozens of systems, think Genshin or Fortnite. But it's all typescript running in the browser, so native browser introspection/debuggability came for free. The biggest problem TBH is the LLM thinking this is a web app, so it makes webby UIs that look out of place in the context of a game :D

Fable has a cromulent time building its own tests, tools and pipelines. But there's no magic, it literally uses the gamepad and plays the game itself, taking screenshots, profiling, and debugging as it goes. The game ticks are fully controllable so it can frame-advance at its own pace.

Sometimes I take screenshots if it's some very complex multi-step repro. But 90% of the time it drives the engine itself.

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

#19
post #14
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…

How does this compare to parametric modeling tools like Fusion/Solidworks/ProE ? Is it more about the integration with game specific tools?

[deleted]

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

#20
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…

> there's a showcase (+ github repo) you can play around with: https://nova3d.xyz/ Before anyone else bothers giving them your Google account, there's zero free generations, something they conveniently don't disclose until after funneling you to sign up.

Try the blender plugin. It's got full BYOK: https://github.com/RareSense/Nova3D/releases/tag/blender-plu...

Sorry I got more traction on Blender and haven't integrated BYOK on the app.

P.s. the max I can do is BYOK. I can't hand out free gens. I'm paying out of my own pocket.

Post reply on HN