Without an available network, login may not complete, some advanced functions such as 3DGS may not work normally, and logs cannot be uploaded for technical support.
When a processing task fails or stops, preserve the original data, project, task status, software and algorithm versions, workstation details, and error message before changing parameters or retrying. SHARE PointClouds Studio V2.6 provides task status, retry, exception-feedback, and log-upload steps that support diagnosis and escalation. These steps improve traceability, but they do not guarantee recovery of every failed task.
Figure 1: Workflow after a task failure: preserve evidence, confirm status, categorize the issue, check the environment, retry under controlled conditions, and escalate to support.
Identify the Trigger, Symptom, and First Action
Common triggers include low-feature areas, large data volumes, insufficient computing resources, incompatible drivers, incomplete input data, network or sign-in problems, and unsuitable processing parameters. Symptoms may include a failed or canceled task, an interrupted task, missing outputs, or a repeatable error message.
The first action is to preserve the evidence and identify the smallest controlled check—not to change multiple conditions at once. The workflow below organizes a recorded symptom, diagnosis, controlled retry, and support escalation into traceable steps without implying that every failure can be recovered.
Use a Six-Step Troubleshooting Loop Before Retrying
1. Preserve the Evidence
Keep the original data, project directory, generated deliverables, device model, software and algorithm versions, workstation configuration, task time, and error message. Do not overwrite or delete the evidence from the first failure.
2. Confirm the Status in Task Management
Distinguish among queued, running, successful, failed, and canceled states. Failed and canceled tasks require different handling. First confirm whether resources are still occupied and whether the task has actually ended, then decide whether to retry it.
3. Review the Exception Feedback and Categorize the Issue
Initially categorize the issue as input data, storage capacity, graphics processing unit (GPU)/video memory (VRAM), driver, network/sign-in, parameters, scene scale, photo conditions, or an unknown algorithm exception. The purpose of categorization is not to assign blame immediately, but to select a validation step involving the smallest possible change.
4. Start with Low-Risk Checks
Check the recommended Windows 11 64-bit environment, an RTX 3060 or better, at least 8 GB of dedicated VRAM for point cloud mapping, at least 12 GB for 3D Gaussian splatting (3DGS), 64 GB of RAM, 100 GB of free space, and the NVIDIA driver version required when CUDA, NVIDIA’s parallel computing platform, is used for colorization. Check the project path, disk permissions, network sign-in, and data integrity.
5. Retry Under Controlled Conditions Instead of Changing Many Variables at Once
Failed or canceled tasks can be retried. Change only one explainable condition at a time—for example, free disk space, install a driver that meets the requirements, reduce the number of concurrent tasks, validate with sample data, or validate a representative copy or crop of already-captured data for diagnosis, without presenting post-processing as a way to split or recreate field capture tasks—and record the results before and after the change.
Figure 2: Task Management shows a failed reconstruction task and its available actions in History Tasks.
6. Escalate to Support with Complete Materials
Use the official channel to submit the device model, software and algorithm versions, computer configuration, task status, error message, steps already attempted, and sanitized logs. Upload Log requires sign-in and a network connection. Before sharing screenshots or logs, remove customer names, addresses, serial numbers, account details, and confidential paths.
Figure 3: The Log Upload dialog contains contact and problem-description fields.
Observable Outcomes
| Trigger or recorded condition | Action in the SHARE PointClouds Studio V2.6 support loop | Observable result |
|---|---|---|
A task has a Failed or Canceled status and the cause is not yet identified |
Review task status and exception feedback | Categorizes the issue before a controlled retry |
| A retry would replace or obscure the first failure evidence | Preserve the project, original data, task record, and generated outputs | Keeps materials available for before-and-after comparison |
| Several operators need to test corrective actions | Change and record one variable per retry | Identifies which recorded change corresponds to the next task result |
| Technical support cannot reproduce the reported symptom | Provide versions, configuration, logs, reproduction steps, and a sanitized sample | Supplies a defined diagnostic package for assessment |
| A large project fails during one processing stage | Test representative data, use a diagnostic copy with 2D/3D cropping to isolate a representative already-captured area, retain the complete source data, and do not treat cropping as field-task segmentation or recapture | Focuses the next retry while preserving the complete source data |
Priorities for Different Types of Failure
- Point cloud mapping: Check original-data integrity, workstation resources, paths, and task status;
- Point cloud colorization: Check the photos, CUDA driver, and VRAM;
- 3DGS: Confirm that the photos are undistorted and that at least 12 GB of dedicated VRAM is available. For large scenes, first evaluate representative data; 3DGS is intended only for photorealistic viewing;
- Upload Log: Check sign-in and network connectivity, and sanitize the material before uploading it;
- Coordinates/post-processed kinematic (PPK): Check the POS trajectory file generated by an external PPK tool, coordinate order, units, and control points/independent check points. Do not classify a positioning problem as a simple algorithm failure;
- SHARE SLAM S100 data from complex indoor spaces: Start with a representative sample, design a closed-loop capture route, and review level relationships, colorization, areas near floor slabs, and trajectory anomalies.
How to Measure the Outcome
Record the time from the first failure to a clear categorization, the number of ineffective reruns, the variable changed for each retry, the number of support exchanges, the time from submission to reproducibility, and whether a return site visit was avoided.
Use troubleshooting time, ineffective reruns, support exchanges, reproducibility, and evidence completeness to evaluate the loop across representative cases.
Frequently Asked Questions
Q1: What should I do first when a processing task fails? Preserve the source data, project, task status, complete software version, settings, and error evidence. Then classify the issue and change one recorded variable per controlled retry.
Q2: Why should I not change several parameters at once? Changing several things simultaneously removes the ability to determine cause and effect. Even if the task succeeds, you will not know which action worked, making the result difficult to reuse next time.
Q3: Does a 3DGS failure affect point cloud measurement? They are different deliverables. 3DGS is used for realistic visual browsing; measurement and computer-aided design (CAD) work should be based on a point cloud that has passed quality checks.
Q4: Can logs be posted directly in a public group? This is not recommended. First remove sensitive information such as customer and personnel details, serial numbers, accounts, and paths, then submit the material through an official support channel.
