Skip to main content
Version: 3.4.20 (unreleased)

Structure-from-Motion (SfM) Photogrammetry

Requires the SfM licence feature

The photogrammetry workflow and its branch of the project tree appear only when your licence includes the SFM feature. See Why Is This Greyed Out? if you cannot find it.

VRGS can rebuild a 3D scene from a set of overlapping photographs. The pipeline runs as a chain of stages. The first always runs; how far Run Reconstruction goes after it is the workflow's build goal — a textured mesh, unless you choose otherwise:

  1. Sparse SfM — detects features in each photo, matches them across overlapping pairs, and solves for every camera's position/orientation and a sparse coloured point cloud (the matched tie points). This stage always runs.
  2. Dense MVS — takes the solved cameras and estimates a depth map per view, then fuses them into a dense coloured point cloud of the surface.
  3. Mesh — turns the dense cloud into a triangulated surface (Poisson, or Greedy Projection from the menu), carrying the cloud's per-vertex colour.
  4. Texture — projects the solved photographs back onto the mesh and bakes a high-detail photographic texture.
  5. Export Tiled Model (SLPK) (optional) — cuts the textured mesh into a tiled, level-of-detail Scene Layer Package that streams in VRGS and opens in ArcGIS.

Typical inputs are drone/UAV imagery or hand-held photos of an outcrop. Typical outputs are a georeferenced camera set (with image thumbnails in the 3D view), a sparse point cloud, a dense point cloud, a surface mesh, a photo-textured mesh you can interpret, and a tiled model of it to stream or share.

Workflow in one line

New an SfM workflow → Add Photos… → Run Reconstruction. With the default build goal that one run ends with a textured mesh. Choose Build up to and Quality first if you want less (a quick sparse check) or more care; Create Mesh and Texture Mesh from Photos stay on the menu for choosing their settings by hand.

Running a reconstruction​

All actions live in the SFM pane — the SFM tab docked beside the Data Tree. Its top row, SFM Workflows, holds one row per workflow (one model of one survey) and the shared Photo Pool. Every command below is on the right-click menu of the row it names.

StepActionWhere
1. Create a workflowRight-click SFM Workflows → NewCreates Model 1, Model 2, … — or let Athos create it from a folder
2. Add imagesRight-click the workflow → Add Photos…Browse to your photos — JPEG, TIFF or PNG, and iPhone HEIC without converting it first. The import runs in the background
3. Configure (optional)Select the workflow. In the Properties pane, Run setup holds what most surveys need: Build up to (how far the run goes), Quality, the altitude datum and the region of interestSee Build up to and Quality
4. Control (optional)Right-click the workflow → Georeference → Import Ground Control Points (CSV)…See Ground control points
5. ReconstructRight-click the workflow → Run ReconstructionShows the run plan first, then runs on a background thread with a progress bar, and carries on to the mesh and the texture when the build goal asks for them
6. Check qualityRight-click the workflow → Results → Show Quality ReportSee Quality report
7. Review imagesRight-click the workflow → Results → Open Photo BrowserPer-photo keypoint/track stats; also where you mark control points
8. Mesh (by hand)Right-click the workflow → Create Mesh (Poisson)… (or Mesh and Texture → Create Mesh (Greedy Projection)…)Done for you when the build goal is Mesh or Textured mesh; by hand to choose its settings. See Building a mesh
9. Texture (by hand)Right-click the workflow → Texture Mesh from Photos…Done for you when the build goal is Textured mesh; by hand to choose the budget or texture part of a mesh. See Texturing the mesh
10. Tile (optional)Right-click the workflow → Mesh and Texture → Export Tiled Model (SLPK)…Needs a mesh, normally the textured one; see Exporting a tiled model (SLPK)

The workflow menu​

The workflow's right-click menu puts the main steps first — Add Photos…, Run Reconstruction, Create Mesh (Poisson)…, Texture Mesh from Photos… — then the two Athos commands, then the rest in submenus. What the workflow needs next is shown in bold: Add Photos while it has none, Run Reconstruction until it has a solve (or the dense cloud its build goal asks for), then Create Mesh, then Texture Mesh. Commands that cannot run yet are greyed out — Texture Mesh until there is a mesh, Show Region until a region is set, anything that changes the inputs while a run is in progress.

