Long term goals

On this page, we discuss goals we would like to achieve, to help us prioritize them.

In progress

Remove all compiler warnings

• Rationale:
• C++ difficulty: low
• Impact on OCE code: medium
• Impact on 3rd party code: low

Under discussion

Replace OCC containers by templated ones

• Rationale:
• C++ difficulty: high
• Impact on OCE code: high
• Impact on 3rd party code: high, unless we find a compatible solution

Replace OCC handles by smart pointers

• Rationale:
• C++ difficulty: medium
• Impact on OCE code: high
• Impact on 3rd party code: high, unless we find a compatible solution

Proper deallocation of OCC resources when unloaded

• Rationale:
• C++ difficulty: high, and high risks of conflicts with OCCT changes with respect to multithreading
• Impact on OCE code: medium
• Impact on 3rd party code: low

Implement a mechanism to find resource path at runtime

• Rationale: we want to get rid of all environment variables (they can still be used as fallback though). Resource path can be specified by compiling; this is acceptable on Unix, but not on Windows. We want a more flexible solution.
• C++ difficulty: medium
• Impact on OCE code: low
• Impact on 3rd party code: null?

Forbid C++ implicit conversions

• Rationale:
• C++ difficulty: low
• Impact on OCE code: high
• Impact on 3rd party code: medium

Forbid calling virtual functions in C++ constructors/destructors

• Rationale: see this explanation, by Scott Meyers
• C++ difficulty: low
• Impact on OCE code: high
• Impact on 3rd party code: null?

Make tessellation data easily accesible to 3rd party viz. libs

• Rationale : OpenGL builtin OCE renderer suffers from many drawbacks. It relies on a poor OpenGl implementation compared to dedicated visualization/rendering libraries. It should be easier to be able to export a tesselation from OCE to 3rd part rendering tools (libraries such as Vtk, Coin, or programs such as povray, Blender etc.). So far, tesselation algorithm used by OCE in the STL exporter or to feed the OpenGl pipe produces big triangle meshes. An interesting addon would be to implement a mesh reduction algorithm on top of the OCE mesher in order to generate lightweight tesselations (very useful for big models visualization, or lightweight clients like smartphones or internet browser via WebGL). These 2 features (tesselation+mesh reduction) could be integrated into a new TKTesselation toolkit.
• C++ difficulty : medium
• Impact on OCE code : null
• Impact on 3rd party code : null

Use the StepClassLibrary for new STEP AP import/export support

• Rationale : the current STEP importer/exporter relies on an old implementation. Currently supported STEP AP are 203 and 214 which are quite outdated. New STEP AP have been released (AP203e2, AP214e3), and other are in development. Making OCE support these new AP is a must since these standards have a big industrial impact. Unfortunately, reverse engineering the OCE STEP code is not possible : the bison/lex files that were used to generate the EXPRESS parser are not included in the OCC/OCE distribution. An interesting alternative is to rely on a 3rd part library, StepClassLibrary, distributed under the New BSDlicense, which is under active development. It's intended to parse an EXPRESS schema and generate a C++ library giving access to all entities/types defined in the schema. The first step of this project would be to replace existing EXPRESS OCE code with SCL, before trying to implement other Application Protocols (ap203e2, ap214, ap242, ifc2x4 etc.).
• C++ difficulty : high
• Impact on OCE code : high
• Impact on 3rd party code : null?

Add ACIS Sat import/export support

• Rationale : ACIS, used in AutoCad, is one of the most used modeling kernel; there's no open source importer for OpenCascade ACIS SAT format is well documented, so it should not be impossible to write an importer for OCE. That would IMHO boost OCE usage allowing exchanges of 3d models with AutoCad.
• C++ difficulty : medium ?
• Impact on OCE code : null
• Impact on 3rd party code : null