Skip to content

Start with the symptom, not an assumed cause

Diagnose ASCAND capture, processing, scan, merge, mesh and export problems by observable symptom and workflow stage.

Start with a repeatable baseline
Browse the complete Tutorials

Start with the symptom, not an assumed cause

ASCAND troubleshooting begins with what you can observe. Record the exact symptom, identify the earliest workflow stage where it appears, and test that stage before changing later parts of the process.

This matters because similar-looking results can have different causes. Missing geometry may originate in object visibility, source framing, method limitations, calibration, registration or later mesh processing. A file that appears at the wrong scale may reflect export units or destination-tool interpretation rather than reconstruction. A completed process confirms that a workflow reached a result state; it does not prove that the source, geometry or output is suitable.

Choose the first matching route:

Troubleshooting narrows plausible causes. A familiar symptom is not proof of a diagnosis, and one successful corrective test does not certify accuracy, completeness or fitness for purpose.

Before following a route, ask whether the symptom exists in the source, first reconstructed result, processed model, exported file or destination application. Move backward until the symptom is no longer present. The transition between the last unaffected stage and the first affected stage defines the most useful diagnostic boundary. This does not prove which component caused the change, but it prevents later symptoms from being mistaken for upstream evidence.

Preserve the failing case before changing it

Keep the original source and result before retrying, converting, repairing or overwriting anything. A useful baseline includes:

  • the ASCAND product and applicable configuration;
  • the recording device and capture arrangement;
  • the selected Vision, Laser, Combo or Multi-Scan workflow;
  • the original source-file identity;
  • the project, job or result identity available in the current platform;
  • the first stage where the symptom is visible;
  • a precise description of the affected region or behavior; and
  • every change already tested.

Make a copy for experiments. Change one relevant variable, repeat the same observation and compare the new result with the preserved baseline. If lighting, framing, object position, method and processing choice all change together, the comparison cannot show which change mattered.

Screenshots can record a viewer state, but preserve the underlying source and result where appropriate. Crop screenshots to the relevant interface or geometry and avoid including unrelated account, personal or third-party information.

Use the controlled-comparison method.

Setup, framing, lighting or source-video symptoms

Start at acquisition when the problem is already visible in the source. Typical observations include:

  • the object, turntable edge or coded reference leaves the frame;
  • the object shifts, tips, flexes or slides during rotation;
  • the camera moves, refocuses or changes its view;
  • the object becomes soft, blurred or strongly overexposed;
  • lighting or background appearance changes during the recording;
  • hands, supports or unrelated objects obscure required evidence;
  • the intended rotation is interrupted; or
  • the surface and background do not separate reliably.

Review the complete recording, not one representative frame. Check the beginning, intermediate positions and end. A plausible still image cannot demonstrate stable framing, complete rotation or uninterrupted reference visibility.

If the source fails, correct the capture before resubmitting it. Reprocessing cannot restore cropped views, reverse motion blur or recover evidence never recorded. Use Capture Setup Problems for staged checks and Record a Scan Video for the ordered recording procedure.

Upload, submission or processing-state symptoms

Treat the platform handoff as separate gates:

  1. The intended local source exists and can be identified.
  2. Transfer completes under the current platform instructions.
  3. The platform accepts the submission.
  4. The correct project and workflow are selected.
  5. Managed processing reaches a reported state.
  6. The expected result becomes available for review.

Record the last gate that completed and the first gate that did not. Do not describe “upload failed” when transfer completed but the file was rejected later, and do not describe “processing failed” when the wrong source or workflow was submitted.

Current controls, file limits, access rules, job labels, timing and service availability are operational facts. Check Platform Documentation rather than relying on an old screenshot or remembered interface. If the current documentation does not explain the observed state, preserve the available message and identifiers and contact support. Do not repeatedly submit the same source unless current instructions recommend it; duplicate jobs can make the evidence harder to follow.

