A Guide to Working with SLAM and LiDAR Data in RealityScan 2.1

What will you learn in this guide?

We’ll cover the order for processing images, trajectories, and point cloud data from SLAM scanners in RealityScan 2.1; how to use classified LiDAR data; and how to export the resulting camera registrations. We’ll also summarize how the COLMAP changes in version 2.1.1 affect data exchange with other software.

These steps can be useful for teams preparing field data for architectural documentation, digital records of existing buildings, and visualization. However, the source documentation does not specify the hardware required for a particular project, processing times, or suitable point density. These should be evaluated separately based on the project data and the system being used.

Requirements and version differences

Support for importing data from SLAM scanners was introduced in the RealityScan 2.1 update. According to the documentation, you can import images and their trajectories from scanners such as XGrids, then add the point cloud. If an existing COLMAP scene is provided with the XGrids data, you can also start with that scene as part of the image-and-trajectory workflow.

On the LiDAR side, importing ASPRS classes alongside LAS and LAZ point clouds is supported. Other notable additions in 2.1 include OpenCV export, XMP export for both original distorted and undistorted images, and COLMAP export with improved compatibility for image data.

RealityScan 2.1.1 lets you choose between a flat folder structure and the standard COLMAP directory structure for exports. Exported data can be saved in binary or ASCII format, and low-accuracy points are filtered during export. Support for the FULL_OPENCV camera model has also been added to import. In addition, command names were updated in 2.1.1: use loadColmap instead of importColmap, and loadBundler instead of importBundler.

The source documentation does not specify account or licensing requirements. Before starting a project, verify your organization’s setup and access requirements.

Step by step: Preparing SLAM and LiDAR data

1. Import the images and trajectory data. In a SLAM workflow, first import the images and their trajectories into the project. If you have a COLMAP scene supplied with XGrids data, consider using that as a starting option as well. According to the documentation, the flight log feature has been renamed “Trajectory.” During import, you can define a custom format, select the Euler angle order, and choose the mounting orientation for Yaw, Pitch, and Roll.

2. Add the point cloud and create cameras. After the image and trajectory data, import the SLAM point cloud. Virtual cameras can be generated using camera pose priors or a component from a COLMAP scene. Combining this data with photogrammetry or other LiDAR data is also supported. The source documentation does not guarantee the accuracy of results for every project, so check alignment and the position of the data in the scene.

3. Check the LAS or LAZ classes. ASPRS classes included with the point cloud can be imported into the project. Class visibility can be controlled from the SCENE 3D/VIEW tab, and the class legend is shown in 1Ds View. When generating a mesh, classes can be selected in the Model settings. This lets you focus on specific classes and create a selective mesh instead of using the entire point cloud.

4. Export camera registrations. Version 2.1 supports OpenCV export and XMP registrations. XMP export provides options for original distorted or undistorted images. If the project will be transferred to other software, decide early in the workflow which coordinate system and image type to use, since these choices can affect subsequent matching steps.

5. Configure COLMAP exchange for the target application. In 2.1.1, you can choose either a flat folder structure or the standard COLMAP directory structure for export. Mask export also includes AI-generated masks; for the standard directory structure, you can specify whether to use the .mask.ext suffix. Since you can choose between binary and ASCII formats, check the structure expected by the target software. Support for the FULL_OPENCV camera model on import also provides broader compatibility with calibration data.

Command-line and server workflows

The Linux version of RealityScan offers a command-line build for automated processing. It runs in a packaged Wine environment and supports alignment, reconstruction, texturing, and export workflows. The official documentation notes that the desktop interface may encounter graphics and focus issues on Linux; CLI is the recommended option. A REST or gRPC API plugin is also available for transferring jobs to remote machines.

Choose command names according to the version you’re using. For example, in 2.1.1, the updated names for COLMAP and Bundler projects are loadColmap and loadBundler. The documentation lists a file path as the required input for the COLMAP command, with an optional XML file containing scene transformation settings. These settings can be used to change the coordinate system or apply a custom transformation.

If you’re planning batch processing with commands, first verify the import and export results with a small sample project. The RealityScan command-line documentation includes separate command groups for tasks such as loading projects, adding images, aligning, and exporting; each command has its own required and optional inputs. Using an old command name in a script without checking it against the current version can cause the automation workflow to stop unexpectedly.

Impact on architectural and visualization workflows

Teams using field scans as references for interior or building modeling can combine SLAM images, trajectories, and point clouds in the same project. Using ASPRS classes for visibility control and selective mesh generation helps separate scene data according to its intended use. XMP, OpenCV, and COLMAP exports also provide options for transferring data between different applications in a measurement and visualization pipeline.

However, the coordinate system and the export format expected by the target software need to be defined in advance. Teams planning to automate processes on a Linux server can explore the CLI and REST/gRPC options; the recommendation is to use CLI rather than the interface on Linux. The sources do not specify hardware requirements, pricing, or licensing terms, so purchasing or workstation plans cannot be finalized based on the features in this guide alone.

Common mistakes

• Adding data in the wrong order: In the SLAM workflow, import images and trajectories first, then the point cloud.

• Checking classes only in the image: Class visibility is managed in SCENE 3D/VIEW, the legend in 1Ds View, and selective mesh settings in the Model settings.

• Not choosing COLMAP export options for the target software: Before transferring data, consider the folder structure and binary or ASCII format options in 2.1.1.

• Using old command names in the new version: In 2.1.1, importColmap and importBundler were replaced with loadColmap and loadBundler.

• Assuming the Linux desktop interface is the default method: The official documentation recommends CLI for Linux because of graphics and focus issues.

Next steps

Start by verifying the image-trajectory-point cloud sequence and class visibility in a small scene. Then export the same data using the COLMAP or XMP options that best suit your target workflow. If you need automation, compare the command names you use with the documentation for your RealityScan version; for server-side workflows, consider the Linux CLI and REST/gRPC options.

Sources and licensing

This guide has been adapted into English from official documentation published by Epic Games for RealityScan 2.1, command-line commands, and RealityScan 2.1.1. The sources are openly licensed.