CloudCompare forum

Hi,

I have a crash when I compute distance between "particular" (?) cloud and mesh. Particular because the cloud has "only" 1000 points and the mesh is "small" (see attached files).

It seems that determineBestOctreeLevel() function of comparison dialog always return 20, which is used as default octree level and lead to very big allocations when calling computePointCloud2MeshDistance() function.

Putting a lower octree value in comparison dialog works perfectly.


Additionally, if I convert the attached sphere.obj in STL the importation is always running after 30 minutes (it seems that CC is again working on a 20 levels octree).

Hi Jean,

Indeed, the first bug is silly (I just forgot that the level should never be bigger than 9 or 10 for meshes - even with a level 21 octree!).

For the other one I'll look at this asap.

Daniel

Ok, it works! I think you have the same problem on STL load when unifying vertices (line 417 of STLFilter.cpp).

Indeed!

That's even worse: this should be a parameter set by the user himself (as it directly controls the relative accuracy of the coordinate values). But I doubt many users would know how to set it properly...

daniel wrote: ↑Wed Dec 24, 2014 10:38 am Indeed, the first bug is silly (I just forgot that the level should never be bigger than 9 or 10 for meshes - even with a level 21 octree!).
Daniel

Hi Daniel, I want to compare two 3D models of a 40 million facets mesh. I've used the "Compute Cloud/Mesh distance" tool on the latest beta version 2024 01 27. At first, I used AUTO parameter for the Octree Level, which was evaluated at 8 in the console logs. Later I wanted to refine it as much as possible, but as soon as I exceeded 10, CloudCompare crashed. I couldn't find any log file that would give me a clue, so I searched the forum. I found your sentence in this thread, which is probably the explanation. To understand the problem, I'd like to know why you can't exceed 10 in Octree Level? It starts calculating, I see the memory growing up but not reaching the maximum of my 64 GB and it crashes. Is it a problem of limitation in the algorithm that the developers wanted ? A mathematical impossibility ?
by the way, congratulations for your extraordinary software.

Hum, with a mesh that may be challenging in terms of memory (due to the acceleration structure with use). But it shouldn't crash... I'll try to investigate this.

I found the issue. This happens when the internal grid used to speed up the process would have more than 2 billion cells. I fixed the code, but you'll likely hit an error due to the lack of memory (but that's always better than crashing). This will be available in the soon to be release official 2.13.0 version.

Waiting for the release (next week), I've uploaded a new version of the 2.13.beta online.