Wed, 03/09/2016 - 15:55
Preface
Open CASCADE Technology contains TKMeshVS - a component completing the AIS classes from TKV3d component with capabilities to display mesh structures not necessarily bound to any TopoDS_Shape.
TKMeshVS does not define any own data structure for storing mesh information; instead, it defines quite flexible interface MeshVS_DataSource for accessing data from arbitrary sources implemented on application level.
The data sources and mesh presentation are separate concepts in TKMeshVS allowing to compute different presentations for the same mesh depending on application needs by implementing MeshVS_PrsBuilder interface. TKMeshVS also contains built-in presentation builders including normal shaded presentation (MeshVS_MeshPrsBuilder), shrink presentation (elements reduced in size) and presentations with colors assigned to nodes (MeshVS_NodalColorPrsBuilder) or elements (MeshVS_ElementalColorPrsBuilder).
The component is quite flexible and is not limited to surface meshes, but also supports meshes containing 3D elements.
TKMeshVS evolution
Unfortunately, the evolution of this component has been thrown out of the board for many years - with only minor efforts. Being designed for working with mesh data of specific sizes (quite small nowadays), standard presentation builders suffer from performance and memory usage issues.
There are two main reasons for this - no visible interest of this component from perspective of new projects and community, and overall complexity of the component supporting rarely used features such as 3D elements.
We still believe that this component might be quite useful and its evolution should be stimulated. However, to reduce our efforts, we would like to focus on the main use case for this component - supporting of surface meshes. So now we consider the following features to be removed in the nearest future:
- Support for 3D mesh elements
- Support for 2D mesh elements other than triangles and quadrangles
Note that MeshVS architecture allows implementing corresponding functionality outside OCCT at application level if needed.
Additional architectural changes might be also considered to improve working with big data sets from presentation builders and selection, which would require considerable porting efforts for existing applications using TKMeshVS component right now.
Feedback request
We would like to ask community for a feedback upon proposed changes in TKMeshVS component and general information if this component is used or not in your projects.
Kirill
Thu, 03/10/2016 - 00:44
Hello Kirill,
Thanks for asking feedback on MeshVS. Let me offer some of it.
We used to use MeshVS in early years of our product but then dropped. Indeed, its API (DataSource) does not formally enforce any predefined data container. However the API itself which prescribes construction of packaged data maps effectively does enforce that - even if your underlying data structure may not be using them (and most likely not), you have to implement this API. This leads to essential growth of the memory footprint - by creating these packed data maps. XSDRAWSTLVRML_DataSource is an example of this. Based on StlMesh_Mesh it has to populate and store these maps to interoperate with MeshVS.
Obviously this has performance and footprint penalties when working with larger models.
We ended up with creation of simpler subsclasses of AIS_InteractiveObject implementing visualization (and selection) for polygonal representations. These are more streamlined and easier to understand and maintain comparing to MeshVS-based classes.
We still periodically refer to MeshVS for recommended use of primitives (e.g. Graphic3d_ArrayOfSegments vs OfPolylines), selection (#27180) and like. In this sense it serves as reference implementation.
Bottom-line: there is still a value in this component either direct or indirect. Given that you actively invest into visualization you likely do need an example of efficient use of non BRep-based geometries. A separate library (not embedded into TKV3d) does offer a very reasonable approach being optional part of the library.
My 2 cents. Hope this helps.
Roman
Thu, 03/10/2016 - 18:39
We are using TKMeshVS together with XSDRAWSTLVRML_DataSource for fast import and display of STL-files as it is often proposed on the forum, e.g.
http://www.opencascade.com/content/stl-import-2
In context of the evolution you might also consider the proposed refactoring of XSDRAWSTLVRML_DataSource [http://www.opencascade.com/content/xsdrawstlvrmldatasource-serious-need-....
Maybe in future we would also be interested in displaying 3D mesh elements. Would there be another possibility to do this after your changes or it should be done at application level as you wrote? Isn't Salome able to display 3D mesh elements. Does it use TKMeshVS for it or some other mechanism?
It would also be good to clarify the relation to AIS_Triangulation - when to use what, differences,...
Wed, 03/16/2016 - 10:03
SALOME utilizes VTK for mesh visualization, it is like this for historical reasons: MeshVS is much younger than Mesh module in SALOME platform.
Meanwhile, MeshVS architecture allows you to implement 3D mesh elements support at the level of your software - though this is rather a usage topic to be addressed on another forum.
Wed, 03/16/2016 - 10:51
From strategic point of view, the key idea behind the currently planned MeshVS evolution steps is to keep it light-weight (to decrease its maintenance cost) and generic and introduce a minimal or nearly-zero overhead at graphic data preparation and rendering stages, taking into account our experience accumulated in this area during the years of graphic performance optimization.
At the same time, we are going to keep at least the same level of flexibility for application developers, so that they are able to customize it according to their particular needs at the application level, without sacrificing performance.