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