WhereCommandWhat it does
Top levelAsk Athos about this ModelOpens Athos on this workflow with a question suited to the stage it has reached: settings for a first run, the sparse result, the dense cloud, or why a run failed
Top levelAsk Athos to Build this ModelAthos reviews the settings and the build goal, shows you the run plan and starts the whole build on one yes — see Letting Athos build it
ResultsShow Quality ReportSee Quality report
ResultsWhat Will the Next Run Redo?Says, without running anything, which stages the next run will reuse and which it will redo, and why — see The run plan
ResultsOpen Photo BrowserThe per-photo table: keypoints, tracks, residuals, why a photo did not register; also where you mark control points
ResultsOpen Photos in Annotation ViewOpens the mesh's photos in the annotation view for SAM2/UNet interpretation
ResultsShow Camera GPS as Point CloudA QC cloud of the raw EXIF GPS positions, to compare against the solved cameras
Mesh and TextureCreate Mesh (Greedy Projection)…The alternative to Poisson — see Building a mesh
Mesh and TextureExport Tiled Model (SLPK)…See Exporting a tiled model (SLPK)
Mesh and TextureSelect Mesh Surface No Photo SeesSelects the mesh triangles that every photo framing them sees something else in front of — usually a second sheet a Poisson mesh built behind the real surface. Nothing is deleted: colour the mesh by the attribute it writes to see them, then use the mesh's Selection → Delete Selected
Mesh and TextureRefresh Camera Markers on MeshPublishes the solved cameras onto the workflow's mesh again; photos that failed to register are drawn red
GeoreferenceImport Ground Control Points (CSV)…, Use Project Ground Control PointsControl for this workflow — see Ground control points
GeoreferenceScale Bars (Known Distances)…Gives a model real size without GPS or control — see Scale bars
GeoreferenceSeed Mesh Tie Points from Ground ControlTurns measured control into the mesh's own tie points, so the mesh ribbon's Corrections → GCP can pull the mesh onto the survey
GeoreferenceAlign to Reference Elevation…Fits the model to a DEM or other reference — see Aligning a model to reference elevation
GeoreferenceAdd Satellite Imagery BasemapDrapes Bing aerial imagery under the model
Region of InterestSet Region from Selected Points, Show Region (Select Points Inside), Clear RegionLimit dense matching and meshing to a box — see Region of interest
SettingsCopy Settings from Another Model…, Save Settings to File…, Load Settings from File…, Reset Settings to Defaults…Reuse a tuned set of settings — see Reusing settings
BottomRenameRenames the workflow and the clouds and meshes it made (also F2)
BottomDuplicate WorkflowA new version with the same photos, settings and control and no results — see Several versions of one model
BottomReset Camera CalibrationReplaces the solved focal length, principal point and lens distortion with the EXIF nominal values and deletes the cached solve, so the next run refits the lens from scratch. Use it when the log reports a calibration as DEGENERATE or DEMOTED

The SFM Workflows row's own menu has New and Ask Athos to Build a Model from Photos… (see Letting Athos build it).

Where each workflow stands​

Each workflow's row carries a coloured badge with its stage: grey no photos or 12 photos (nothing run yet), amber importing, running 43% or cancelling, green sparse, dense, meshed or textured (how far it has got), and red failed when the last run did not finish — even if an earlier run left clouds behind. The badge follows a run live, so a glance down the tree tells you which models are done and which need you.

As soon as you Add Photos, any photo with EXIF GPS gets a camera marker in the 3D view at its GPS position — before you run anything. These are drawn without a thumbnail to mark them as provisional: they are where the receiver said the camera was, not a solved pose. After a reconstruction the registered cameras are redrawn with thumbnails, in their solved positions.

In the Vulkan 3D view, cameras count as part of the scene, so a project with nothing else in it still shows them: the view frames them from above when they appear, and Reset View comes back to them. A provisional marker stays about 6 pixels across however far away you are. Photos imported before the project has a coordinate system get their markers when one is set, and changing the coordinate system moves the provisional markers; a model with solved cameras, and a workflow that is running, are left alone.

