vtalyh / v-hacd Goto Github PK

Add parameter to control the max # of vertices for convex-hulls

Add a merge stage to combine convex-hulls if the volume of their convex-hull is 
equal to sum of their volumes

As discussed via email, it would be great to have some kind of a context 
variable that allows mainly for two things:

 * Be able to cancel the execution of long running V-HACD functions. There has to be a reasonable tradeoff between response time and performance. Execution does not need to interrupt immediately but with an approximate grace period of, say between 10 and 30 seconds. I need to set this from an outside thread (in a callback?) and the function will stop at the next given opportunity. Preferably including cleanup of temp data.

 * The same mechanism should be able to give me an approximation of progress. Ideally in percent of total time. Again, this doesn't need to be precise. Just a rough indication for the user to know how long this will take.

I suggest a context object interface that is implemented by the user and can be 
passed in. It could look like this:

namespace VHACD {

struct IControlFlow {

    // called by vhacd to tell the total progress.
    // (optional, could resort to always 100 percent)
    // it would be ideal if this would be called only
    // once and not change afterwards but I guess that 
    // would be hard to achieve
    void set_total_progress(std::size_t p) throw () = 0;

    // called by vhacd to indicate how much progress
    // has been made. Must be between 0 and set_total_progress()
    void set_progress(std::size_t p) throw () = 0;

    // called by vhacd regularily
    // if it returns false, the algo is aked to stop at
    // the next given occasion 
    bool continue() throw () = 0;
}

}

The user will implement this object and pass it to ApproximateDecomposition().

Would be awesome.

Thanks,
Stephan

The user callback that displays progress is not called often enough to prevent 
a GUI application from going into "not responding" mode.  The total percentage 
complete goes to 15% very quickly, then stalls for a couple of minutes and 
jumps to 90%, then finishes quickly.  In order to be useful, that callback 
should really get called a lot more often, so the user doesn't think there is 
something wrong with the program.

Implement queue data structure to avoid relying on STL

For those of us who don't have OpenCL installed could you make the inclusion of 
FindOpenCL optional.

In src/VHACD_Lib/CMakeLists.txt and src/test/CMakeLists.txt
change "include (FindOpenCL)" to "include (FindOpenCL OPTIONAL)".