I am trying to run facet extraction on a small set (2M points). Doing Fast marching at 4 (grid step = 0.192784) and M dist 0.2, min point 20 and max edge 0.05. I am getting horrible performance (2 hours@93%) with CPU usage at around 3% and GPU 0%. Is there som multithread issue? And are there no GPU capabilities?
CC 2.11.3
AMD Ryzen Threadripper 3960X
128 GB ram
NVIDIA Geforce RTX 2070 SUPER
qFacet performance
-
WargodHernandez
- Posts: 187
- Joined: Tue Mar 05, 2019 3:59 pm
Re: qFacet performance
I spent some time investigating this today, first off there is no GPU usage in this plugin, also there doesn't appear to be any multi threading when using fast marching (didn't look into KD tree method).
My testing used a cloud with ~350k pts
I added timers and console statements to see if I could track down some guidance to the settings as far as speed goes.
It turns out the largest time deltas are due to the error measure type used following tables were made with Octree Level 8, max error per facet: 0.2, without retro projection error option:
Errortype: RMS | Time: 63.922s
Errortype: MAX_DIST_68_PERCENT| Time: 1052s (All of the percentage based errors have similar time, they share the same code path)
ErrorType: MAX_DIST | Time: 28.857s
I also tried adjusting all other setting to see their impacts, the lower the octree level the faster the calculations, but there isn't a dramatic bump change anywhere like the error type.
The use retro projection error option only changed the total times by a couple tenths of a second at (octree level 4) to 3 seconds at (octree level 8)
Looking into the error calculations the percentage based versions have to create an array with distances to the local planes for each point and to sort each array afterwards. that is likely pretty hard on local cache and processing requirements in general compared to just finding a max value or calculating an RMS.
My testing used a cloud with ~350k pts
I added timers and console statements to see if I could track down some guidance to the settings as far as speed goes.
It turns out the largest time deltas are due to the error measure type used following tables were made with Octree Level 8, max error per facet: 0.2, without retro projection error option:
Errortype: RMS | Time: 63.922s
Errortype: MAX_DIST_68_PERCENT| Time: 1052s (All of the percentage based errors have similar time, they share the same code path)
ErrorType: MAX_DIST | Time: 28.857s
I also tried adjusting all other setting to see their impacts, the lower the octree level the faster the calculations, but there isn't a dramatic bump change anywhere like the error type.
The use retro projection error option only changed the total times by a couple tenths of a second at (octree level 4) to 3 seconds at (octree level 8)
Looking into the error calculations the percentage based versions have to create an array with distances to the local planes for each point and to sort each array afterwards. that is likely pretty hard on local cache and processing requirements in general compared to just finding a max value or calculating an RMS.
Re: qFacet performance
Well, a low octree level can be very bad with a very dense/big point cloud. As the number of points in each cell will be huge. So you generally have to find a reasonable spot, with a not too small cell (otherwise there are too many 'fusion steps'), and not too big (otherwise there are too much points in each cell, and the facets won't meet the input flatness criteria, etc.)
Daniel, CloudCompare admin