Hacker News Reader

Comment by jhot | Hacker News Reader

Last weekend I bought my wife a bike off marketplace. It was in good condition but was missing one of the internal cable routing grommets. I gave Claude pictures of the pill-shaped hole by itself and with my digital calipers in the long and short directions.

Gave it a short prompt and it gave me an openscad model with everything parametrized. I printed with no changes in tpu and it was nearly perfect on the first try. Claude put in a 0.3mm subtraction in the x/y dimensions and I lowered it to 0.1 and it's perfect.

Much easier shape than ancient Roman architecture but still very cool how easy it was.

View on HN

Yeah, CAD has been my personal example of "oh the barrier to entry for this skill was high enough that I didn't do it and now I can be passably bad at it enough to get some simple things done"

I've had similar experiences with making simple functional parts off a 3d printer with OpenSCAD + LLMs. I'm very aware that the models are worse at it than say, generating react code, and I'm also the antithesis of a skilled pilot. It's still cool and has resulted in me starting to learn a new skill at a hobby level.

Learning to make simple parts in onshape is pretty darn easy (and fun).

Yeah. I teach this after school to 7th grade kids. Anyone can pick this up in a few hours.

They taught us to make Legobricks with CAD when I was in 6th. Wish I retained more of that and that it would be more widely taught.

I am reasonably confident that access to solid modeling and additive fabrication is now more widespread than ever.

I mean, like any other skill that has pretty much been my experience (though I tried fusion + openscad), but there is something about being able to ask a computer all the dumb noob questions that makes that first phase easier.

It's like this with a lot of things now. For example, Nix's learning curve used to be a huge barrier to entry. Now with LLMs, I'm using nix-darwin and home-manager for dotfiles, package management, and have individual flakes in all of my projects for cryptographically reproducible builds!

Nit: there’s nothing “cryptographic” about reproducible builds.

“Reproducible build” already usually implies bit-by-bit reproducibility.

i thought it mainly implied architectural/hardware compatibility and deterministic output

Nix mostly does not guarantee deterministic output. It rather guarantees deterministic inputs, and then sandboxes the system to inhibit the build from accessing the outside world.

Deterministic inputs do not always imply deterministic outputs.

Indeed, the Reproducible Builds community is working on fixing non-deterministic build output https://reproducible-builds.org/

I meant with Nix you're comparing hashes. With Docker, you're using pinned versions

“The reproducibility is cryptographically verifiable with hashes“ would be the full sentence, but it’s a mouthful.

yes, but it's still not cryptological, it's just verification using hashes.

The hash being cryptographically secure is significant. In contrast, you could use (for example) md5 to non-cryptographically verify that the full process matched.

Sorry, the point I was making is that this isn't cryptography- it's the properties of a cryptographic hash (hard to spoof) that are useful. I don't think any verified build program uses the hash to encrypt data at any point. If I'm wrong on this point, that's fine, but please include a link.

Sure, "verified in a cryptographically secure manner" is technically not equivalent to "cryptographically verified" but the response "it's not cryptographic" is rather ambiguous at best given that it is, in fact, a cryptographically secure manner of verification. The key observation here being that an algorithm or process being "cryptographically secure" does not mean that it is "cryptographic" in nature (ie implements or uses cryptography).

Build reproducibility checks usually use bitwise comparison, not hash comparison.

The Reproducible Builds project also wrote diffoscope, which goes quite far with helping identify where differences occur and how to fix them.

https://reproducible-builds.org/ https://diffoscope.org/ https://try.diffoscope.org/

Let’s say, for the positive case, hash comparison is significantly faster.

I feel like that is quite unlikely. Both the hash and bitwise comparisons read both files in both cases. In the not-equal case the hash reads the entirety of both files, so its slower than a start-to-end bitwise comparison, which exits at the first not-equal bit. In the equal case, both read the entirety of both files. Various other bitwise strategies can be faster than start-to-end, rdfind for example checks the start of the file first, then the end, then the rest of the file.

I think we’re not talking about the same scenario. I’m talking about the case where at least one hash has already been calculated.

Nix is also great at work. You keep the server nix code in the same repo and OpenCode can just change and test server config.

same — LLMs turn skills i'd parked for years into 'just try it' territory, which is genuinely new.

Claude does well if you can provide all dimensions. It fails at guessing though. The real magic is when you can provide one dimension or photograph with a ruler in it and the AI will figure the rest out. Right now, Claude anyways, is pretty bad at guessing.

I was recently trying to get models to generate a 3D fortune cookie. Claude in three.js and Gemini in openSCAD. Neither really got the concept or could get very close at all. It's a surprisingly complex shape I guess.

with the shape you probably want something thats good at bends/fabric

cause youd start with the flat shape, the set some contraints that certain edges are colinear

Probably easier with Trellis 2 or Meshy.ai

Amazingly I tried the exact same thing! It also kept making meaningless corrections and was so confident that the blob it had produced was a fortune cookie that it started telling me I was wrong.

these small functional prints are exactly where OpenSCAD and LLM generation shines

Does it optimize for no support?

You optimize for no support when selecting print orientation (but for anything semi-cylindrical like described that would be the only sane orientation and the one slicer would choose when you smash the 'Auto Orientation' button).

Naive/uninformed question: does 3D printing produce any cleavage issues (like you’d get with a crystal) along the directions of printing, and does it ever make sense to change the orientation to help with that?

Of course it does! Inter-layer adhesion is lower than the adhesion within the same layer, so it's often recommended to orient the print in a way that maximizes strength - especially for tensile loads. Sometimes it even makes sense to split the part so that you can print each of them optimally (flat side on the print bed) and get the best strength for the dominant load directions. That applies to functional prints - for decorative stuff you use the direction that gets you the cleanest print.

Reply on news.ycombinator.com