Dear Pierre, First, rigid body simulation and assembly sequencing are, according to me, really different topics in term of objectives and expected outputs (the slideshow attached is quite old, one of my colleague presented a more recent paper related to this topic at the MOSIM'08 conference)
The second point is that the objective of the pythonOCC project is not to cover the huge scope of engineering and implement the best ideas from best papers published in best journals/conference. It's something that can not be achieved by a few people. We just aim at providing a platform enabling such an implementation in the easiest possible way. The development strategy can be sum up in a few words: let's take the best existing free and open source libraries in engineering field, and let's find a way to integrate them in a new consistent environment. Current pythonOCC release (0.4) is built upon OpenCASCADE, SMESH, GEOM. Then next one will add Traits support, OpenDE (rigid body simulation), maybe fem solvers etc. Each of those libraries are developed by many skilled engineers. The added value of the pythonOCC project is then the *integration* of these libraries. Free and open source development model, as well as the use of standards, make such an integration be achieved by a few motivated people (actually, it's not demonstrated yet, but I want to prove that it's possible). The added value being *integration*, it's out of scope of the project to develop/implement low-level features such as 'automatic assembly sequencing from semantics extraction'. Best Regards, Thomas 2010/2/24 Pierre JUILLARD <pierre.juill...@gmail.com> > > Dear Thomas, > > Following you mail concerning rigid body simulation, I wanted to mention a > work illustrated on the OpenCascade website concerning modelling of assembly > and that may be related to rigid body simulation most notably in the > "detection of contacts" topics. > > Here is the link of the documents: > http://projects.opencascade.org/projects/doc/TheseNRejneri-FR.ppt > (you can also find the thesis on the web) > (link of this project: > http://projects.opencascade.org/projects/assembly.html > link of the project library page which gathers other interesting links: > http://projects.opencascade.org/projects/) > > I wanted to know if such features are available in pythonOCC? > Usually, such a management of parts is complex, but is very interesting to > identify assembly problems. > > I thank you in advance for your comments. > Best regards, > > Pierre > > > > > > 2010/2/21 Thomas Paviot <tpav...@gmail.com> > >> 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 >> >> > > _______________________________________________ > 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