Skip to main content

PythonOCC : Open Source interactive CAD shell (and how to run it on OSX)

What is PythonOCC?

PythonOCC is an Open Source (LGPL) Python-wrapper for OpenCASCADE.

So what is OpenCASCADE (OCC)?

This is an advanced Open Source (custom license) modeling kernel, comparable to commercial engines, such as ACIS or Parasolid, which are used in quite some commercial CAD programs. When you want to develop CAD software, you could use OCC and write programs in C++.

And why using Python?

With this wrapper, you can create CAD and geometry scripts in Python, which is an interpreted Object-oriented scripting language. You can write almost "on-the-fly" and seriously reduce the implementation effort, by skipping the compiling-phase. You can even interact with a running program in the Python interpreter.
Want to read more about this?
So far so good. Now the nasty, technical stuff... I want to have it running on my Macbook Pro. Don't even attempt to do this if you lack the Developer extensions (XCode needs to be installed and X11, which provides most of what you need). I'm using Snow Leopard (OSX 10.6.8) and XCode 3.2.6, which are not the latest versions, now Lion has been released.
The rest of this post is quite detailed, but I'm putting this out for others to comment on and learn from. It is quite a long story, sadly. Not a download, install, accept EULA and run type of software installation.
1. Install OpenCASCADE through OCE

While OpenCASCADE and Python are both cross-platform, OpenCASCADE is not natively supported on OSX. There is a team of volunteers that have done a tremendous effort to get OpenCASCADE re-organized and more tweaked for current compilers and platforms. This is the OpenCASCADE Community Edition (Google OCE-dev Group and Github OCE source Repsitory).

So I downloaded the binary installer from Github for OSX, currently at release "OCE 0.6.0". This will be installed in /Library/OCE/0.6.0 although the installer doesn't inform you about this!

Then you have to ensure the X11.app is available (the XWindowing system, which is quite alien from the native Aqua interface from OSX).

xterm > terminal program in X11
If all goes well, you can test to see if OpenCASCADE (in the OCE version) is properly installed when you can launch DRAWEXE, a graphical, command-line utility to interact with OCE, which is available in the bin folder. There is a menu-window and a prompt in the terminal. This is old school ;)

Then you can follow the DRAWEXE-example from the OpenCASCADE website.


Beware, I've had to manage a few things to get this far:
  • Install Developer tools from Apple (XCode, X11)
  • The binary installer for OCE is precompiled for OSX Snow Leopard (10.6) in 64-bit. If you use a different platform, you should probably compile from sources. This is made easier with the OCE distribution.
  • I've had to install 'ftgl', which is the OpenGL Font Rendering Library. To be able to use that, I had to go to the downloaded ftgl compressed archive, unpack it, open Terminal.app and "cd" into the folder and type:
    • ./configure
    • make
    • make install

2. Install PythonOCC from sources

While the PythonOCC team provided binary installers, they are currently outdated, so I started from the most recent source files. The sources are hosted on github and use the git version control system. This is a tool to work on a local copy, with the possibility to update from the github site, create your own local branches, merge them etc... If you don't know what this all means, you can also download a compressed archive if you want.


I've installed git from Macports or fink, IIRC. Fink and Macports are both ways to install typical Linux-applications, similar in approach to the package manager tools found in Linux (e.g. apt-get). This takes care of getting all dependencies included, without destroying your OSX system too much...

Create a folder somewhere, go into it from the Terminal and type:

  • git pull git://github.com/tpaviot/pythonocc.git

PythonOCC comes with two embedded libraries, which are not trivial to install.

Come to think of it, I had to also install the CMake build system from Kitware... This is an Open Source build system, which makes it easier to write makefiles (the text files to tell your compiler how sources are turned into executable programs). This cmake-file can be written platform-independently (up to a certain level) and be used in Linux, Windows, OSX.

  • SMESH is used for advanced control over meshing and tesselation. Since it is quite hard to install and requires a fortran compiler, they are trying to remove it as a separate module to install.
  • GEOM is a parametric framework, based on SalomeGeometry. The sources are included in PythonOCC (/src/contrib/GEOM-5.1.5.9).
    • Before I could compile, I had to comment out a few lines in the CMakeFiles.txt file, which is the input for CMake. That was because the queried environment variables have changed in OCE 0.6.0 and are to a large extent not required anymore. I placed a # sign before some of the lines:
      • #FIND_PATH(OCC_INCLUDE_PATH Standard_Real.hxx $ENV{CASROOT}/inc)
      • #SET(OCC_LIB_PATH "$ENV{CASROOT}/lib")
      • #FIND_LIBRARY(OCC_LIB_PATH TKernel PATHS $ENV{CASROOT}/lib)
      • #MESSAGE(${OCC_LIB_PATH})
    • Then I started compilation, using CMake in the GEOM folder (but build in a sub-folder to not mess up the source folder):
      • mkdir _MyBuild
      • cmake -DOCC_INCLUDE_PATH=/Library/OCE/0.6.0/include/oce -DOCC_LIB_PATH=/Library/OCE/0.6.0/lib ..
      • make
      • make install
    • If all goes well, the GEOM modules are installed on your system. In my case, the libraries arrived in /usr/local/lib/GEOM-5.1.5.9 and the header files in /usr/local/include/GEOM-5.1.5.9