The reconstruction runs in the background; progress appears on the main progress bar and on the workflow's badge. When it ends, the messages panel says how it went and what to do next, whoever started it:

  • a success line with the photos registered, the sparse points, whether a new dense cloud was made, and the time;
  • a tip when a tenth or more of the photos did not register (the Photo Browser says why for each);
  • a warning when nothing gave the model real-world scale, or the dense stage made no cloud this run;
  • the next step — Create Mesh, or raising Build up to — unless the build goal is already carrying on to the mesh, which reports itself;
  • for a failed run, the stage and the reason, and a pointer to Ask Athos about this Model; for a cancelled one, a plain note that the saved stages are kept.

The results are added to the project automatically:

  • <name> sparse — the sparse tie-point cloud (e.g. Model 1 sparse), carrying Observations and Reprojection error attributes you can colour by — see Inspecting the sparse cloud.
  • <name> dense — the dense MVS cloud, when the build goal is Dense cloud or further, carrying Fusion Views and Fusion Sigma attributes — see Inspecting the dense cloud.
  • <name> mesh — the surface mesh, from the build goal or Create Mesh (it later carries the baked texture and the photographs too).
  • Camera poses — each registered photo, with its image thumbnail.
  • Ground control points — any control you imported, as project objects under Ground Control Points in the Data Tree, showing how far the model landed from each one.

The mesh and texturing stages also run on background threads; the mesh links back to its workflow, so Texture Mesh from Photos always finds the mesh that workflow created.

Re-running is cheap — the solve is reused

A completed solve is kept in the workflow's workspace, and Run Reconstruction reuses it whenever nothing that shapes the solve has changed — same photos, same reconstruction parameters, same control, tie points and scale bars. The re-run then skips feature extraction, matching and registration entirely and goes straight to whatever is new.

The everyday case: you run with Build up to set to Cameras and sparse cloud to check the survey quickly, then raise it. The second run starts at the dense stage within seconds instead of re-registering every photo for half an hour. The same applies to tuning any Dense MVS parameter: the dense settings are deliberately not part of the reuse check, so dense experiments never pay the sparse cost. The log states plainly when a run reused the solve and when it did a full one.

Change any reconstruction parameter — or the photo list, ground control, tie points or scale bars — and the next run does an honest full solve. To force one without changing anything, delete sparse_solution.bin from the workflow's workspace folder.

Coordinate frame

The model is placed by whichever of these you give it, in this order of priority:

  1. Ground control points — 3 or more marked control points fit the model directly to your survey (centimetre accuracy). See Ground control points.
  2. Camera GPS — with Use GPS prior on and valid EXIF GPS, the model is fitted to the camera positions in the project's coordinate system, so the output lands alongside the rest of your project data (metre accuracy).
  3. Nothing — the model is reconstructed in an arbitrary local frame with no scale and no orientation. A scale bar can still give it real size, but it will not be georeferenced.

If the photos carry GPS and the project has no coordinate system yet, VRGS opens the Coordinate System dialog with the UTM zone covering your photos already selected — accept it or search for a different CRS.

Whatever placed the model, the quality report always states which data did it and how well it fitted, and the workflow's Real-world scale property, near the top of its Properties page, says it in one line: control points or camera GPS with the fit's RMS, scale bars only, or NONE — an arbitrary frame in which distances, dips and azimuths are not real.

When a workflow has made more than one mesh (each Create Mesh adds one), the commands that need a mesh ask which, and the one you pick becomes the workflow's current mesh, shown in bold under Outputs. The cloud and mesh rows under Outputs show the same loading and progress badge as their rows in the Data Tree, and their check boxes stay in step with those rows.

Saving during a run​

A run does not depend on you saving. It saves the project as it starts, so the workflow, its photos and its settings exist from the first second, and it saves again as each stage finishes, so closing VRGS, a crash or a power cut costs at most the stage in progress.

Stage finishedWhat is saved
Feature extraction, matching, registrationThe result is already in the workflow's workspace folder, and the workflow records how far it got. The whole project is saved as well only when a save is due: at least a minute since the last one, and at least 20 times as long as that one took, which holds these saves to about 5 % of the run on a large project.
Sparse reconstruction, dense MVS, mesh, textureThe result goes into the project and the whole project is saved.

