Progress Bar Support / Handle please

[ZoomDomain]

Please implement a readout for one of the main loops in the CGAL process, so that a program using it can find "number of vertices processed" "number of triangles processed " " number of primitives processed " IT WOULD BE SO COOL!

Sometimes CGAL takes 3 hours on my pc, until that time it just locks up without any signs of life. For such a long process it would be very wonderful to have a single Debug.Log line in the main loop which updates a string with VTX info's, and anything at all that could be used to guess on the status of the CGAL processing.

Thankyou.

[sloriot]

What package/class are you refering about?

[ZoomDomain]

Bonjour, It's with regards to the opensSCAD implementation of CGAL. Some programmers have tried to implement and fix the progress indicator display, i am told the openscad developers " Don't recompile CGAL on all platforms for release, There seems to be no existing hook so [...printing total vertex numbers from a loop iteration] could be done by just a user of CGAL.

Some programs have "projected file size, time to completion, vertices processed" and similar tools that a programmer can use in a status window, and it seems that the programmers are hampered in that sense.

Here is a page with some information, relating to CGAL's Nef3_nary_union :

openscad/openscad#810

the openscad status window has not been fixed for 2+ years for lack of a solution.

Antony

[sloriot]

If you're talking about the n_ary intersection or union, I can add a generic visitor to the get_union() or get_intersection() function so that you can track when a union/intersection is done and get access to the intermediate Nef. Would that solve your problem?

cc @kintel

[sloriot]

See sloriot/cgal@b8a1980
PS: not tested yet

[ZoomDomain]

Thanks so much, i am vague on the subject so i will have to ask kintel to confirm that he can access it while cgal is running some of the longer functions, if you say so it must be. It sounds like a brilliant solution and it would be very helpful. Perhaps if you can write the number of vertices from the current union/next processed component, we could add it up, that would be cool however not essential. Anything that could be accessed every minute in the processing stage. thanks

[kintel]

@sloriot While the n_ary union is the worst offender, it's a small and trivial function to reimplement with visitation support. The major challenge is that the Nef_polyhedron_3 CSG operators themselves are blocking, sometimes for many hours, leaving us in the dark with no progress info or way to cancel the operation. We've tried to work around some of this by running CGAL in its own thread. We'd still need to unsafely kill that thread if we want to cancel though, and it still won't give us any progress info.

[afabri]

I guess it would be interesting to get a standalone cpp file
and some data files that run forever. This should not happen
unless you have giant meshes you work on. Then we could
have a closer look at what is going wrong.

Best,

Andreas

On 15/09/2015 16:31, Marius Kintel wrote:

@sloriot https://github.com/sloriot While the n_ary union is the worst
offender, it's a small and trivial function to reimplement with
visitation support. The major challenge is that the Nef_polyhedron_3 CSG
operators themselves are blocking, sometimes for many hours, leaving us
in the dark with no progress info or way to cancel the operation. We've
tried to work around some of this by running CGAL in its own thread.
We'd still need to unsafely kill that thread if we want to cancel
though, and it still won't give us any progress info.

—
Reply to this email directly or view it on GitHub
#341 (comment).

Andreas Fabri, PhD
Chief Officer, GeometryFactory
Editor, The CGAL Project

phone: +33.492.954.912 skype: andreas.fabri

[kintel]

I don't think it's a bug. We have sizeable meshes, using the EPEC kernel, and processing time is significant. The larger the meshes, the more processing. We regularly talk to users with ~24h processing time to evaluate the final mesh.

[kintel]

PS: minkowski is another blocking operation which tends to take a lot of time. We've partially worked around this by rewriting minkowski to perform a convex decomposition plus a union of hulls, which gives a significant speedup, but we still get hit by the final union if any of the operands are concave:
https://github.com/openscad/openscad/blob/master/src/cgalutils-applyops.cc#L209

[ZoomDomain]

Hi Afabri, I'm not certain how CGAL runs within CSG adding tasks, to make a geometrical 3d sunflowers would take 600 spheres of i.e. 30 vertices each, and 200 petals made from tetrahedra and some other elements, it would probably take about two hours for the program. If CGAL was yielding for a moment every few thousand calculations and updating a static variable stating the triangles/vertices/ etc written thus far it would be well cool. :) I will read up on the docs to see if i can understand the references are very good incidentally.

[ZoomDomain]

So every time a leaf or a node in the CSG tree is processed, is it in theory possible with the current edition of CGAL to send a kind of clock independent message to the host platform of CGAL? Si'il vous plait je serais d'une tres grande reconnaissance de savoir si et comment coder un tel compteur dans le CGAL.

[sgiraudot]

This issue is similar to #102.

There is a work in progress to implement a CGAL progress tracker, see #1036.

[sgiraudot]

(I'm closing the issue as it can be considered a duplicate. Please refer to #102.)