Now PythonOCC itself... Not fully there, yet... by far.
    I went back to the main pythonocc folder, downloaded from github. The process takes two steps:
    • python setup.py build --disable-SMESH --with-occ-include=/Library/OCE/0.6.0/include/oce --with-occ-lib=/Library/OCE/0.6.0/lib --with-geom-lib=/usr/local/lib/GEOM-5.1.5.9
    • python setup.py install --disable-SMESH --with-occ-include=/Library/OCE/0.6.0/include/oce --with-occ-lib=/Library/OCE/0.6.0/lib --with-geom-lib=/usr/local/lib/GEOM-5.1.5.9
    So this is a two-step process: building and installing. If all goes well, you will have an additional OCC folder inside your main site-packages of Python: /Library/Python/2.6/site-packages

    To check that OCC is actually available inside Python, go (again) to the Terminal.app and type:

    • python

    to launch the current default python (the one installed from Apple) and load the OCC libraries:

    • from OCC import *

    This will take a while, but as long as you don't see errors, you are good to go.


    3. Graphical User Interface and windows?

    While you can start writing command-line python-scripts directly, there is a caveat! There is no GUI.

    And while I would like to say that there is an easy, cross-platform solution, alas it is convoluted on OSX.  Last time I tried to install PythonOCC on Windows, all was up and running in maybe 20 minutes: python, OpenCASCADE, PythonOCC, Qt, PyQt4.

    The PythonOCC team have come up with three "backends" for GUI's and one wrapper class around it that frees the user from too much GUI-stuff.
    • wx : a wxWidgets based backed (which is a cross-platform GUI system, for Windows, Linux, OSX).
    • qt : the Nokia Qt frameworks, including GUI stuff, running on most systems (Windows, Linux, OSX, embedded Linux, some smartphones).
    • python-xlib : an XWindow based simpler layer.
    For OSX, the wx option is, well, broken. Don't attempt it, unless you "really" know what you are doing. I'm not. I tried in the past and gave up. It is a mixture of X11, OSX and hacking.

    And to use Qt in python, you need a wrapper. There is PyQt from Riverbank software (which has some license limitations) and more recently PySide which has a more liberal license. All instructions point to PyQt so that is what I will use.
    1. If you have installed Qt4 before, beware! On OSX, there are two version: qt4-mac and qt4-x11. The first is native, using Cocoa and the Aqua interface. Really good integration in OSX and very usable. While this is totally recommended for any cross-platform development. However... not for OpenCASCADE, at the moment. So I uninstalled Qt4-mac, alas.
      • sudo /Developer/Tools/uninstall-qt.py
    2. Then you need to install the qt4-x11 version, which is far from easy. I used Fink. This is only the bare summary:
      • install fink and update it so it is current:
        • fink selfupdate
        • fink update-all
      • This can take quite a while... and comes with a large amount of software: cmake, python, qt4-mac... However, everything resides in /sw that does not hinder the rest of OSX.
      • Now you are ready to install qt4-x11:
        • fink install qt4-base-x11
      • This comes with a few hundred dependencies and can take quite long (a few hours on my machine). I had to answer a few questions and avoided some "aes" options, as described in my comments on the PythonOCC blog.
      • check that the Fink version of qt4-x11 is installed. Type "qmake -v" into a terminal. It should point to qt4-x11 inside the /sw folder.
    3. Before you can use PyQt4, you need to install another library, called sip from Riverbank Software (who also make PyQt4).
      • Download the installer. I've had an API conflict between the precompile PyQt4 form the PythonOCC.org site, so I have to use an older version.
        • SIP-4.12.3 complained:  "RuntimeError: the sip module implements API v8.0 to v8.1 but the PyQt4.QtCore module requires API v7.0"
        • SIP-4.10 worked fine.
          • python configure.py
          • make
          • sudo make install
    4. Now you can use the pre-compiled PyQt4 provided on the PythonOCC.org website. There are pre-compiled released for OpenCASCADE and PythonOCC too, but they are for older versions (OCC 6.3.0, while OCE 0.6.0 is using OCC 6.5.1). The number difference is small, but is about two years older.
    5. --- EDIT ---- I've had to hack one line in the OCCViewer.py file (installed inside your Python site-packages folder: the first line was included, but gave an error when running a script using the GUI. I've had to replace the modules call with the expected result string:
      • comment out v3d_module_library = sys.modules['_V3d'].__file__
      • replace with v3d_module_library = '/Library/Python/2.6/site-packages/OCC/_V3d.so'
    Finally something that works

    Now some picture of a running system...

    Double-clicked a python script in the PythonOCC Examples/Level1/Geometry folder, called "Geometrydemos.py". X11 should be started and the python script runs inside a Terminal.



    This is an interactive view: you can zoom, pan, orbit, select items and call some commands in the menu. It uses X11 for display (see the X-cross in the window), but other than that, it runs directly inside OSX.

    My personal thought: installing XCode, X11, fink (with hundreds of programs that are already inside OSX), OpenCASCADE, qt4-x11, SIP, PyQt4 and finally PythonOCC to make small scripts is quite a contradiction... But it is open, flexible, cross-platform and can be the basis to prototype a new CAD system that innovates.

    Comments

    1. hi Stefan,

      you're absolute right that installing pythonocc on osx is horrible. it takes 5 minutes on ubuntu, is easy on windows, *not* so on osx...

      however, things are looking up; there is an installer of OCE, plus we're investigating whether we can embed an X11 widget in Cocoa. that would allow us to use vanilla pyqt4 / pyside, which come with an installer [ pyside does for sure ]. so, that would make installing pythonocc considerably easier.

      thanks for a comprehensive article on installing pythonocc!

      ReplyDelete
    2. Jelle,

      I agree it's horrible. Certainly when it should not be needed.

      My biggest frustration was that I had to uninstall a perfectly working Qt4-mac, which I wanted to use in other programs.

      Don't know if both can live at the same time... Without too much environment variable tinkering.

      OCE is a real improvement, I agree. And if PythonOCC can build on top of that, you have a good combination.

      Is PySide a valid alternative for PyQt4 ? Have you tried it?

      Groeten vanuit België ;)

      ReplyDelete
    3. Why do mechanical engineers use the CAD software?

      ReplyDelete
    4. I don't understand the question...
      Why wouldn't mechanical engineers use CAD software?

      In the case of PythonOCC, it is a very open, unlimited environment if you are capable of developing your concepts as a script. You can write any construct you want, develop it, test it, experiment it.

      When comparing with a traditional CAD system, you are mostly able to use the underlying tools and commands as they were developed by the software company.

      In pythonOCC you can 'talk' to the geometric kernel (OpenCASCADE) and create your own toolset. In a tool such as SolidWorks (guessing from the site your name links to) you have to use the SolidWorks toolset.

      For some design tasks, a full system is probably the best solution, but for "tinkering" a home-brewn toolset, e.g. combining a modeling library with a CNC code generator toolset, with another toolset (e.g. OSC, SOAP, XML...) you are not really restricted anymore. And that might be the motivation to use such an open system, certainly if you value Open Source concepts.

      ReplyDelete

    Post a Comment

    Popular posts from this blog

    Improve usage of BIM during early design phases

    When I was collecting ideas for a book chapter on BIM (that seemed to never have emerged after that), I collected 10 ideas, which I believe still reflect good recommendations to improve the usage of BIM during the early design phases. These ideas are related to BIM software, but you can apply them in any flavor, as long as you can model with Building Elements, Spaces and have control over representation. Introduction This article gives an overview of several recommendations and tips, to better apply BIM applications and BIM methodologies, in the context of the early design phases. Many of these tips are applicable in any BIM application and they are based on experience gathered from teaching, researching and using BIM software. Sometimes they could help software developers to improve the workflow of their particular BIM implementation. Tip 1 : Gradually increase the amount of information In the early design phases, the architect makes assumptions and lays out the main design in

    Getting BIM data into Unity (Part 9 - using IfcConvert)

    This is part 9 of a series of posts about getting BIM data into Unity. In this post, we’ll discuss the IfcConvert utility from the IfcOpenShell Open Source IFC Library to preprocess an IFC model for integration with Unity. This is (finally?) again a coding post, with some scripts which are shared to build upon. Conversion of IFC into Unity-friendly formats The strategy with this approach is that you preprocess the IFC-file into more manageable formats for Unity integration. Most Web-platforms do some sort of pre-processing anyway, so what you see in your browsers is almost never an IFC-file, but an optimised Mesh-based geometric representation. However, it wouldn’t be BIM-related if we’d limit ourselves to the geometry, so we will parse the model information as well, albeit using another, pre-processed file. IFC to Wavefront OBJ I used a test IFC-model and used the IfcConvert-utility converted it into OBJ en XML formats. The default way to use it is very simple:

    Getting BIM data into Unity (Part 8 - Strategies to tackle IFC)

    This is part 8 of a series of posts about getting BIM data into Unity. In this post, we’ll discuss IFC as a transfer format towards Unity. As with the previous post, this is not a coding post, although hints and examples are provided. Open BIM and IFC Everybody who ever met me or heard me present on a conference or BIM-lecture will not be surprised to hear that I’m a strong believer in the Industry Foundation Classes (IFC), an open standard, with already two versions published as an ISO standard, being IFC2x2 and IFC4 (but surprisingly not IFC2x3 which is widely used). In the ideal world, this would be the format to use to transfer BIM data into another environment, such as Unity. So what are our options? Looking in the Unity Asset Store Assimp is a library which supports multiple formats, including IFC. https://assetstore.unity.com/packages/tools/modeling/trilib-unity-model-loader-package-91777   I did a few attempts, but alas without any success. It is possib