Thomas, Dan, Dave,
A precedent (or at least a closely related concept) was the "CAD
Services API" developed by the [now defunct] OMG Manufacturing
Technology & Industrial Systems Task Force (MANTIS). That
specification is no longer active. It basically fell prey to
the OMG rule that an active spec must be implemented by at least
2 vendors -- it was only implemented by one vendor (see below) --
but it represents some good work that is still potentially
useful.
The fact that only ITI had a product that implemented the CAD
Services API specification is more an indication of the hesitancy
of CAD vendors to provide a standardized API than of the quality
of the spec, IMO. ;) I've put a copy of its last version on my
web server for convenience (not publicized since I think OMG's
copyright might still be in force, not sure -- but since NASA
contributed to the spec, I feel somewhat justified in making it
available!):
http://pangalactic.us/cax/CAD_Service_V1.1_030363.pdf
It's interesting to note that both NASA *and* OpenCascade
contributed to the spec. It is based on the API of "CADScript",
a set of Python wrappers for CAD tools that was developed as a
commercial product by Doug Cheney of International Technegroup
Incorporated (ITI). CADScript is no longer offered by ITI as a
product, but Doug (who is a strong python advocate) has used a
Python API internally for another ITI product of which he is the
primary developer, called CADIQ, which analyses CAD models for
various types of modeling errors that could lead to data exchange
problems or manufacturing problems, for example. (The CADIQ url
is: http://www.transcendata.com/products/cadiq/) Doug presented
the CADScript product at the PDE 2001 Workshop at JPL. His
presentationslides are here:
http://step.nasa.gov/pde2001/STEP-and-Scriptable-CAx-Tool-Integration_Doug-Cheney.ppt
Doug also did an impressive live demo using CADScript for the
Multi-CAD Assembly use case shown in his next-to-last slide.
Also, from recent conversations with Doug, I know that users of
the current CADIQ product can be given access to the supported
Python API that it uses (not sure how much of CADScript might be
there).
I agree with what Thomas proposes below -- the concept of a
standardized high-level API that would have a standardized
framework or methods to specialize it for particular use cases.
I'd suggest considering the CAD Services API specification as a
starting point for a high-level API, since that spec incorporates
a substantial amount of harmonization work that was done to
develop a consensus high-level CAD API, and I think if pythonOCC
provided a high-level API that implements even something close to
the CAD Services API, it could provide a de facto industry
standard high-level CAD API, with the hope of getting it adopted
by other tools, and in the future possibly made a formal standard
(by OMG, ISO/IEC, or whomever).
Cheers,
Steve
On 12/11/2010 03:47 PM, Thomas Paviot wrote:
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 <mailto: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 <mailto: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 <mailto:Pythonocc-users@gna.org>
>> https://mail.gna.org/listinfo/pythonocc-users
>
--
Sent from my mobile device
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org <mailto: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
