I wrote a detailed blog post on why and how I came to develop Cadmium: http://blog.3dtin.com/cadmium-solid-modelling-library-python-openso
Besides Cadmium, I am the developer of 3DTin - the browser based 3D modeling tool. Cadmium is my effort to build a scripting environment for solid modeling that can eventually be made available through online CAD tool like 3DTin. Please let me know if you have any feedback on the above post. Thanks. -- Jayesh On Mon, Jun 13, 2011 at 11:26 AM, Jayesh Salvi <jayeshsa...@gmail.com> wrote: >> >> Hi Jayesh, >> >> Welcome to this list and thanks for reporting your contribution. We already >> discussed here the opportunity to simplify the API (just google the famous >> "Anyone seen this?" thread). Julien Blanchard reported here a kind a similar >> project named pycado (http://julienbld.github.com/pycado/), > > Yeah, I looked into Pycado too. > >> but I do prefer >> your approach: I already wrote that I do not recommand writing another >> scripting or macro language in order to succeed in such a project. *the* >> scripting language is already available: python. The use of native python >> features enables real 'high level' idioms, like for instance mapping boolean >> operations to '+', '*' or '-' as you did, which is IMO an excellent idea. > > We share the same opinion. > >> >> The model transformation from CGAL to pythonOCC may be hazardous: I don't >> see how the 'Polyhedron' class (CGAL) can be related to any superclass of >> cylindrical primitives like Spheres, Cylinders. Do you plan to extend your >> project beyond CSG features? > > The main reason I switched to PythonOCC is, I couldn't get past > assertion failures and crashes with CGAL, even while performing CSG > operations on some simple geometries. Probably my lack of > understanding of CGAL, but I was blocked nonetheless. With PythonOCC > features however I got things working in only couple of days. Never > faced in crashes, or incurred errors that I couldn't understand. > > In near term I am interested only in CSG operations, but in future I > would like to add more functionality. Could you please elaborate on > why you said switch from CGAL to PythonOCC may be hazardous? The > Polyhedron class in cadmium is roughly an equivalent of BRepPrimitive > in PythonOCC (or Nef_Polyhedron when it was using CGAL). Do you think > that may be an incorrect abstraction? > > I see that PythonOCC has support for a lot of features (NURBs, > arbitrary BRep construction, etc), I believe we can come up with > simple abstractions on top of these powerful features to provide some > cool solid modeling functionality. What do you think? > >> >> python based, visualization free, it's all I like to see in CAD in general! >> Good luck for your project, and feel free to announce here your recent >> developments. > > I sure will. > > Thanks for the feedback. > _______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
