parallel applications with Open CASCADE

Hi Everybody !
I have two questions:
I have tried to show some AIS_Shape's form different Threads. The Application was crashed. Is the Viewer synchronized for parallel applications ?
A TopoDS_Shape will be triangulated bevor the AIS_Shape will be shown.
How can I triangulated it without to show it. Will be it triangulated one more time, if I show it ?


Roman Lygin's picture

Hi Dmitry,

I did not check the visualization part with Intel Inspector but I am more than certain it is not thread safe and cannot be used as is. I recall that in OpenGl package many data are passed between functions through static variables so obviously this can cause data races between threads and can lead to crashes (I just mentioned this in today's post on the blog). You need to apply synchronization to ensure thread safety.

2. The shape is triangulated using BRepMesh. Triangulation is not recomputed unless the requested deflection is finer than one used for already stored triangulation.

Hope this helps.

--- - the Open CASCADE blog

Dmitry Khabi's picture

Tahnk you.
BRepMesh works very well.
And as you have said, it doesn#t work with the Threads (Stack overflow with function MoveTO)

Roman Lygin's picture

I was playing with visualization to run concurrently last week-end and indeed can admit it cannot be used as is. TKOpenGl is fully based on assumption that the code runs sequentially. There are quite a lot of static variables used to store data between various calls of C functions.
Not sure if this should be a valid assumption (e.g. dictated by Open GL itself). Anyway, you cannot use AIS_* classes to run concurrently.

To gain speed up, I was trying to run triangulation concurrently to triangulate shapes in parallel before their display. This worked quite well and no data races have been detected (of course, all previous patches had to apply). The deficiency however came up unexpectedly. Regardless if your shape already has triangulation or not, when displaying it, internally the algorithm still calls BRepMesh_IncrementalMesh (in Prs3d_ShadedShape) which parses the shape and may try to re-triangulate the shape (what consumes time). An attempt to create an own mesher (e.g. subclass of _IncrementalMesh that would simply skip iterating) failed as the BRepMesh_DiscretFactory (which implements plugin architecture for meshers) tries to load such a dll on each call (instead of caching). This results in wasted time and overall performance downgrade, so this will have to be patched too.

But nonetheless, the _IncrementalMesh seems to be a safe thing to run concurrently.

Hope this helps.
--- - the Open CASCADE blog - CAD Exchanger, your 3D data translator