-
Notifications
You must be signed in to change notification settings - Fork 284
Long term goals
Denis Barbier edited this page Sep 18, 2013
·
9 revisions
On this page, we discuss goals we would like to achieve, to help us prioritize them.
- Rationale:
- C++ difficulty: low
- Impact on OCE code: medium
- Impact on 3rd party code: low
- 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
- 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?
- Rationale:
- C++ difficulty: low
- Impact on OCE code: high
- Impact on 3rd party code: medium
- Rationale: see this explanation, by Scott Meyers
- C++ difficulty: low
- Impact on OCE code: high
- Impact on 3rd party code: null?
- 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
- 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?
- 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
- Rationale:
- C++ difficulty: high
- Impact on OCE code: high
- Impact on 3rd party code: high, unless we find a compatible solution
- Rationale:
- C++ difficulty: medium
- Impact on OCE code: high
- Impact on 3rd party code: high, unless we find a compatible solution