pde2011 pythonocc project status and plans

PythonOCC project status and plans

Thomas Paviot (pythonOCC/LCPI)*, Jelle Feringa (pythonOCC/TU Delft)**, Stephen Waterbury (NASA/Goddard Space Flight

Center)****[email protected]; *[email protected], **

[email protected]

13th NASA-ESA Workshop on Product Data Exchange11-12 may 2011Siemens Innovation Center, Cypress, California

Creating and distributing 3D engineering objects through wide scale networks

2

Agenda PythonOCC: project background and brief history of

the project Project issues WebGL backend – COLLADA mapper High Level standard based API Questions

13th NASA/ESA Workshop PDE 2011 - pythonOCCMay 2011, 12th

The primary purpose: bring an engineer oriented layer between end-user CAD software layer and a software developer oriented CAD kernel.

3

CAD softwareEnd-user level(VB scripting,VB automation)

Modeling kernelDeveloperLevel (C++)

Missing intermediate level


Project status

First implemented features

4

Developerlevel

pythonOCCA python library for CAD/CAE

Features: 2D/3D modeling Data Exchange

(STEP/IGES/STL) Basic GUI features


Project status

Then implemented addons related to Mesh and Parametric modeling features

5

Meshing features (Quad, triangles, 2D and 3D)

Parametric modeling features


Project status

Rigid body simulation

Physics + « RealTime » collision detection

13th NASA/ESA Workshop PDE 2011 - pythonOCC 6May 2011, 12th

Project status

Experimenting distributed CAD/Mesh/FEM architecture (2/2): Service Oriented Architecutre


Project status

Experimenting distributed CAD/Mesh/FEM architecture (2/2): implementation


Pythonocc geometry

Salomé mesh CodeAster FEM computation

Workflow sync

Project status

Long term objective: creating and distributing 3D engineering objects over wide scale networks using open standards and Free/Open Source software (FOS).

Subproject 1: experimenting latest 3D visualisation technologies (WebGL/COLLADA) in order to enable sharing/exchanging 3D visualization

Subproject 2: develop a high level API on top of OpenCascade data model in order to enable sharing/exchanging 3D procedural models as well as concurrent 3D modeling.


Long term strategy

COLLADA / WebGL standards for a consistent 3d visualization supply chain COLLADA : « a royalty-free XML schema that enables digital asset

exchange within the interactive 3D industry. » Dedicated to 3D information exchange. Exchange of BRep geometry, tesselated geometry, annotation,

textures, shaders, kinematics etc. Partially implemented so far by vendors

WebGL (http://www.khronos.org/webgl/): « WebGL is a cross-platform, royalty-free web standard for a low-level 3D graphics API based on OpenGL ES 2.0, exposed through the HTML5 Canvas element as DOM interfaces. […] WebGL brings plugin-free 3D to the web ». Dedicated to 3D information rendering. Supported by latest browsers generation (Google Chrome 10+, Mozilla

Firefox 4.0, Opera 11) but MSExplorer. Many javascript libraries available (O3D, three.js, GLGE, spidergl etc.)

enabling easy deployment of WebGl.


SP1: WebGL support for visualization

Plugin free geometry visualization: Demo 1


Step 1: The geometry/topology is generated from a pythonocc script.




Step 2 (optional): The shape is rendered through the local builtin OpenGL driver and a Qt window.




Step 3 : the shape is tessalated and exported to a javascript file named ‘shape.js’




Step 4: include the shape.js file into a html file through the HTML5 canvas feature




Step 5: serve this html file with any http server/web framework (python based or not).




Step 6: render the html file with a WebGL compliant browser (example FF4, Chr10+).


Plugin free geometry visualization of a standard file: Demo 2


ABB robot IRB6400R – STEP file obtained from the ABB online catalog.


Plugin free geometry visualization for a standard file: Demo 2


STEP File: 6Mb size, 75895 entities STEP file processed by step_to_webgl.py, a 80 lines

python script that does: STEP file parsing Mapping to OCC topology/geometry data model Meshing Javascript file generation

Running step_to_webgl.py over this 6Mb STEP file takes about 140s and consumes up to 400Mb of memory. Can’t be used for realtime interaction with the shape yet, but the script is not optimized at all.

The js file is rendered the same way (FF4/Chr10+)


Plugin free geometry visualization for a standard file: Demo 2