The run waits while a save is written. After 10 minutes it carries on, and the save stays queued. These saves never ask a question, so an unattended run is not held up by one. If one fails, the messages panel says so and the result is still in memory: save the project with Ctrl+S before closing. A project this session may not write is not saved as the run goes, and the panel warns once; the stages it finished are still in the workspace folder.

Save After SfM Stage in Project Properties → Saving & Backup, on by default, controls these saves. The interval autosave cannot stand in for them, because it skips while background processing is running.

Opening a project after an interrupted run. The messages panel says once what happened, for example: The last run stopped after matching (the application closed or crashed). What it finished is saved; the next step in the workflow menu carries on from there. The workflow's Status row in the Properties pane keeps the message. The badge shows how far the saved results reach, not running or failed, and the next step is in bold as usual. Run Reconstruction starts again and reuses whatever the workspace caches kept.

A run that stops part-way keeps the earlier model. If you cancel a run, or it fails, before its solve has finished, and an earlier run left a complete model, that model's camera positions, calibrations and clouds stay as they were, and the panel says so. With no earlier model, whatever the run solved is saved, since it is all those hours produced.

The run plan​

Run Reconstruction first opens the Run Reconstruction dialog, so a run that cannot finish, or will not give what you expect, is stopped before an hour of work rather than after. Its upper part is the plan:

  • What the run will reuse and redo, and why — for example the sparse solve reused because nothing that shapes it has changed, and the dense stage redone because a dense setting has.
  • How long, from the last run's own stage timings (not shown before the first run).
  • Size and position — what will give the model its real size: control points (naming any that will not be used because they are marked in too few photos), camera GPS, scale bars only, or nothing.
  • Region of interest, when one limits the run.
  • Memory — the last run's peak against what can be committed now, with a warning when the dense stage will not fit.
  • Then — the stages the build goal adds after the run: the mesh, the texture.

Below the plan are the controls that change it, and the plan is worked out again as soon as you change one:

  • Build up to and Quality — the same choices as in Run setup.
  • Limit dense matching and the mesh to the region of interest — available once a region is stored.
  • Lower the Dense Quality — offered when the memory warning shows: one click moves Depth map quality one rung down (about a quarter of the memory) and the plan says whether it now fits.
  • Run straight away next time — skips this dialog from then on (the same as turning off Confirm each run with its plan in Run setup).

Click Run to start, Cancel to put the workflow back as it was when the dialog opened, or Ask Athos to Check to hand the plan to Athos, which reviews the settings against it and offers to start the run. What Will the Next Run Redo? (Results submenu) shows the reuse-and-redo part at any time without offering to run. A run that Athos starts does not open this dialog: Athos shows you the same plan in the chat and waits for your yes.

Region of interest​

A region of interest limits the expensive stages to the part of a survey you need. It is a box in project coordinates:

  1. Run the reconstruction once (the sparse cloud is enough; a dense cloud is easier to select on), select the area to keep on the model's cloud with Polygon Select or circle select in the 3D view, then right-click the workflow → Region of Interest → Set Region from Selected Points.
  2. Or type the corners under Run setup → Region of interest (Min X/Y/Z, Max X/Y/Z) and tick Use region.

With the region on, dense matching sweeps only the photos that see it, and the Poisson mesh is solved on the box plus a 5 % margin and cut at the box — so the texture bake covers only that part too. The sparse solve still uses every photo. Show Region (Select Points Inside) selects the cloud points inside the box so you can see it; Clear Region removes it. Duplicate Workflow copies the region, and it moves with the model when you align it to reference elevation.

Letting Athos build it​

Athos can take a model from a folder of photographs to a textured mesh with one confirmation:

  1. Right-click SFM Workflows → Ask Athos to Build a Model from Photos… and pick the folder (or just ask in the chat: "make a 3D model from the photos in E:\Drone\Flight1"). Athos lists what it found — how many photos, their size, any HEIC to convert, the new model's name and build goal — and creates the workflow when you agree. The photos import in the background.
  2. Athos checks the settings and shows you the run plan, with the stages the build goal adds after the run.
  3. One yes starts the whole build. Athos tells you in the chat when the run ends and as the mesh and the texture finish.

