After upgrading to OCC6.5.3, we find the shape tessllation's time performace become very bad compared with OCC6.3. For a simple sphere, it costs about four times than OCC6.3. Loading same large IGES files, the tessllation time costs too much.
I know OCC team have tried best to make tessellation results better. But the time performance become really bad using the same tolerance parameters. Any idea or plan to solve this problem?
Thanks in advance. Any suggestion is welcome.
Let me offer my perspective.
The modifications to blame have been introduced in 6.4.x. Though some incremental improvements have been made in 6.5.x, both performance issues and excessive memory footprint still remain There were also quality regressions in 6.4.x and early 6.5.x but some of them have been fixed. I don't know for sure 6.5.3/.4 as I have stopped tracking the test models. In CAD Exchanger I ended up with forking 6.3.x version though would be happy to return to mainstream OCC as soon as the issues are away.
My speculation is that likely OCC folks have initially tried to address the issue of insufficiently accurate triangulation of complex NURBS (e.g. of high degrees) which in 6.3.x were approximated too coarsely. However instead of focused modifications for the NURBS (perhaps BRepMesh code base did not allow that?) they had to make generic modifications leading to greater amount of sampling points/triangles. Even elementary surfaces have been affected, e.g. spheres now contained larger amount of triangles. Thus, the benefit for a particular corner case had a broad downside in terms of performance and footprint penalty. Everyone has to pay a higher price now :-(. It would ertainly be interesting to get inputs from the development team on the background and plans (if any).
In general, it would be great to have a tailored triangulation algorithm(s) that would be more fine-tuned to geometrical configurations and much faster. Perhaps non-Delaunay triangulation would be just fine for visualization and many other purposes.
We kindly ask you to indicate the issues (if possible for sure) considering by you as remaining
in BRepMesh triangulation algorithm in OCCT ver.6.5.4 (comparing with 6.3.0).
It would allow us to speed up the process of BRepMesh algorithm quality improvement.
Thank you for the note. We are in touch with your development team on this.
As promised, I have made some analysis comparing 6.3.1 and 6.5.4 (using shipped pre-built binaries - i.e. release, win32, vc9 configuration).
Observations based on a handful of models (~5 simple + 3 medium complexity):
1). Visual quality is generally on par. One regression reported as http://tracker.dev.opencascade.org/view.php?id=23580. One shape that was wrong in 6.5.3 is now good in 6.5.4, it was good in 6.3.1.
2). Memory footprint (as measured by number of triangles) is 10%-80% higher vs 6.3.1, including max of 80% on a plain cylinder. Deflection is up to 2x higher. One one model, footprint and deflection were smaller than in 6.3.1.
3). 6.5.4 performance measured on all complex models only is worse, up to 3x+ vs 6.3.1. Reported as http://tracker.dev.opencascade.org/view.php?id=23581
Conclusion: the quality seems to be far better than in 6.4.x and perhaps earlier 6.5.x but still generally lags behind 6.3.1, especially the performance. It should be mentioned that it's important to compare performance in single thread mode. Even if 6.5.4 enables parallelism, it may not count in scenarios when parallelism is employed at higher level and when multiple BRepMeshes run concurrently.
You have to be logged in to download the attached file