5 ms·

Cut and paste of a recent comment I made in a similar thread: I've started to switch to Cadquery from OpenSCAD because OpenSCAD lacks proper fillets and chamfe

Cut and paste of a recent comment I made in a similar thread: I've started to switch to Cadquery from OpenSCAD because OpenSCAD lacks proper fillets and chamfers. I usually prefer the CSG (arithmetic tree of union/difference/intersection + transforms + base shape leaves) to model 3D objects, as opposed to Cadquery's "draw on 2D surfaces and extrude" approach, but OpenSCAD's lack of fillets / chamfers combined with the "everything is a polygonal mesh" approach of the rendering engine is just too limiting. Cadquery has a lot of potential (the underlying engine uses a traditional hierarchical NURBS BREP, IIUC), but it also has a lot of shortcomings: Here are some I've bumped into: . very strange "stack-based" model. For complex objects, it's hard to wrap your head around it, and the workflow it forces on you as a user does not always fit your mental model of the object. . the underlying hierarchical nature of the object (the BREP) is forcibly hidden from the user, which leads to kafka-esque situations when one wants to e.g. select parts of an object. . selecting parts (faces and edges) in a object is a nightmare. cadquery has "selectors", which are a) its own weird little DSL b) very difficult to use on complex shapes c) does not support name-based retrieval: can't label things and get to them later by name. See this github issue for example: https://github.com/dcowden/cadquery/issues/29 https://github.com/dcowden/cadquery/issues/29 - the UI (cq-editor) is unusable for real-world work: no perspective rendering, no graduations in ortho views, no way to measure things on the object, no way to examine the BREP, etc ... Generally speaking, the UI is only a visualizer, and does not let you query / inspect the model in any detailed way. - fine-grain control over tessellation (conversion to mesh) is lacking. - good for modeling mechanical parts / lousy for modeling anything organic-looking - importing external models that don't fit the cadquery BREP-based represention is basically impossible. TL;DR: a nice tool to add to your belt, but not a very mature environment yet, and certainly can't replace OpenSCAD yet.

defterGoose 5y ago
AFAIK there isn't really another reasonable way of rendering other than having render meshes attached to everything (due to GPU architecture), but they shouldn't be getting used for any calculations so it also shouldn't matter very much.
- ur-whale 5y ago
  > it also shouldn't matter very much. There is usually a point at which you need to take your model out of the CAD out of the CAD tool. For example to 3D print or to render. And at that point, fine control on the meshing is rather important. Sure, if you have a manufacturing tool that can directly handle NURBS, great. That's certainly not the majority of the the hobbyist / prosumer market. And the actual pros ... they don't use stuff like Cadquery, they use solidworks and the like. So, yes: proper conversion to a polygonal mesh with fine control matters a great deal.
  - defterGoose 5y ago
    > So, yes: proper conversion to a polygonal mesh with fine control matters a great deal. Sure, but the output conversion tools shouldn't be built around the render mesh. Any CAD tool worth it's salt should be able to take the best underlying representation of the model and give you an .stl with arbitrary precision. Every time I've ever exported a mesh from a NURBS modeller, I've gotten a dialog that lets you choose parameters. I'm not so experienced with standalone renderers (I usually only need the built-in ones), but the mesh that the CAD program uses to render should basically only be used for that purpose. Most programs shouldn't even give you access to it unless you open it up and look and the guts.
Piezoid 5y ago
> - good for modeling mechanical parts / lousy for modeling anything organic-looking SDF modeling is great for organic shapes. On the surface, it feels similar to OpenSCAD since CSG operations are natural primitives (min/max/...). Fillets / chamfers are easier to produce, compared to OpenSCAD: http://mercury.sexy/hg_sdf/#snippet http://mercury.sexy/hg_sdf/#snippet Libfive is one implementation geared towards CAD work. One issue with SDFs for CAD is that it can be difficult to work on complex models. The representation is not minimal: two SDFs can represent the same volume, but act differently when you combine them with other bodies. Libfive's "stdlib" is quite minimal. For anything fancy, you have to build your own "DOM" on top of it, in order to organize your parametric models. I have not enough experience for that, but I think that it should be possible to build a DSL that render to an SDF expression, while supporting introspection, constraint solving, AD for gradients, etc, with goals similar to CadQuery (I don't like the stack API either). This might also help with the normalization issue above.
ssl232 5y ago
> c) does not support name-based retrieval: can't label things and get to them later by name. I think I saw somewhere in the docs that you can tag items and reference them in the selector DSL. Maybe this is possible now? I haven't tried it though. One other small gripe about CadQuery that I'd add is that its error messages (via its CAD kernel) are typically very opaque.

defterGoose 5y ago

AFAIK there isn't really another reasonable way of rendering other than having render meshes attached to everything (due to GPU architecture), but they shouldn't be getting used for any calculations so it also shouldn't matter very much.

ur-whale 5y ago
> it also shouldn't matter very much. There is usually a point at which you need to take your model out of the CAD out of the CAD tool. For example to 3D print or to render. And at that point, fine control on the meshing is rather important. Sure, if you have a manufacturing tool that can directly handle NURBS, great. That's certainly not the majority of the the hobbyist / prosumer market. And the actual pros ... they don't use stuff like Cadquery, they use solidworks and the like. So, yes: proper conversion to a polygonal mesh with fine control matters a great deal.
- defterGoose 5y ago
  > So, yes: proper conversion to a polygonal mesh with fine control matters a great deal. Sure, but the output conversion tools shouldn't be built around the render mesh. Any CAD tool worth it's salt should be able to take the best underlying representation of the model and give you an .stl with arbitrary precision. Every time I've ever exported a mesh from a NURBS modeller, I've gotten a dialog that lets you choose parameters. I'm not so experienced with standalone renderers (I usually only need the built-in ones), but the mesh that the CAD program uses to render should basically only be used for that purpose. Most programs shouldn't even give you access to it unless you open it up and look and the guts.

Piezoid 5y ago

> - good for modeling mechanical parts / lousy for modeling anything organic-looking SDF modeling is great for organic shapes. On the surface, it feels similar to OpenSCAD since CSG operations are natural primitives (min/max/...). Fillets / chamfers are easier to produce, compared to OpenSCAD: http://mercury.sexy/hg_sdf/#snippet http://mercury.sexy/hg_sdf/#snippet Libfive is one implementation geared towards CAD work. One issue with SDFs for CAD is that it can be difficult to work on complex models. The representation is not minimal: two SDFs can represent the same volume, but act differently when you combine them with other bodies. Libfive's "stdlib" is quite minimal. For anything fancy, you have to build your own "DOM" on top of it, in order to organize your parametric models. I have not enough experience for that, but I think that it should be possible to build a DSL that render to an SDF expression, while supporting introspection, constraint solving, AD for gradients, etc, with goals similar to CadQuery (I don't like the stack API either). This might also help with the normalization issue above.

ssl232 5y ago

> c) does not support name-based retrieval: can't label things and get to them later by name. I think I saw somewhere in the docs that you can tag items and reference them in the selector DSL. Maybe this is possible now? I haven't tried it though. One other small gripe about CadQuery that I'd add is that its error messages (via its CAD kernel) are typically very opaque.