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