On an existing workflow, Ask Athos to Build this Model does steps 2 and 3. With a local Ollama model Athos can show each step but not take it; switch to a provider with tool calls (/switch claude) to let it act.

iPhone (HEIC) photos​

iPhones save photos as HEIC unless Settings → Camera → Formats is set to Most Compatible. Add Photos… takes them as they are — .heic, .heif and .hif files, and HEIC photos that another tool has renamed .jpg — and converts each one to a JPEG in the project's photo pool. The originals are left where they are, and a HEIC that has been added before is not converted again. The JPEG is the one the phone would have written in Most Compatible mode:

  • Its EXIF comes across unchanged — GPS position, altitude and heading, focal length and 35 mm equivalent, camera make, model and lens — so the provisional camera markers, GPS georeferencing and the starting focal length work exactly as they do for a JPEG.
  • The pixels stay the way the camera stored them, with the EXIF orientation tag that tells a viewer to turn a portrait shot upright.
  • Its colour profile is kept (Display P3 on recent iPhones).
Don't rotate the photos upright first

Most converters turn portrait shots upright. For SfM that splits one camera in two: photos are grouped into cameras by image size as well as make, model and focal length, so an upright portrait (for example 4284 × 5712 pixels) and a landscape shot (5712 × 4284) from the same lens are solved as two cameras, each from fewer photos. Adding the HEIC files directly keeps them in one camera.

The conversion uses Windows' own HEIC support, which needs two extensions from the Microsoft Store: HEIF Image Extensions (free) and HEVC Video Extensions, which may be a paid item unless your PC came with HEVC Video Extensions from Device Manufacturer. If Windows cannot decode HEIC, the log says which extensions to install, and the other photos you selected are still added. Several photos convert at once — about 0.2 s per 24-megapixel photo on a workstation — and the JPEGs take roughly twice the disk space of the HEIC files.

Several versions of one model​

Comparing settings usually means building the same survey more than once. Two things make that cheap:

  • One copy of each photograph. Add Photos… copies images into the project's photo pool (SFM_WORKSPACES/_shared/photos in the project folder), and recognises a photo by its content, not its name. Adding the same survey to a second workflow copies nothing; the log says how many photos were already in the pool. Adding a photo a workflow already has is skipped.
  • One feature cache. Every workflow in the project shares one feature cache, so a second workflow over the same photos with the same detector, working resolution and feature budget skips feature extraction entirely. Workflows made before the pool keep their own photo folders, and their caches are still read, so re-running an existing model does not re-extract.

Duplicate Workflow (right-click a workflow) makes a new version in one step: the same photographs — shared, not copied — with their enabled or disabled state, the same settings, ground control, scale bars, tie points and region of interest, and no results. Change what you want to compare and run it; the original and its clouds and meshes are untouched. A lens the original solved is not carried over, so the new run solves its own; a calibration you attached from a file is kept.

The Photo Pool row. The SFM tree lists the pool as its own row, Photo Pool, beside the workflows, with a count of the images it holds:

  • Tick it to show the pooled images on the map and in the 3D view — each image once, at the GPS position in its EXIF, in pale cyan so a pool marker is never mistaken for one of a model's solved cameras. A drone photo is turned to its EXIF heading; nothing more about its attitude is known, so pool markers have no view frustum. This needs the project's coordinate system to be set, since the EXIF positions are projected into it.
  • Right-click → Remove Unused Photos… moves the pooled images that no workflow, mesh or photograph in the project uses — with their annotation files — to the project's RECYCLING folder. Nothing is deleted: move them back from there, or delete them yourself to free the space. The command waits while photos are being imported.

A model's Images row. Its check box shows or hides that model's cameras on the map (one layer per model, named SfM: <model>) and in the 3D view, leaving its clouds and meshes as they are. Right-click it and choose Show Photos as Images in 3D to see the photographs themselves: each solved photo is drawn on the surface it shows, at the distance of the model's own points in its view, and slightly see-through. A correct camera's photo lies over the model; a wrong pose or lens shows as a mismatch between the picture and the surface. The nearest twelve are shown at up to 1024 pixels and fill in over a few frames as you move. A camera that sees too few points, or a model whose point cloud is not loaded, has its photo drawn a short way in front of the lens instead.

