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

Parametric CAD in Rust

campedersen.com

Post reply on HN
Print view View original

181–184 of 184 posts

Re: Parametric CAD in Rust

#181

Post by fsloth »

WillAdams wrote: post #180
fsloth wrote: post #179

Earlier quoted context omitted.

Version control? Quite a few with their domain specific naming conditions, constraints and workflows. For example Fusion 360 https://www.autodesk.com/products/fusion-360/blog/fusion-360... Then there's stuff like "Tekla model sharing" https://www.tekla.com/products/tekla-model-sharing Onshape https://cad.onshape.com/help/Content/versionmanager.htm Etc The requirement to a) collaborate b) version the work is quite old…

I was more thinking opensource options now that Ondsel has folded, but appreciate the information.

Their blog post about this subject is really good https://www.ondsel.com/blog/goodbye/

They chose maybe one of the toughest imaginable combinations for a business model. Viable open source businesses are hard (since you don’t own your ip in closed form, hard to explain to investors what the actual value is). 3D businesses are hard.

So it’s hard x hard.

Clearly their _tech_ worked. I guess there is a lesson here - better mousetrap is almost never enough for a viable business.

Re: Parametric CAD in Rust

#182

Post by xg15 »

fainpul wrote: post #103
rkagerer wrote: post #91

With the ability to change one number and regenerate everything That's exactly how I use Solidworks (and similar parametric CAD software) all the time. It takes some discipline, but the key is for all your geometry and relations to be driven from sketches and equations. Then you just change a value (sketch dimension or global constant), hit rebuild, and everything regenerates fairly reliably. Don't get me wrong, this…

I'm with you. What I've learned from all those "programmatic CAD" threads is that some people just really prefer code over anything else. They also build only simple parts, so it's not an issue for them. As the author says: "I wanted to write my parts the way I write firmware. In Rust. With types. With version control."

Yeah, sometimes it seems there is a certain kind of devs who don't just like code for the sake of it, but have an active hostility against GUI tools and visualization in general, for whatever reasons.

I get the appeal of "change a number and regenerate everything" as well as "you can store everything in git" - but there is no reason why a decent visual CAD program couldn't do both of them just as well.

In contrast, the ability to actually see a part in front of me and not having to mentally visualize it the whole time seems substantial to me.

Re: Parametric CAD in Rust

#184

Post by DannyBee »

WillAdams wrote: post #175
DannyBee wrote: post #130

Earlier quoted context omitted.

Yes, this is all true, but the comment I responded to wanted to be able to basically code rather than GUI sometimes , but still have the GUI up to date. Because of how onshape was built it makes this very very easy. Solidworks very much does not. Fusion360 also has good enough python bindings but it's still nowhere near as easy or integrated to do this (or debug it) as onshape. So I'm kinda not sure what you are goin…

For folks who are curious about this, see: https://cad.onshape.com/FsDoc/ My surmise is that this is tightly coupled with Parasolid, so it wouldn't be feasible to create an implementation of this language using some other CAD kernel?

You could port it, but i don't think the geometry kernel is the hard part.

The code for the standard library is here: https://cad.onshape.com/documents/12312312345abcabcabcdeff/w...

(Click tab manager in the bottom left and you'll get a nicer list of the files involved)

The actual representation is essentially dictionaries. IE transform is a functon that looks like this:

  /**
   * Construct a [Transform] using the matrix argument for rotation
   * and scaling and the vector argument for translation.
   */
  export function transform(linear is Matrix, translation is Vector) returns   Transform
  precondition
  {
      matrixSize(linear) == [3, 3];
      is3dLengthVector(translation);
  }
  {
      return { "linear" : linear, "translation" : translation } as Transform;
  }
Fillets, for example, are a whole bunch of featurescript UI around fillet operations:

https://cad.onshape.com/documents/12312312345abcabcabcdeff/w...

(The underlying fillet ops are opFullRoundFillet, etc. All of this is UI to generate the parameters and highlight the results and such)

The actual geometry ops are in geomOperations. Those are the geometry primitives you'd have to duplicate, and they are fairly standard. Fillets, holes, CSG, etc.

It would not be a ton of work (IMHO) to have a geometry kernel that supports what they support.

The UI related primitives, the query engine, etc, those are i think where you'd have real work to do.

Post reply on HN