Plugin free geometry visualization – experimenting shaders : Demo 3


3d file « cyinder_head.brep » downloaded from the OpenCascade website.

File processed by the python script to be exported as a javascript file.


Plugin free geometry visualization – experimenting shaders : Demo 4


Chrome 11

Firefox 4


Conclusions regarding the WebGL experiments (1/2) WebGL implementation is incredibly fast and stable

in all tested modern browsers (FF,Chr,WebKit) Many WebGL/js libraries are available. Difficult to

choose one The WebGL technology is ready to get deployed

everywhere *now* Game technologies dealing with huge scene

rendering (LOD) should meet 3D engineering needs for big model visualization



Conclusions regarding the WebGL experiments (2/2) WebGL success is certain (in our opinion!). COLLADA seems to be perfectly suitable for 3D visualization

archive/exchange. However, COLLADA Brep implementation by vendors is less

sure. Our choice: untill all major CAD vendors implement

COLLADA Brep importers/exporters or some STEP/COLLADA mappings have proven to be lossless model transformation, the concurrent use of STEP/COLLADA seems to be necessary: STEP files for the model definition COLLADA files to store model outputs: tesselation,

annotation rendering, kinematics animation A robust workflow to ensure STEP/COLLADA files

consitency A step2collada.py script is currently being developed. Too

early to have something to show, more to come in a few weeks.



Need for a High Level API (HLA)

The OpenCascade data model has a very small granularity. Thousands of classes/methods available.

Is it possible to build an intermediate layer on top of this API? That is less granular than the 3D kernel level datamodel, but a

bit more granular than the ‘cad user’ feature tree level That does not acts as a ‘filter’ over the kernel data model: we

look for a « lossless semantics compression » of the underlying data model that would bring CAD modeling with pythonocc at the « engineering level » (see sl.2)

This HLA would be used to: Quickly and efficiently create complex shapes based

upon the smallest possible set of objects/methods/functions. Similar to the ‘MacroParametric approach’, but without developing a new scriping engine (we’re running python).


Sp2 : High Level API

Local and online CAD services HLA on one machine: ‘local’ CAD services Make this services publicly avaiable for other machines over

a network: ‘distant’ CAD services OMG already released a set of CAD services (r1.2, january

2005) : « The intent is to establish a series of high-level engineering interfaces that do not require low-level data structures to answer mechanical engineering queries » Good! But: CORBA based (outdated technology) Misses a lot of functions to enable ‘modeling’

So, what we’re currently working on: A top/down approach from user needs A bottom/up approach from CAD kernel developer

needs (hope they’ll match one day!) Distributing services over a network



HLA: top/down approach Based upon the analysis of OMG CAD Services 1.2 and needs of

users wishing to model 3D shapes. Rewriting a new CAD services API from scratch. Objects/Services

classification are currently being described as an ontology with the help of Protégé. Trying to answer the question: what a CAD service should be? What do we need?



HLA: the ontological level



HLA: bottom/up approach Trying to answer the question: how

could we abstract the current low level data model according to the way we use to develop with pythonocc?

A pragmatic approach aiming at answering the question: what we can actually do in a short term? An « experimental programming » approach that is absolutely necessary for an incremental progress leading to « final » API.

Classes Vertex,Edge,Part,Solide,Curve,DiffGeomCurve etc. already implemented

Bottom/Up and Top/Down must converge to an acceptable compromise so that we’re able to quickly provide a working/unittested API.



HLA: from local to distant services

No WSDL/SOAP based webservices. Need for a lighter protocol/architecture. 2 architectures

experimented : Message oriented architecture: experimenting Twisted

AMP or Perspective Broker protocols, AMPQ REST web services



A blog: http://www.pythonocc.org


Further information

A google code project page (svn repository, issue tracker, wiki etc.): http://code.google.com/p/pythonocc


Further information


Further information

Contacts

Dr. Thomas PaviotpythonOCC project founder/co-managerArts & Metiers ParisTech – Researcher at Product Design and Innovation Laboratory - Paris, [email protected]

Jelle FeringapythonOCC project co-managerTU Delft – PhD candidate at Hyperbody research group -Delft, The [email protected]

http://twitter.com/pythonocc

Twitter account

Thank you ! Any questions ?


pde2011 pythonocc project status and plans

Technology