Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arxiv.org

Post reply on HN
Print view View original

21–30 of 42 posts

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

#21

Post by baigy »

zactato wrote: post #14
baigy wrote: 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?

There’s overlap in spirit, but we’re not trying to replace the precision of Fusion/SolidWorks. the idea is that an agent writes an editable 3D program from your prompt/reference, including geometry, parts and eventually behavior. Blender/GLB is our current target, so it looks game-oriented rn, but games aren’t the whole idea. for a mechanical CAD use case we’d want the same experience backed by a real CAD tool/kernel rather than pretending mesh geometry is engineering-grade. I think of CAD, Blender and game engines as different possible build targets for the same broader idea.

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

#22

Post by baigy »

avaer wrote: post #10
baigy wrote: 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…

Thanks for that feedback. rn I've been chasing editability over runtime. the ~50 parts are basically the source code representation, not necessarily what should ship. since you get 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 I haven't built or properly benchmarked that optimization pass yet. I 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)

#23

Post by baigy »

RobotToaster wrote: post #11
baigy wrote: 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?

The parts are originally defined in code, not stored as point clouds. That code builds the geometry using primitives, curves, custom mesh operations and sometimes CSG/booleans. When executed in Blender, the final exported GLB contains meshes.

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

#24

Post by baigy »

qarl2 wrote: post #13
baigy wrote: 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.

Thanks, here's a showcase you may like: https://app.nova3d.xyz/showcase

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

#25

Post by RobotToaster »

baigy wrote: post #20
RobotToaster wrote: post #16

Earlier quoted context omitted.

> 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.

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

It seems to have BYOK in the web app now? did you just add it? The only issue is it doesn't accept Gemini AQ authentication keys.

> P.s. the max I can do is BYOK. I can't hand out free gens. I'm unfunded and paying out of my own pocket. It is what it is.

Understandable, sorry if I sounded overly harsh, it was just an unexpected surprise.

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

#26

Post by baigy »

YuechenLi wrote: post #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 compl…

Would love to compare notes. It's compiler-shaped rn. The generated code is the source and Blender is the current build target. Python directs Blender's native geometry operations only. I also already generate UVs from the coded model before GLB export, while its part structure is still available, which helps avoid recovering everything from one fused spiderweb mesh. Visual checks aren’t the only option either. Having the code gives us direct structural checks too. Btw curious to see your SDF approach.

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

#27

Post by tcdent »

avaer wrote: post #10
baigy wrote: 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…

Isn't today's graphics stack moving in the direction of dynamically-optimized meshes (ie. Unreal's Nanite)?

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

#28

Post by avaer »

baigy wrote: post #22
avaer wrote: post #10

Earlier quoted context omitted.

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…

Thanks for that feedback. rn I've been chasing editability over runtime. the ~50 parts are basically the source code representation, not necessarily what should ship. since you get 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…

My ideal would be the model generates the sources (so it's programmatically tweakable after the fact, which is the entire appeal), but there is an open source compilation tool or something that can optimize it for the different use cases after you've made your tweaks.

Devs could probably make their own version of this; every engine/consumer of assets is different and needs tweaking. But there is no engine that won't choke on the raw version, so someone needs to make an optimization baseline or show how it's possible.

Thanks for considering!

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

#29

Post by chrisjj »

baigy wrote: 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…

Did I read this right? The objects are still just surfaces, not solids?

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

#30

Post by avaer »

tcdent wrote: post #27
avaer wrote: post #10

Earlier quoted context omitted.

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…

Isn't today's graphics stack moving in the direction of dynamically-optimized meshes (ie. Unreal's Nanite)?

Yup. But that's 10x more complicated, and needs an even more specialized baking phase that's even further from the raw representation. It only multiplies the issue.

And Nanite is not really designed for the kinds of lower fidelity fully articulated objects we're talking about here.

I will say though: I think things are going to move to neural rendering faster than people expect. So maybe the future is low fidelity highly articulated objects rendered with img2img. But nobody is seriously doing that yet.

Post reply on HN