Hi Dave, I use to work with Catia V5 and SW and, when I started to develop pythonOCC, my first intent was (and is still) to go to the opposite!
My answer to your 4 points : - I agree with you that parametric modeling is a key feature of the high level API - The 'svn diff' over a shape built from a (python) script is quite good. However, shape comparison is quite more difficult than text comparison. If absolutely don't have any idea about the 'how to' - In my opinion, components like SW's "sheet metal design" are out of the scope of a high level API for pythonOCC. I mean, this kind of module is at some higher level. The high level pythonOCC API should be a kind of middle-level API (between the sheet metal design and the OCC TopoDS_Shapes, Edges etc.) on which business domain specific classes/objects/methods would be based - Last point: I hate the 'feature tree' of usual CAD softwares. I don't know who once said "the design process of a complex shape is isomorphic to a tree-like graph and you all will use this kind of pattern to drive your design for the coming 30 years", but he should be punished! IMO, we must break free from this poor way of thinking CAD. To go further, we must take care when talking about 'scripting' as a kind of procedural construction of the model. I do believe in python as a 'dynamic programming language' rather than a simple scripting language. python programs just enable incredibly agile and complex mechanisms that are far away from the Catia V5 or SW VB scripts. And I completely agree with your last 2 paragraphs! Thomas 2010/12/12 Cowdens <dave.cow...@gmail.com> > Thomas, I like that idea a lot. > > I use solid works (SW) as my primary solid modelling package, so I think > it is useful to compare these ideas with SW, since it is quite powerful and > easy to use. > > Here are some thoughts regarding this : > > > - SW is highly parametric-- I think that using PAF is a key and > important feature > - SW uses a completely proprietary format. all operations are 'point > and click' and then are saved in a proprietary format that is binary and > cannot be merged/stored in CVS. Were a solid model a 'script'-- a series > of > instructions that builds the models, it would be much more powerful. The > user story I have in mind here is " i use a tool that lets me build a > model. > i drill a hole with parameter P1 as the diameter, and save the file into > CVS. later on, i change paramter P1 to a new value, and when i do a cvs > diff, i see only this line of text changed. > - SW has many, many custom modules that provide highly specific > functions for differing needs. A good example is the sheet metal package, > which allows computing bends from flat sheets. Another example is a > fasteners module that automatically produces ANSI fasteners. These are > pefect illustrations of your point, Thomas: this kind of specificity would > be very expensive to build for all disciplines. > - SW provides shows a 'model tree' that shows each operation and its > children operations. As you modify properties of any particular operation, > the changes automatically cascade through the model. This makes SW very > powerful, but interestingly makes it a lot more like programming because > you > have to essentially design the model with this tree in mind. > > There is another intruiging point when you consider building a solid from > a 3GL program like a python script. The two big CAD packages, SW and > Pro/Engineeer ( PTC ), differentiate themselves primarily by whether models > are hierarchal and all parameter changes cascade thrhough the model ( like > SW ), or whether the model is static, and changes do not cascade in this way > ( PTC has a fancy name for this-- but basicaly they argue that the cascades > in SW are more difficult than they are worth. > > If you build the model from a script, this debate is essentially moot, > because using either approach you can programmatically build the model > again. And, having a 3GL language driving the creation of the model is much > more flexible and expressive than the proprietary way SW does it. > > > ** > ------------------------------ > *From:* pythonocc-users-boun...@gna.org [mailto: > pythonocc-users-boun...@gna.org] *On Behalf Of *Thomas Paviot > *Sent:* Saturday, December 11, 2010 3:48 PM > *To:* pythonOCC users mailing list. > *Subject:* Re: [Pythonocc-users] Anyone seen this? > > Dear Dan, Dave, > > I didn't know about the openscad project, thanks for introducing me this > project. Dave, you write "it is a tool that allows programmatically > building solids using python and a CSG kernel", but I don't see any python > scripting, I have rather the feeling that the scripting language of openscad > is a kind of specific language, am I wrong? > > I agree with both of you regarding the high-level API that could be built > upon pythonOCC. Abstracting the low-level OCC api/data model would be > something really helpful. From a development viewpoint, there is not big > issue : we all developed or our own classes/methods or function in pythonOCC > in ordre to speed up development and make our programs modular. The big deal > is rather : what classes/methods should be made available to the user? How > could this set of functions be complete, i.e. how to ensure that *all* the > needs from any user are covered by this API ? > > In my opinion, there's no way to get it done (I've been thinking about this > for a long time). We'll always find a user that is not satisfied with the > API and who requests for another method/class etc. The risk is then that > this high level API become as big and complex as the original one (OCC). > > We could then imagine a different workflow than the usual one. I think > about something that was used for the standardization of the AP239 of the > STEP standard (also known as PCLS) : a very generic data model were designed > (and standardized), and the specialization of the data model was also > standardized. As a consequence, users with very specific business just join > their efforts to define a standardized specialization of the generic data > model suitable for their needs (aviation maintenance, operational feedback > etc.). > > This development model could be moved to the pythonOCC high level API > development : > > - a generic data model would be defined, with basic and fundamental > elements ; > - a framework for specializing this model is also defined. Both of this > two points could be viewed at an ontological level ; > - we then set up a 'high level API' repository with a set of basic > classes/methods already defined ; > - from these 2 points, we just let the user contribute new > classes/functions/methods if what he is looking for is not already > available > from the repository. > > It could be a way for us (developpers of pythonocc) to share the > development efforts of this needed high level API. And to have, as a > consequence, a huge web-based repository of python > classes/methods/functions, classified by businesses (FEM, manufacturing > etc.), level of granularity, functions (gears, bearings etc.) etc. > > pythonOCC would then become a kind of distributed library : a core > component (the python wrapper), required, and thousands of optional > components available online, supported by a powerfull request engine. > Setting up such an architecture is more a scientific project than a simple > python development activity. > > What do you think about that idea? > > Thomas > > 2010/12/11 Dave Cowden <dave.cow...@gmail.com> > >> Yes, definitely a higher level of abstraction is needed than just pure >> python. >> >> I am thinking ( not surprisingly ) of an environment a lot like a java >> ide. You write code, but the ide provides syntax highlighting, >> function completion, refactor support, code templates, a way to >> include other libraries, etc. >> >> On 12/10/10, Dan Falck <dfa...@frontier.com> wrote: >> > Yes, this technique does work- I've used it for commercial design work >> > with some proprietary modelers (Ashlar Cobalt and PunchCad Shark FX) >> > that used a crude scripting language-called of all things 'Macro >> > Parser'. I was able to make simple changes to the scripting that would >> > be major changes to the model. This allowed for very flexible revisions. >> > It also made it easy to recover from a crash if the application was >> > acting finicky. >> > I was able to do fork crowns for bicycles (classic Italian style-not the >> > modern stuff) by using techniques that emulated a cnc mill tool path >> > through the solid block. The whole time I was working the model as a >> > machinist would at a mill or lathe- subtracting shapes from the solid >> > that I started with. Python code was necessary to keep me from losing my >> > mind during these projects :) I created some functions that made dealing >> > with the crude 'Macro Parser' scripting a lot easier. >> > PythonOCC looks a whole lot more attractive to me than my old work with >> > this crude scripting. But, I would like to be able to abstract it a >> > little more though to make it easier to remember how to use it, without >> > having to go to the OCC docs all the time. I would bet that Thomas and >> > Jelle are working on something like this. >> > I think this project might be similar to what we are talking about: >> > >> > http://www.caddd.org/ >> > >> > Dan >> > >> > On 12/10/10 2:27 PM, Dave Cowden wrote: >> >> I assume that someone has seen this: >> >> >> >> http://openscad.org/ >> >> >> >> it is a tool that allows programmatically building solids using python >> >> and a CSG kernel. >> >> >> >> If such a tool used pythonOCC instead, it would be _much_ more >> powerful. >> >> >> >> This kind of tool is really interesting to me. Anyone who has done >> >> much solid modelling for a living quickly realizes that a complex >> >> solid model is much like a programming problem. You cannot just >> >> 'start building' a complex model: you have to plan how the object is >> >> built, which references are used, etc, so that the object is >> >> extensible and easily changed to accommodate design iterations. It >> >> becomes really important to plan reference planes and other reference >> >> geometries to reference each other in a way consistent with the rest >> >> of the model. >> >> >> >> Using a programming language to capture the [currently always >> >> proprietary] way that solid modelling packages capture the build order >> >> and dependency chains of a solid ( especially parametric solids ) is >> >> brilliant. As programmers, we are very familiar with the ability to >> >> use CVS merge and other utilities to track fine-grained changes to >> >> software over time, even when under concurrent development. Imagine >> >> the power of this capability applied to scripts that produce solid >> >> objects! No more huge binary solid object files that are opaque from >> >> a change management viewpoint! >> >> >> >> Does anyone know if such a package is underway anywhere based on >> >> pythonOCC? >> >> >> >> >> >> >> >> _______________________________________________ >> >> Pythonocc-users mailing list >> >> Pythonocc-users@gna.org >> >> https://mail.gna.org/listinfo/pythonocc-users >> > >> >> -- >> Sent from my mobile device >> >> _______________________________________________ >> 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 > >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