Drone cameras show their view. An aerial photo's marker is a drone kept level and turned to the flight heading, which does not show where the camera was pointing. Each one now carries a small frustum: four lines from the lens to the image rectangle, with a tick on the side that is the top of the picture, so a nadir survey and an oblique one are told apart at a glance.

Display properties. Click a model's Images row to see how its cameras are drawn in the Properties pane:

PropertyWhat it does
Show camerasThe row's check box: this model's cameras on the map and in 3D.
Camera sizeThe size of the camera and drone markers. Thumbnails, frustums and image planes scale with it. Until you change it, the project's photograph camera size is used.
Show thumbnailsA small copy of each solved photo in front of its lens.
Camera frustumsDrones only (the default), All cameras or None. A photo without a solved attitude never gets one.
Show photos as imagesEach solved photo drawn on the surface it shows, to check the camera against the model. The same as the row's Show Photos as Images in 3D command.
Show GPS camera positionsEach photo's EXIF GPS position, as a small blue marker.
Show GPS error linesAn amber line from each registered photo's GPS position to its solved camera: the GPS error per camera. Independent of the markers.
Camera Colour ByColour the markers by a quality figure from the last run.

These are saved with the model and copied by Duplicate Workflow.

Click the Photo Pool row for the pool's own page: Show cameras (the row's check box), Camera size, and Show thumbnails, which puts a small copy of each photo above its marker, turned to face you. A pooled photo has a position and at most a compass heading, so it gets no frustum or image plane. The size and thumbnail settings are saved in the pool's index.

Selecting a camera. Click any camera marker in the 3D view — a model's, the pool's, or one published to a mesh — to select it. It is drawn highlighted and the Properties pane shows the photo: its file, position, EXIF and calibration. Double-click a model's camera to open the photo browser on that model's photos.

What the workflows share

Each workflow keeps its own camera poses, calibrations, outputs and quality figures — only the image files and the feature cache are shared. Deleting a workflow never deletes photos. Annotations drawn on a photograph are saved beside the image file, so a pooled photo's annotations appear in every workflow that uses it.

Reusing settings​

The workflow's Settings submenu carries a tuned set of settings to another survey:

  • Copy Settings from Another Model… — a menu headed Copy the settings of: lists the project's other workflows; pick one to take its settings and build goal.
  • Save Settings to File… / Load Settings from File… — the same, through a small .json file you can keep with your methods or send to a colleague.
  • Reset Settings to Defaults… — every setting back to a new workflow's (Balanced).

What travels is the settings and the build goal — never the photos, control, region of interest or results, which belong to a survey. The altitude datum stays with the workflow it was set on: it describes that survey's GPS. The settings being replaced are kept as settings_backup.json in the workflow's workspace folder, so Load Settings from File… can put them back. None of these is allowed while a run is in progress.

Build goal and quality​

Two settings in Run setup decide most of a run: how far it goes, and how careful it is. Every other setting is in the parameter reference.

Build up to​

How far Run Reconstruction goes. Start here.

  • Options: Cameras and sparse cloud, Dense cloud, Mesh, Textured mesh (the default for a new workflow).
  • What each does:
    • Cameras and sparse cloud — the solve only. The quick check that a survey worked, and the cheapest run.
    • Dense cloud — adds the dense point cloud. Choose it when you want to align to reference elevation, set a region of interest or tune the mesh by hand before meshing.
    • Mesh — then builds a Poisson mesh of the dense cloud, with its depth taken from the point spacing and the default trim, limited to the region of interest when one is on.
    • Textured mesh — then bakes a photo texture onto that mesh at the budget the photographs support (see Texturing the mesh), on a decimated copy when the workflow's Texture onto decimated copy setting says so.
  • How it reports: the run plan lists the stages that will follow the run. Each stage reports in the messages panel when it starts and when it ends, and a stage that cannot start (no dense cloud this run, an empty mesh) says why and stops the build there. Cancelling the run stops the chain, and the bake has its own ✕ on its progress bar.
  • Re-running: the solve is reused when nothing that shapes it has changed, but the dense stage runs again whenever the goal includes it, and each run with a mesh goal adds a new mesh (the earlier ones are kept). To mesh or texture a cloud you already have without re-running anything, use Create Mesh or Texture Mesh from Photos on the workflow menu instead.
  • Workflows made before November 2026 keep what they did: their goal is Dense cloud if Dense MVS was on, otherwise Cameras and sparse cloud.

