Dear all, A few years ago, I developed a software aimed at providing rigid body simulation features to Catia V5 or SolidWorks. This project, known as "Decade dynamics", is not active anymore although many users are frequently asking for new features or bugfixes (for your information, a website dedicated to the project is available at http://www.decade-dynamics.org, there also is a PDF document here: http://download.gna.org/decade/decade_A4_recto_basse_def.pdf and http://download.gna.org/decade/decade_A4_verso_basse_def.pdf - All this material is in french, sorry).
The limitations I faced when working on that project are the root of my motivation to start the pythonOCC project: - the small 'free' API provided with Catia or SolidWorks (a VB API) is not sufficient to access all internal classes/method, - the complete API (known as CAA for Catia) is very expensive, - there are licensing issues if you ever want to redistribute such a program. I chose to distribute Decade under the GPL license, and never had any problem with software vendors: I never made money with it, there's no real business opportunity, so lawyers dont' care about my work. However, I'm still interested in rigid body simulation, since it's much important when working in the robotics/mechatronics field and, more generally speaking, in engineering. I committed to the pythonOCC subversion the first draft of a DYN package dedicated to rigid body simulation (you can have a look at this video to see the first results: http://www.youtube.com/watch?v=IW5VYbCGFYc). This DYN package is at the same level as PAF(Parametric Application Framework). The set of sub-packages PAF/DYN/MSH/FEM are what we called the 'Level2 API': it's an intermediate layer between the OCC kernel (LeveL1) and the applications that can be built on top of them. The goal is also to make them interoperable, I mean being able to exchange data in a consistent way: I imagine a 3D complex model, made with PAF, simulated with DYN to get forces in joints, checked with a FEM analysis, then optimized according to these results (the design/simulation loop), and finally exported to a STEP file for manufacturing. All of these sub-packages would rely on a semantically explicit knowledge (KBE). Well, this is not a roadmap, rather a long term objective... Please let me know if you have any comment or suggestion, Best Regards, Thomas
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users