Here's an interesting view of what the OpenSCAD guys are doing. This is a view of this CSG-based high level api. http://blog.thingiverse.com/2010/12/10/getting-started-with-openscad/ Believe it or not, this simple tool with very limited functions( by OCC standards ) is making big waves because: (a) its free, and (b) its easy to get going with, and (c) it is parametric and can be used to create very complex objects using 3GL scripts. I already see a lot of objects on thingiverse, a popular collection of objects, done with this tool instead of others. Here is an example where a guy has an OpenSCAD script that will produce a set of bevel gears with varied thickness, pitch, diamter, pressure angle, etc etc. Very specialized, but very cool it can be done as a script! http://www.thingiverse.com/thing:3575
_____ From: dave.cow...@gmail.com [mailto:dave.cow...@gmail.com] Sent: Sunday, December 12, 2010 7:04 PM To: pythonOCC users mailing list. Subject: Re: Re: [Pythonocc-users] Anyone seen this? Hi, Steve: I'm definitely in agreement with you about CORBA/SOAP. I'm a huge fan of MOM solutions as opposed to SOAP and such. HTTP tends to have some benefits when interacting with services over the internet ( B2B ), but that is really just because nobody has proposed a good MOM-over-HTTP spec that everyone can agree on yet. The big decision, of course, is whether to define an API in terms of essentially function calls (like IDL ) or 'messages' -- which an have an arbitrary structure, but are basically transport independent. Though I find MOM architectures are more scalable and flexible, they tend to be overkill when most of the system will be running in-process anyway, which seems likely in this situation. One other thought to throw out in this topic is the 'analysis paralysis' issue. Though it would be good to build on the work of others, and to be consistent with existing specs in order to ensure widest adoption, sometimes a spec that's actually implemented but less than ideal is the best choice. As I see the issues discussed, I'm thinking more and more that it be best to just make some reasonable decisions on how the API works and go with it. Perhaps this could be loosely based on the OMG spec to start with, but I don't think its likely much will be gained by sticking to it. PythonOCC is strong, and AFAIK is the most advanced of all the open source kernels. Sticking with a CORBA- based API will likely limit the flexibility that a pure python based library could offer. I don't think it is necessary to be able to interoperate with other companies or systems to be successful. There is a good chance that the mainsteam modelling kernels will not publish an API that conforms to a standard interface anyway, they will want a proprietary API to lock in their customers. My gut feeling says the best approach is to look at the OMG spec to understand the issues and learn about the problem domain, then design an API that works well with pythonOCC and move on it, not worrying from that point whether it is OMG compatible or not. On Dec 12, 2010 6:47pm, Stephen Waterbury <water...@pangalactic.us> wrote: > On 12/12/2010 04:44 PM, Thomas Paviot wrote: > > > Dear Steve, > > > > The OMG CAD Services (OCS) specs are still freely available from the OMG > > website (the latest release is 1.2 : http://www.omg.org/spec/CAD/). > > > > > Thanks, I just removed the 1.1 doc from my site! (I had a local > > copy and hadn't bothered to check whether OMG still had an > > accessible version of the spec.) > > > > > I agree > > with you about the fact that the OCS is a good starting point. I briefly > > studied the OCS some months ago, and have a few notes I'd like to discuss with > > you: > > > > * from a technical viewpoint, the CORBA technology is perfectly suitable > > for synchronous sharing of business objects through a network. In my > > opinion, an asynchronous collaboration should be enough (regarding the > > business needs related to usual CAD workflows) and Web Services (WSDL, > > SOAP etc.) might just be perfect; > > > > > I find CORBA a bit "heavy" compared to some more recently > > introduced technologies, and nowadays I don't think of OMG specs > > as implying CORBA implementation, albeit they are still defined > > using IDL (which I kind of like). I must also confess an > > aversion to SOAP/WSDL -- yes, they work, but they are (IMO) also > > rather clumsy to develop with. Apologies for being so judgmental > > about those -- I'm sure they will work fine for any developer who > > is more comfortable with them than I am. I am very interested in > > building an architecture for communications between CAX tools and > > services, but I currently plan to use lightweight message-based > > technologies to implement a common "info bus" through which tools > > and services would communicate using a set of pub/sub type APIs. > > Of course, there may also be use cases for which remote object > > protocols are appropriate, but a lot of tools and services will > > require wrappers to participate and I suspect messsaging wrappers > > may be easier to write than remote-object-style wrappers that > > have to maintain a lot of state. That certainly doesn't preclude > > defining objects as the things that are communicating, so perhaps > > it's just a remote object architecture by another name. ;) The > > particular technology that I'm planning to experiment with is > > Twisted's "Asynchronous Messaging Protocol", AMP[1], which is > > very lightweight and elegant (Twisted also has Perspective > > Broker[2], an interesting remote object protocol). > > > > > * from a semantic viewpoint, whereas the computational model is explicit, > > the informational model is mostly implicit. For instance, the > > CadBrep::Face class definition could be whatever. In my opinion, it could > > be a good thing to harmonize the semantics contained in the OCS and the > > STEP parts 42, 55 etc.; > > > > > I wholeheartedly agree with that! In fact, speaking of > > semantics, I'd actually like to have an ontology (OWL) from which > > the informational model (schema) is generated -- of course, this > > is a design principle I'm trying to implement in my > > work-in-progress, PGEF[3] ... ;) > > > > > * some of the methods defined in OCS are strongly platform dependent: for > > instance CAD User Interface, paths etc. A high level CAD API should > > abstract these concepts and be platform/CAD system independent; > > > > > I certainly agree that all methods should be platform > > independent. In a quick glance I didn't notice anything > > platform-dependent -- can you give an example? > > > > > * at last, I have a few doubts about the persistent identification since I > > know it's still considered as a major issue. And I wonder whether or not > > the OCC topological naming could be mapped to these persistent_ids. > > > > > I agree there could be issues there also -- a big stumbling block > > in trying to implement a product model in which important printed > > circuit board features could have their identities survive a > > round-trip (import/export) to/from an MCAD tool is the lack of > > session-independent persistent identifiers in MCAD tools at the > > "feature" level. Of course, you might have meant something else > > ;), but that is one persistence issue I'm aware of! > > > > For me this is a very useful thread and I'd like to help in any > > way I can with helping to define and test a high-level CAD API. > > > > Cheers, > > Steve > > > > [1] http://twistedmatrix.com/documents/8.1.0/api/twisted.protocols.amp.html > > [2] http://twistedmatrix.com/documents/current/core/howto/pb.html > > [3] https://pangalactic.us/repo/pgef > > > > P.S. Thomas, do you think someone from the pythonOCC team might > > participate in PDE 2011? I hope so! > > > > > Best Regards, > > > > Thomas > > 2010/12/12 Stephen Waterbury water...@pangalactic.us water...@pangalactic.us>> > > > > 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-C heney.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 dave.cow...@gmail.com> dave.cow...@gmail.com 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 dfa...@frontier.com> dfa...@frontier.com 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 Pythonocc-users@gna.org> Pythonocc-users@gna.org Pythonocc-users@gna.org>> > > > > >> https://mail.gna.org/listinfo/pythonocc-users > > > > > > > -- > > Sent from my mobile device > > > > _______________________________________________ > > Pythonocc-users mailing list > > Pythonocc-users@gna.org Pythonocc-users@gna.org> Pythonocc-users@gna.org Pythonocc-users@gna.org>> > > > > https://mail.gna.org/listinfo/pythonocc-users > > > > > > > > > > _______________________________________________ > > Pythonocc-users mailing list > > Pythonocc-users@gna.org Pythonocc-users@gna.org> > > https://mail.gna.org/listinfo/pythonocc-users > > > > > > > > _______________________________________________ > > Pythonocc-users mailing list > > Pythonocc-users@gna.org 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 >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
