ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
58% Positive
Analyzed from 1630 words in the discussion.
Trending Topics
#code#game#blender#mesh#parts#source#byok#more#cad#geometry
Discussion (30 Comments)Read Original on HackerNews
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 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.
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.
The paper breaks down the whole technique, and 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.
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.
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.
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.
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.
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.
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!
With the app, I haven't added BYOK yet. I guess I should have before I posted on HN!
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 look great.
The problem is that making a game actually worth playing (something that Nintendo would allow to be released) isn't something that was ever possible to do as a pasttime, AI or not. You have to be in front of the computer all day guiding it. Worse, AI does not have any notion of experiencing or evaluating fun, so you can't automate this. So the LLM can't actually make the "game" part of the game. This would be a killer research problem to tackle, though!
If we're talking about making something that passes a sniff test, you could make a metaverse right now. It just wouldn't meet the bottom of the Steam free tier in terms of what players prefer.
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.
So, yeah, mine is full geometry kernel that was made for CAD. I'll do a full write-up on Show HN later as there is just way too much stuff to cover for the project. The gist of it is that it is a compiler for 3D models that takes the high-level language, which I named Firmament, and lowers it to STEP AP242 mapped BRep in C#.
So, for SDF, it was originally conceived as a method to solve the general case 3D BRep boolean problem through methodology similar to libfive/Fidget in FRep directly. The problem is that we immediately ran into the same wall that everybody else did attempting to recover mesh/BRep structure from the SDF blob, spent like a week doing BRep patches for it, before we ultimately concluded that it was not really possible to do as FRep is a lower representation than either BRep or mesh. It's probably more useful for continuum physics/fluid dynamics in the future than it is for CAD/solid mechanics/3D modeling, but currently the SDF pipeline is just kinda sitting there as dead code and not being used much.
https://github.com/yuechen-li-dev/Aetheris/tree/master/Aethe...