Currently, Nova doesn't handle any physical constraints regarding stability, just collision.

I think physics handling is a very desirable feature, maybe an agent using a physics engine directly or maybe via MCP that agent could get feedback about a model's stability, fix problems, back to more feedback, etc.

This would be similar to the current way finds and iteratively corrects defects by rendering images from the model, different perspectives, and directly examining them.

Main idea was, if LEGO parts don't cover the needs for an agent to build a model, let it use the best it can find, and manufacture others if needed, but keeping same compatibility with the rest of the catalog.

And for that, instead of generating new parts from scratch, maybe mutating pre-existing parts into new shapes it needs, but leaving connectors as they were, or even adding new connectors but still compatible.

I'm currently considering 3D-printing a small one, however, in order to see how it looks IRL.

Something that comes to my mind very often is... adding more parts to the LDraw parts catalog, the ones used to build models, but these extra ones would be real-sized blocks, like the ones used to build actual buildings ;-)

https://anteloc.github.io/index-samples.html

That's a gallery of by-products and results from different executions.

Videos, I'm afraid I don't have any, these CAD models can be better inspected by opening them on e.g. LDView, that to record LDView while playing with them.

Those come from opening ldraw-nova on VS Code, asking different coding agents (Codex, Claude Code, etc.) to read the instructions.md at the repo, and then to build something.

Also, from different attempts by different agents in order to learn "how" to do something, like e.g. place an axle correctly.

Those are just leftovers, usually images like those show embedded in web app chats on LDraw Nova.

If you are curious about the internals of an .mpd model, the "what was the agent picturing on its mind", open the .mpd file that got your attention on a text editor, and read the first line under the ones starting with "0 FILE".

Technic models, for example, are usually expensive, given that initial placements are usually further from the right position than non-Technic models, the "bricks" ones.

A (wild!) estimate: Astra, building a Technic mechanism, around 5$...

This is one of the reasons for creating this project: making a tooling that can be used by low-end agents to iteratively build, while high-end agents, like e.g. Astra or Opus, would do the planning, vision models the inspection... etc.

Well, who knows :)

Getting mechanisms to work is one of my goals, though =)

When giving them enough examples, like e.g. houses, they tend to do well in that category, but not perfect.

My guess is that what happens is, given that most LEGO parts have a very limited, discrete set of legal positions and rotations, expressed as integer numbers, the agent finds patterns between different models, like e.g. a brick close to the center of a model usually has very similar (integer) coordinates and rotation components to another central brick from another model.

However, it still messes up very often, with things like e.g. +/- signs that flip parts due to rotations becoming -90deg when they should be +90deg; then, validation and correction cycles, running tools that verify the presence/absence of collisions, really helps in finishing the job.

I'm taking a look at this paper right now, didn't came across it before.

I think it's really good, and also an approach I tried.

In my case, it was working pretty well in terms of geometry and correctness, but not in terms of creativity: too many constraints and an agentic LLM would end up building very similar buildings all the time. Too few ones, and it would drift into unbuildable models.

In the end, I think the current iterative process gives it a good balance: let it try things first and be creative, parts will be placed incorrectly at the beginning, but it will fix their placements, colours and so on bit by bit, until the end result is (hopefully!) correct.

And regarding Opus, according to my experience, I'd say definitely models quality is way better when produced by Opus 5 and even better by Opus 5.5

I've been experimenting with FreeCAD and freecad-mcp too, even managed for Claude to create a new LDraw benchmark for it.

However, given the amount of parts some LDraw models have, FreeCAD performance would not be enough, something to do with its solver trying to work out too many constraints at once.

The thing about how to assemble the parts, yes, that drove me crazy for quite a while.

A way I found that helps is to provide the agents information about contacts, e.g. what parts of a brick are actually connectors.

With that in place, it can create tools to automatically check if two parts are connected "the right way" ;-)

I got LEGO connectors info from here: https://www.melkert.net/LDCad/tech/shadowLib

I really appreciate you helping me with this, and totally get the bit about getting flooded.

Anyway, I hope HN community will like this, and maybe contribute, have some crazy ideas about how and where to move forward =)

New on HN, first time posting, and (I guess) my post on Show HN was rejected...

Anyway, I hope I'm not bothering anyone by posting this outside Show HN, or posting almost the same thing twice.

Past year, around December, I started experimenting with making ChatGPT and Claude generate source code in LDraw language.

This LDraw is literally an "assembly" language, a low-level programming language that describes how to assemble LEGO pieces together into models, one placement instruction at a time.

When executed by specific tools, like e.g. LDView, LeoCAD, Studio... these instructions become LEGO CAD models, that can be interacted with, modified, etc.

Or, in other words: one LDraw source file in .mpd or .ldr format is equivalent to one LEGO CAD model.

So, the idea I had was: if I manage for maybe ChatGPT or Claude to generate high-quality LDraw source files... then, they would actually be generating high-quality LEGO CAD models, right?

Then, after months of iterations and trying one thing after the other... it worked!!!

Long story short: using GPT-6 Astra and Opus 5.5, I've managed to create a python toolset, instructions, and docs for agents in general. Now, these can be used by them to generate LDraw models.

I've packed it all as a dockerized web app for others to try and experiment, with several providers (and agents) to choose from: OpenAI, Claude and OpenRouter.

I'd really appreciate feedback and comments, let's see where this goes =)

Past year, around December, I started experimenting with making ChatGPT and Claude generate source code in LDraw language.

This LDraw is literally an "assembly" language, a low-level programming language that describes how to assemble LEGO pieces together into models, one placement instruction at a time.

When executed by specific tools, like e.g. LDView, LeoCAD, Studio... these instructions become LEGO CAD models, that can be interacted with, modified, etc.

Or, in other words: one LDraw source file in .mpd or .ldr format is equivalent to one LEGO CAD model.

So, the idea I had was: if I manage for maybe ChatGPT or Claude to generate high-quality LDraw source files... then, they would actually be generating high-quality LEGO CAD models, right?

Then, after months of iterations and trying one thing after the other... it worked!!!

Long story short: using GPT-6 Astra and Opus 5.5, I've managed to create a python toolset, instructions, and docs for agents in general. Now, these can be used by them to generate LDraw models.

I've packed it all as a dockerized web app for others to try and experiment, with several providers (and agents) to choose from: OpenAI, Claude and OpenRouter.

Here's a bunch of exmaples: https://anteloc.github.io/index-samples.html.

If you are curious about the internals of an .mpd model, the "what was the agent picturing on its mind", open the .mpd file that got your attention on a text editor, and read the first line under the ones starting with "0 FILE".

I'd really appreciate feedback and comments, let's see where this goes =)

Comments URL: https://news.ycombinator.com/item?id=49937916

Points: 80

# Comments: 41