Where possible, distinguish a case that always stops at the same gate from an intermittent case. Record the local time, affected project or result, and exact visible state without interpreting it. Do not assume that a browser message identifies a server-side cause, or that the absence of a visible error means processing succeeded. Current service status and account access require current evidence.

Vision result symptoms

For Vision, compare the result with the boundaries visible through the complete source sequence. Useful symptom descriptions include:

  • an expected region is absent;
  • the result extends beyond the visible object;
  • separate parts appear bridged;
  • a thin feature is missing or enlarged;
  • a cavity remains filled;
  • orientation changes appear inconsistent; or
  • background or support geometry appears in the result.

These observations can relate to silhouette extraction, object/background separation, coded orientation, source quality or the limits of visual-hull reconstruction. They do not identify one cause by themselves. A concavity that never changes the visible silhouette may remain unresolved even when the capture is valid; a region lost because of poor separation may instead require a corrected source.

Do not repair or crop the result before preserving the original evidence. Use Vision Scan Problems to distinguish correctable capture symptoms from method boundaries. For the underlying reconstruction model, read Vision Scanning and Voxel Carving.

Laser or Combo result symptoms

Begin Laser and Combo diagnosis only after confirming that the current product-specific setup, safety, alignment and calibration requirements apply to the installed hardware. Keep the laser off whenever classification, powered operation, operating zone, supervision or protective measures are uncertain.

Observable symptoms may include an interrupted or weak projected response, missing surface bands, isolated outliers, repeated offsets, inconsistent geometry around a rotation, or disagreement between Laser- and Vision-derived contributions. Separate three questions:

  1. Was usable laser-enabled and, where required, laser-disabled evidence recorded?
  2. Was the installed geometry correctly established and calibrated under current instructions?
  3. Did the relevant independent processing paths produce evidence suitable for reconciliation?

A visible straight line does not prove calibration. A completed Combo process does not prove that both evidence paths were useful or correctly reconciled. Do not move a holder, alter powered hardware or improvise a protective measure as a troubleshooting shortcut.

Use Laser and Combo Scan Problems for the method-specific route and Documentation for current operating requirements.

Multi Merge, mesh, export or import symptoms

Identify which downstream responsibility owns the symptom:

  • Registration: scans align in one region but separate elsewhere, settle into a plausible wrong pose, or lack reliable overlap.
  • Geometry or topology: holes, disconnected regions, non-manifold structures, incorrect normals or deliberate repair surfaces affect the mesh.
  • Representation or export: the wrong point cloud, mesh variant, attributes or file family was selected.
  • Transfer or import: a file is incomplete, companion resources are missing, or the destination interprets units, axes, textures or attributes differently.

Do not use mesh repair to conceal a registration error. Do not change formats to correct missing reconstructed geometry. Do not merge sources merely because a denser result looks more complete.

For alignment and overlap, use Multi Merge Problems. For topology, formats, downloads and destination behavior, use Mesh and Export Problems. Preserve the original scans, transformations and first export so each stage can be compared independently.

Escalate a reproducible case

If the published checks do not resolve the issue, prepare a support request that another person can follow:

  • identify the product, extension and configuration;
  • name the selected workflow and the stage where the problem first appears;
  • provide the source, project, job and result identifiers available to you;
  • describe the symptom in observable terms and identify the affected region;
  • state whether the issue repeats with the unchanged source;
  • list the controlled checks and changes already completed;
  • include the exact visible message or error information without paraphrasing it; and
  • provide only the relevant screenshots or files requested for diagnosis.

Do not send passwords, full payment credentials, unrelated files or more personal information than the case requires. Confirm the current route for scan files and data-policy questions before sharing sensitive or rights-restricted material.

Contact Support

Review Privacy and Scan DataGood 3D scanning habits are rarely secret settings or universal shortcuts. They are small, controlled decisions that make the capture easier to understand, repeat and evaluate.