PotreeConverter
PotreeConverter copied to clipboard
Failure Cases
During conversion, the point cloud is subdivided into small chunks that can be indexed from the bottom up. However, if the data set has unfavourable point distributions, the converter might fail.
E.g., the chunker subdivides the point cloud into chunks with size boundingBox / 128 or boundingBox / 512. During indexing, each chunk is further divided into chunks with size 1 / 32. If, during indexing, all points of a chunk are located within a subchunk, then the converter throws an error and aborts. Preliminary fix added with commit: https://github.com/potree/PotreeConverter/commit/98f535281148201f0ad11b3f3dd5e2540354b6b8 The fix does not abort anymore unless the subchunk contains 50% duplicates. This is done because further subdividing duplicates would loop forever.
Another issue is ( or was, also preliminary fixed with https://github.com/potree/PotreeConverter/commit/98f535281148201f0ad11b3f3dd5e2540354b6b8) that if a high level chunk contained few points and ended up only promoting 1 point to the upper levels, then inner nodes would end up with 0 points. Currently, the converter discarded any node with 0 points but this also removed the connection to descendants with more than 0 points. After the fix, nodes are only removed from the octree if they have 0 points and are leaf nodes. Empty inner nodes are no longer removed.
Any suggestions how to overcome this? I believe I have a pointcloud with very non-desirable distribution and the Converter keeps aborting. I tried PotreeConverter 1.7 but indexing stalls exponentially, hence taking forever. Would downsampling work? It does not affect the distribution, but I have very dense scans. Or if you know of a script/tool to order the points in a better fashion for PotreeConverter, I'll appreciate it.
Generally I'd like to make the Converter more robust towards all kinds of input data sets. If you have a point cloud that doesn't work, please send it to me at [email protected], and I'll see what I can do to make it work. I've also got someone else currently having issues with a point cloud of a road network which we are working on fixing.
Thanks for the quick reply. I just need to verify that sharing the data of this historical site is allowed. If so, I'll gladly share it.
On the other hand, after trying several things (different file formats, point cloud merging methods, point order, etc), what worked in my case was to input each scan as a list: ./PotreeConverter --source [list of individual scans] -o [output_dir]
, of course each scan was properly registered beforehand based on a reference. Which was actually the simplest/easiest solution.
To me (the user) the rendering and visualization is fine, perhaps would be interesting to compare the performance against the potree output when the complete pointcloud is converted from a single file, as I was trying in the beginning. Cheers!
I have long roads and rails that fail in indexing. I cannot determine what is making them fail. Sometimes it processes a huge file (17GB) - big to me :). Then other times it fails on much smaller files. I thought just cutting them in half and trying again would work but I am running into issues with even very small files. Typically have a directory with about 100 tiles and I just choose the directory potreeconverter.exe "d:/mydirwithlasfiles"
. Is there something else I could try to make this work?
I also had this problem and fixed it. I think the distribution is the key. I was working on point cloud of a road network. My input was 100~ las files, which was named as 0001, 0002... and such. Each file is recorded in order, so 0001 and 0002 is right beside each other while something like 0099 is more likely to be located far from 0001.
For some reason, Potree was reading file in random order, something like 0060, 0002, 0040, 0080, .... and this caused some tile go missing. I couldn't find reason for why it reads files in this weird manner, but I think it was OS or mount problem. But I overcame somehow. After I fixed the potree converter code to sort the las files in alphanumerical order, every tile was there as expected.
I think dynamic programing nature of Potree converter may lead this problem. Perhaps sorting the las file spatially before reading all could solve the problem, so that all the points are grouped together spatially before reading the LAS files. That is my wild guess.