Tue, 11/06/2012 - 09:04
Forums:
Hi all,
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.
Ding
Wed, 11/07/2012 - 16:04
Ding,
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.
Thanks,
Roman
Wed, 11/07/2012 - 18:47
Dear Roman,
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.
Regards
Thu, 11/08/2012 - 02:03
Forum supervisor,
Thank you for the note. We are in touch with your development team on this.
Regards,
Roman
Sun, 11/25/2012 - 23:33
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.
HTH.
Roman
Tue, 01/14/2014 - 17:59
Dear all,
I'm aware this is an old thread, but I need to know if this issue has been addressed in latest OCC releases.
Issue #23581 appears to be still "open", could you confirm this ?
Thank you
Thomas
Tue, 01/14/2014 - 18:41
Dear Ding,
In general, BRepMesh has been improved in recent releases, and probably performance has been improved too. This is to be confirmed by testing. We suggest you to compare performance of the version you are using with that of OCCT 6.7.0 on your platform and report results here (and / or in #23581).
Best regards
Wed, 01/15/2014 - 10:02
Hi Supervisor,
Thank you so much for your great job. I will test it later.
Ding
Fri, 03/07/2014 - 13:43
Hi! I'm using OCCT 6.7.0 in Ubuntu 12.10. I wrote a code to fit a NURBS surface to the Stanford Bunny (ftp://graphics.stanford.edu/pub/3Dscanrep/bunny.tar.gz). The point cloud is downsampled and "GeomAPI_PointsToBSplineSurface" reports that the approximation is performed without errors by checking IsDone(), but "BRepBuilderAPI_MakeFace" can not triangulate the constructed NURBS surface and it takes too much time. Is this problem still unsolved?