<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 6, 2020, at 9:01 AM, Martin Dobias <<a href="mailto:wonder.sk@gmail.com" class="">wonder.sk@gmail.com</a>> wrote:</div></blockquote><br class=""><blockquote type="cite" class=""><div class=""><div class="">While the existing tools such as CloudCompare or<br class="">Potree are great to visualize point clouds, we are IMHO still missing<br class="">integration with a proper GIS, which would open many new possibilities<br class="">and make point cloud data more accessible to ordinary GIS users.<br class=""></div></div></blockquote><div><br class=""></div><div>Point cloud visualization in QGIS would be an excellent addition, but as you discuss, it would be a heavy lift.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">So far it looks like it would be a good idea to use the PDAL library<br class="">for I/O - it supports a variety of formats through a common<br class="">abstraction which would make our life much easier. </div></div></blockquote><div><br class=""></div><div>I agree. You could also give users the ability to load PDAL Pipelines (search for the PipelineExecutor C++ class) that would enable them to directly load and process PDAL data much like a GDAL VRT. Another point that QGIS should worry about is streamable or bulk data processing with PDAL. Both are supported.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">The next thing is<br class="">how to deal with rendering. From what I understand, CloudCompare reads<br class="">the whole point cloud file into memory and builds an in-memory octree<br class="">which is then used for data access. Potree needs the data to be<br class="">pre-processed beforehand with PotreeConverter tool into an octree, its<br class="">nodes are then stored in files and requested as needed. Entwine does<br class="">similar indexing, with a different file format. So it seems that it<br class="">would be nice to cover both cases:<br class=""></div></div></blockquote><div><br class=""></div><div>Everyone that renders data pre-processes it into something more suitable for visualization. Entwine supports keeping all attributes, to full depth, with the option of preserving original data ordering. The encoding of the data can be LAZ or Zstd-compressed blobs, but other encodings could be trivially added. Entwine also supports "addons" <a href="https://pdal.io/stages/writers.ept_addon.html" class="">https://pdal.io/stages/writers.ept_addon.html</a> that can be used to enrich per-point attributes without disrupting the existing tree. This is needed for situations where the original data is remote (say <a href="http://usgs.entwine.io" class="">usgs.entwine.io</a> for USGS 3DEP holdings), but you want to locally process/classify/enhance data.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">It will probably be a long run to make the point cloud visualization<br class="">look good - splatting, dynamic point sizing, eye-dome lighting and<br class="">possibly more features already supported by Potree / CloudCompare.<br class=""></div></div></blockquote><div><br class=""></div><div>It has been my observation that point cloud rendering features radiate most quickly out of Potree into the other softwares. This includes implementations of EDL, dynamic sizing and fill approaches, and the frustum culling approach.</div><br class=""><blockquote type="cite" class=""><br class="">I don't want to make this mail too long - at some point I will try to<br class="">prepare a QGIS Enhancement Proposal (QEP) with more details. I would<br class="">be very grateful for any comments and suggestions, where do you see<br class="">possible issues, where else to look for some inspiration etc.<br class=""><br class=""></blockquote><br class=""></div><div>I'm excited to see movement toward PDAL's usage in QGIS. As you embark on the process of its development, don't hesitate to ask questions and for things you might need. PDAL was not developed with support for a dynamic live GUI as a primary use case, and you are likely to run into a few friction points (Progress reporting is one thing I immediately know about. Threading situations would be another). We'll see what we can do. </div><div><br class=""></div><div>Howard</div><br class=""></body></html>