Quality​

How carefully, for the whole build. The preset moves the handful of settings that genuinely trade speed against accuracy, so you rarely need to touch the rest.

  • Options: Fast, Balanced (the defaults), Accurate, Custom.
  • What it does:
    • Fast — quarter-resolution alignment, fewer features, retrieval matching, and an eighth-resolution dense cloud. Loses fine detail and some weak-overlap pairs. Use it same-day, in the field, to find out whether the survey actually worked.
    • Balanced — the shipped defaults: half-resolution alignment and a quarter-resolution dense cloud. What you want almost always.
    • Accurate — full-resolution alignment, dense features, exhaustive matching, tighter gates, and a half-resolution dense cloud. Markedly slower (on a large set the exhaustive matcher and the dense stage are the cost), but leaves nothing on the table: the half-resolution dense cloud is what keeps corners and ledges sharp.
    • Custom — a readout, not a choice: it means the settings below no longer match any preset. Selecting it does nothing.
  • What it sets: the alignment image scale, the feature budget (features per megapixel and the per-image cap), the match strategy and retrieval neighbours, the bundle-adjustment iteration caps, the two pixel gates (Registration tolerance and Huber threshold), which have to follow the image scale, and Depth map quality.
  • What it will not touch: your detector, GPS and altitude-datum settings, the build goal, and the dense matcher's own dials. A preset never silently undoes a decision you made for a different reason.
  • Older workflows saved as Fast or Accurate before November 2026 read as Custom, because their dense quality is the old Quarter; pick the preset again to bring them in line.

The Photo Browser​

Right-click the workflow → Results → Open Photo Browser, or double-click one of the model's cameras in the 3D view. It holds a table of the workflow's photographs and the selected photo. The strip above the table gives the run's state, its progress or result, GPS: (the GPS pair max distance, for the next run) and a button that starts, retries or cancels a run.

ColumnWhat it shows
FileThe photograph.
UseY, or off when the photo is left out of the next run.
Reg.Y when the last run registered the photo.
Why not registeredFor a photo that did not register, the reason and the registered photos it matched best, with the size of each match.
Keypoints, TracksThe features found in the photo, and those that became 3D points.
RMS pxThe photo's reprojection error.
Frame %, Max rWhere in the frame its tracks lie: the share of an 8 × 8 grid they reach, and the farthest from the centre, where 1.00 is a corner. A trailing ! flags a low value, and - means not measured.
Date, GPS, CameraFrom the photo's EXIF.
X, Y, Z, Omega, Phi, KappaThe solved camera position and orientation.

Why not registered says one of these, and then either the best matches or no verified match with any registered photo, which points at the matching rather than at the photo:

  • matched too little: sees 3 of the 20 3D points it needs
  • offered, but sees only 14 of the 20 3D points a pose needs
  • its matches gave no consistent pose (repetitive or degenerate view)
  • a pose was found but rejected: median error 12 px
  • unreadable photo or no camera data

Failed (N) appears above the table when the last run left photos unregistered. It lists them with their reasons, grouped by camera when there is more than one, and choosing one jumps to it. Its last two items act on the whole list: Leave these N photo(s) out of the next run and Put these N photo(s) back in the next run.

Right-click the photo:

CommandWhat it does
Reset ZoomGoes back to a scale of 1 and takes out any pan.
Fit WindowFits the whole photo in the pane.
Show Sky Mask (magenta)Overlays the sky filter's mask. Reads Show Sky Mask (run Dense MVS first) and is greyed out until there is one.
Goto in 3D ViewTakes the 3D view to this photo's camera. Greyed out for a photo with no solved pose.
Use in ReconstructionTicked while the photo takes part. Untick it to leave the photo out of the next run; it stays in the workflow and the Use column shows off. Takes effect at once and cannot be changed during a run.
Mark Ground Control PointOffered when the workflow has control points. See Ground control points.
Next Photo for This Point, Stop Marking Ground ControlOffered while you are marking a point.

