I am encountering two distinct blockades when attempting to import terrestrial laser scan (TLS) data into RealityScan 2.1.1.
Issue 1: Native .ZFS Import Failure
When attempting a direct import of native .zfs scan files captured with a Z+F IMAGER 5024 and processed via LaserControl 12.0, RealityScan throws a generic import error and fails to load the dataset. The import settings and error message are shown in the screenshots below. This exact native .zfs workflow previously functioned without issue when utilizing data from a Z+F IMAGER 5016 processed through LaserControl 9.0.
Issue 2: Incomplete/Sparse .E57 Import
As a workaround, I exported the project from LaserControl 12.0 as an .e57 file.
-
RealityScan imports the
.e57file without throwing an error, but the resulting point cloud is extremely sparse. Multiple scanner positions appear to be entirely missing or unparsed. Even when exporting the individual scans as separated.e57file, these files appear to be too sparse. The ‘Max points to display’ in the rendering settings was increased to the maximum. -
The exact same
.e57file opens flawlessly in CloudCompare, showing all scanner setups, full density, and correct spatial alignment.
Questions for the community/dev team:
-
Is there a known compatibility gap between RealityScan 2.1.1 and the newer Z+F 5024
.zfsformat? -
What are the recommended
.e57export settings in LaserControl 12.0 (e.g., Ordered vs. Unordered, specific spatial subsampling toggles) to ensure RealityScan recognizes all scan stations instead of dropping positions?
Any insights would be appreciated.
