Good question on the naming issue. I thought about it a lot Right now i have implemented selectors that could select the edge.
In the case attached, the only way I could see to do it would be to use the near to point selector, and but that does indeed suffer from a problem because the correct point in space could change. One idea I have thought about is to allow tagging features produced by each operation, and then allow a query to look for features shared by multiple tags. In the case attached it would be the edge crested by the second boss, and lying in the face created in the first boss. Do you think that would work? On Mar 19, 2013 6:20 AM, "Thomas Paviot" <tpav...@gmail.com> wrote: > 2013/3/17 Dave Cowden <dave.cow...@gmail.com> > >> Hello, everyone: >> >> I'd like to introduce to you parametricparts.com, a new web-based >> platform for making 3d parametric objects. >> >> There has been much talk over the years on a 'second level API'-- and i >> know there are couple of implementations: cadmium for example. >> >> I would be interested in your thoughts about the API I have developed-- >> which is inspired by jQuery in the javascript world. Unlike some of the >> other second level APIs, my goal was to create a fluent API that allows >> constructing objects in a way that captures design intent. >> >> Here's what i came up with: >> >> https://parametricparts.com/docs/examples.html >> >> Right now cadquery, it is implemented on top of FreeCAD, because FreeCAD >> is super easy to install. But if there is community interest, I would love >> to move it to be implemented on top of pythonOCC, because it offers more >> flexibility. >> >> I'm on a mission to build the first real productivity solution for 3D >> content-- I'd love to hear your thoughts! >> >> >> > Hi Dave, > > Happy to have such good news from you! I'm very impressed with what you > already achieved with parametricparts.com, congratulations. > > CadQuery is interesting, it makes me think about the cadmium api ( > https://github.com/jay3sh/cadmium), there might be some kind of possible > meeting points between these two projects. CadQuery could be implemented in > pythonocc without any problem IMO, you have three options : > * rely on the core occ classes/methods > * use the first fragments of a higher level API, contributed by Jelle > Feringa, available in the src/addons/ folder. Most of Jelle's work is still > on his hard drive, and should be pushed up to the git repository in order > to be integrated into pythonocc ; > * rely on the GEOM python wrapper, to benefit from something really > "parametric". > > Each has to be balanced, and CadQuery would definitely be a nice addition > to pythonocc. > > I have one question though: how to you deal with the "topological naming" > issue. I mean, for example how do you "select" or "choose" an edge > necessary to a filleting operation, in a way that the "design intent" is > captured. For instance, how you would model, using CadQuery, the LBlock > geometry attached (from [1]) and especially the fillet? > > Best Regards, > > Thomas > > [1] Li, Jinggao, Byung Chul Kim, and Soonhung Han. "Parametric exchange of > round shapes between a mechanical CAD system and a ship CAD > system."*Computer-Aided > Design* 44.2 (2012): 154-161. > > > _______________________________________________ > Pythonocc-users mailing list > Pythonocc-users@gna.org > https://mail.gna.org/listinfo/pythonocc-users > >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
