Point cloud import - large coordinates issue

[Yan-Koch]

Issue when importing a georeferenced pointcloud generated by Agisoft. Point cloud provided by Inrap.

• e57: Large coordinates are not detected in the e57. When trying to truncate the coordinates manually, an error message appears. If imported with the original coordinates, the point cloud is cut into slices It is necessary to import the e57 in Cloud Compare first, then export it from CloudCompare. It solves the large coordinates detection by OST.

Original e57 file: https://drive.google.com/file/d/1j_RdTPKuiJtQ0aBJn4H_8R2mAaX-GBxG/view?usp=drive_link

• Ascii: Large coordinates are detected, but the import shows a point cloud cut into slices, either after truncating the coordinates or keeping the large coordinates. Other information: slices seem to have a 0,5m spacing.

Screenshot:

Original ASCII file: https://drive.google.com/file/d/1KlxHnqj7uFBJ1FT1R6Rr9B4aAiUagmST/view?usp=drive_link

Code for Ascii reading function: PTSfilereader.cpp Lines 160-161-162 (float?)

[jo-chemla]

These slices are indeed caused by floating point precision/sampling errors. CloudCompare, Potree, UE Lidar-Plugin, Cesiumjs w. 3dtiles & co all resolve it indeed by applying a matrix-transform that moves back vertex coordinates around an origin, usually using simply a global shift (+ scale in some cases), called global-shift for CC. This global shift or transform is applied to every point on load, for example on coordinates stored on higher-precision float64, - usually in batches of vertices via a simple matrix operation - and the transform applied to the entity/3d-object - so when doing the rendering, the camera matrix-transform-inverse composed with the 3d-pointcloud-entity matrix-transform results in a transform that is close to identity or around the scene origin.

CC stores this global-shift information per entity so it can be transferred back on save/export.

[Yan-Koch]

These slices are indeed caused by floating point precision/sampling errors. CloudCompare, Potree, UE Lidar-Plugin, Cesiumjs w. 3dtiles & co all resolve it indeed by applying a matrix-transform that moves back vertex coordinates around an origin, usually using simply a global shift (+ scale in some cases), called global-shift for CC. This global shift or transform is applied to every point on load, for example on coordinates stored on higher-precision float64, - usually in batches of vertices via a simple matrix operation - and the transform applied to the entity/3d-object - so when doing the rendering, the camera matrix-transform-inverse composed with the 3d-pointcloud-entity matrix-transform results in a transform that is close to identity or around the scene origin.

CC stores this global-shift information per entity so it can be transferred back on save/export.

Hi, Thank you for your comment. OST currently handles large coordinates and also proposes a global shift like CC does. The problem mainly concerns the last format added (*.pts), with probably a number type problem (floating / double). This is just something that we forgot to test. Regarding the e57, it only concerns the file created with AGIS. Other files that contain large coordinates are ok.