I co-authored this paper. It's a new technique to generate 3D graphics as source code instead of a point cloud.<p>Under the hood, it generates 3D objects with separate, sophisticated internal assembly, producing an editable "kit of parts" (instead of monolithic blobs).<p>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 actually know that there is a `Door`, `Drum`, `Control_panel` etc. Which things belong to which assemblies. What moves and where its pivot is. And eventually what those components are supposed to do.<p>Most current 3D GenAI cannot do this since it generates "monolithic blobs" that look good, but are unusable in downstream workflows (e.g. game engines). I.e. if you generate a 3D bicycle using traditional approaches, it's basically a blob. When you need the wheels to turn, a human (or another AI) must spend time cutting the blob into parts, naming them, placing pivots and rigging joints. I.e. you need post-generation segmentation workflows of some sort.<p>The paper breaks down the whole technique, and there's a showcase (+ github repo) you can play around with: <a href="https://nova3d.xyz/" rel="nofollow">https://nova3d.xyz/</a>
> there's a showcase (+ github repo) you can play around with: <a href="https://nova3d.xyz/" rel="nofollow">https://nova3d.xyz/</a><p>Before anyone else bothers giving them your Google account, there's zero free generations, something they conveniently don't disclose until <i>after</i> funneling you to sign up.
Have you explored optimizing the assets to be game-ready?<p>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 brick wall every gamedev realizes after trying to make a scene out of easy-to-work-with primitives. You just can't hit a playable frame rate like this unless your entire game consists of just a few objects.<p>Have you experimented with atlasing, mesh fusion, baking animations, standardizing PSO's to a scene budget, etc? Because if this can't be automated, I've found it really limits the utility of such freeform generation techniques, since the approach is fundamentally incompatible with performance on today's graphics stack.
Isn't today's graphics stack moving in the direction of dynamically-optimized meshes (ie. Unreal's Nanite)?
Yup. But that's 10x <i>more</i> complicated, and needs an even more specialized baking phase that's even further from the raw representation. It only multiplies the issue.<p>And Nanite is not really designed for the kinds of lower fidelity fully articulated objects we're talking about here.<p>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.
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.
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.<p>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 <i>someone</i> needs to make an optimization baseline or show how it's possible.<p>Thanks for considering!
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.
This looks super interesting. I'm trying out the hosted app using "bring your own key", I've added an OpenAI key but it doesn't seem to let me generate a 3d model. It's still saying I need credits. Is this expected?
I see what you're doing. If you use the blender plugin, you'll get BYOK: <a href="https://github.com/RareSense/Nova3D/releases/tag/blender-plugin-v1.3.1" rel="nofollow">https://github.com/RareSense/Nova3D/releases/tag/blender-plu...</a><p>With the app, I haven't added BYOK yet. I guess I should have before I posted on HN!
Hang on right there!
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.
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.
How far are we from speaking a GameCube-era game into existence as a pastime?
Did I read this right? The objects are still just surfaces, not solids?
The current output is polygon meshes + the source code. So technically "surfaces", rather than CAD/B-rep solids. Many parts are closed volumes, but we don't claim manufacturing-grade solid geometry. This paper is focused on the Blender/mesh path. A CAD-solid backend would be a different target.
So fucking cool.