Clicking the photo places tie points, which also link photos for scale bars: a click adds one, Ctrl+click selects the one under the cursor so later clicks extend that link across photos, and Shift+click deletes the nearest.

Inspecting the sparse cloud​

The sparse cloud carries two attributes you can colour by, filter on, and histogram like any other VRGS attribute:

  • Observations — how many cameras actually see each point. Thin coverage is where a reconstruction is weakest. Colour by this before launching a dense MVS run that will spend hours on geometry the sparse solve never really pinned down.
  • Reprojection error — the per-point residual in pixels. A healthy RMS can hide a bad tail; filtering to the worst points shows you exactly where the model is unhappy, rather than just telling you that it is.

Inspecting the dense cloud​

The dense cloud carries three attributes that say how well each point is supported. Colour, filter and histogram them like any other attribute:

  • Fusion Views — how many depth maps reached the point. Each depth map is one photograph's view of the scene, and each of its pixels has already been checked against other views before it counts (as many as Dense MVS consistent views, two by default), so 1 means one photograph's measurement confirmed by its neighbours, not an unchecked point. Low counts mark ground the survey saw from few positions: the edges of the coverage, overhangs, and faces seen only obliquely.
  • Fusion Sigma — how precisely those depth maps placed the point, in metres. Each depth map knows its own precision from its range and its baseline to the views it was matched against. A depth map from close range, or one that more views agree with, gives a smaller sigma. Treat it as a relative measure: where the cloud is better or worse known. It assumes the views' errors are independent, and views flown in one pass share their errors, so the true error is larger than this figure.
  • Fusion Support — the most views that agreed on where the point is, at their own precision, after estimates of other surfaces (a ledge in front of the rock, a layer behind it) were trimmed away. Fusion requires at least Dense MVS consistent views partners to survive that trim before it keeps a point, so the value is never below that setting plus one; higher values mark surface the survey measured consistently from more directions.

All three carry over to a Poisson mesh made from the cloud (see Where the mesh is measured). Clouds made before this release do not have them; re-run Dense MVS to get them.

Worked examples​

Drone survey with GPS (nadir)​

SIFT, Alignment image scale Half, Share intrinsics per camera on, Use GPS prior on, GPS sigma XY 2–5, GPS pair max distance set to a few times the photo spacing. Enable Dense MVS with the PLANE_SWEEP backend.

Convergent outcrop (oblique, high overlap)​

SIFT, Max features 8000+, Use GPS prior on if the photos are tagged. Enable Dense MVS and leave the default Sky filter on when the outcrop is shot against the sky.

Densest possible dense cloud​

Dense MVS confidence cutoff 0.6, Dense MVS consistent views 1, Dense MVS depth tolerance 0.04. (Expect more noise—clean up afterwards with point-cloud filters.)

Cleanest dense cloud​

Dense MVS confidence cutoff 0.85, Dense MVS consistent views 3, Dense MVS depth tolerance 0.015.

Fast preview​

ORB, Alignment image scale Quarter, Max features 4000, BA max iterations 40, Dense MVS off (or on with neighbor views 3).

Textured outcrop mesh​

Run the reconstruction with Build up to at Textured mesh, the default, which carries on to the mesh and the texture by itself. To choose their settings by hand, stop at Dense cloud, then Create Mesh (Poisson) at its defaults, and finally Texture Mesh from Photos and accept the recommended budget — it is derived from what your photographs can actually resolve, which is the ceiling on useful detail whatever you ask for.

Only override it if you have a specific reason: Texel size: 0.005 m with pages of 4096 asks for a 5 mm texel at most, which is worth doing when you need a guaranteed density for measurement rather than the best texture the imagery supports.

To share the model, or to stream it smoothly on a modest machine, finish with Export Tiled Model (SLPK)… at its defaults. Tick Bake the tile textures from the photographs when the tiles should carry everything the photographs resolve, not just what the mesh's texture pages hold. See Exporting a tiled model (SLPK).

More on photogrammetry​