Cogs displays data in format exported from PotreeConverter https://github.com/potree/PotreeConverter.
It is highly recommended to install the NPM package @kognifai/cogstools. This package contains all required tools and utilities.
PotreeConverter converts point cloud raw data in LAS or LAZ format into an hierarchical representation.
To preprocess data use:
The viewer for Point Clouds within Cogs tries to replicate what the potree viewer (https://potree.github.io/) does. So it should be possible to view our processed data with the potree viewer and compare with the cogs implementation.
Potree converter (potreeconverter2.exe) takes a raw set of points and converts it into an hierarchical form, i.e a tree-structure. The root node is a small subset of the input points that should be evenly distributed over the space of the point cloud. The child nodes brings additional points for part of the space and so on. So points on root node are spaced far away, adding points on the child nodes makes points spaced less far away.
Recommended options to PoTreeConverter:
Create an instance of Entity: Potree to display point-clouds. The PotreeComponent(#PotreeComponent_8h_source) [PotreeComponent] (@ref Cogs::Core::PotreeComponent) contains the display logic for point-clouds. A point-cloud can contain billions of points and the viewer uses level-of-details and frustum culling.
The runtime viewer chooses a subtree of the full tree in a such a way that points on-screen are roughly evenly spaced (that is the view-dependent part) and it has a memory budget that limits how deep in the tree is (which determines on-screen point spacing).
To limit memory usage the Point Cloud display uses budgeting, it is the point count that is used to limit number of points shown.
The pruning exclusively happens at runtime when choosing the subtree to use.
The overall spacing of points on screen is directly controlled by the memory budget. Especially running Cogs for WEB a web-client is subject to harsher resource limits than a desktop application is. The solution here is just to crank up the cogs memory budget, and the cogs viewer will happily just add more points.
The other hard part is choosing a good point size. Too large and the scan looks blobby, too small, and the scan get holes. When doing a laser scan, parts close to the scanner are more densely scanned that parts further away, surfaces slanted away from the laser are less densely scanned and so on. In short, the point spacing varies quite a deal. The right size is so that two adjacent points on a surface slightly overlaps.
If the PotreeComponent(#PotreeComponent_8h_source) [PotreeComponent] (@ref Cogs::Core::PotreeComponent) has mode PointDensityScaled, it will try to guess this when loading a chunk of points.
See List of COGS variables, PoTree section, for detailed information about all COGS variables available at runtime that are connected to Point Cloud.
Cogs does not load all data, the viewer use a memory budget + screenspace point spacing tolerance to determine how much it is allowed to load. Try to crank up the memory budget and reduce point spacing.
It might be that the Application quality + Potree settings are too conservative.
Load the point cloud in the cogs.core runtime and play around there without the restrictions of a web environment.
Adjust overall point size so that points are overlapping as little as possible, but enough to cover holes. There are four point shapes, Probably Sphere and Paraboloid should give best results (but costs a bit).
If points are too large in one area and too small in another area:
Make sure DistanceAndDensityScaled mode is on
Experiment with densityLevelScale, densityScale, and densityBias.
If colors are wrong or too dark or too light, it might be a sRGB issue.
PotreeComponent.pointScreenSpacing is the desired spacing between points on screen, i.e. the tolerance. This is DPI-scaled and scaled wrt grid density used when building the model. So 2-4 might be good values.
variable potree.chunks.maxCount specifies how the maximum number of chunks used throughout all active models, i.e. sets a limit on resource usage. It is a hard limit that will not be bypassed.
variable potree.spacing.globalScale is a scale factor for pointScreenSpacing. It will scale tolerances of all potree models, and is supposed to be an easy hook to adjust graphics load on different devices, e.g set it to a 1 < value on mobile devices, e.g 4.
It is better to adjust pointScreenSpacing and globalScale to get a decent load, it will be more stable. chunks.maxCount is as said a hard limit (and if you look at the log, you will see if this being backed off if you hit it).