Evolution of TKMeshVS component

Hello Author,

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.
Commenter-1

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,...

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.

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.

Hi,
After nine years, are the previously mentioned aspects of MeshVS still relevant, or have they become outdated? I'm curious because I haven't come across any significant changes to MeshVS in recent years.