SfM: Meshing, Texturing and Tiled Export

Requires the SfM licence feature

The photogrammetry workflow appears only when your licence includes the SFM feature. See Why Is This Greyed Out?.

With the default build goal, Run Reconstruction meshes and textures for you. This page is for doing those steps by hand: choosing the mesh method and its settings, controlling the texture bake, and cutting the result into a tiled model to stream or share. Running the reconstruction is in the SfM user guide.

Building a mesh

Once you have a dense cloud (<name> dense), turn it into a triangulated surface. Both methods run on a background thread, copy the cloud's per-vertex colour onto the mesh, and add <name> mesh to the project. Right-click the workflow and pick one:

Needs a dense cloud

Create Mesh works on the dense MVS cloud, so run a reconstruction with Build up to at Dense cloud or further first. If the dense cloud is missing or still loading, the action tells you so.

Create Mesh (Poisson)

Poisson reconstruction fits a single watertight surface through the points — it fills small gaps and gives clean, closed geometry — and then, by default, trims back the surface it invented away from the data (see Trim factor). Best default for outcrops.

Octree depth

• Default: 0 = auto — matched to the measured point spacing.
• What it does: the resolution budget of the whole reconstruction. Poisson builds the surface on a grid of 2^depth cells across the model, and nothing smaller than one cell can appear in the mesh, however dense the cloud is. At depth 8 a 300 m outcrop gets ~1.3 m cells — a 5-million-point cloud with centimetre spacing comes out looking melted, which is the classic "dense cloud looks great, mesh looks poor" complaint. Auto sizes the cell to ~2× the cloud's point spacing (capped at depth 13), and the log prints the chosen depth, cell size and spacing so the budget is visible. Each +1 of depth halves the cell and roughly quadruples time and memory.
• Example: leave at 0. Set an explicit 9–10 only when you want a lighter, generalised mesh — for draping or as a fast preview.

Samples per node

• Default: 4.
• What it does: how much noise averaging Poisson applies: how many input points fall in a leaf cell before it is fully trusted. 1 interpolates every point exactly — right for clean laser scans, wrong for photogrammetry, whose dense clouds carry centimetre-scale noise that would be reconstructed as surface bumps at high depth. 4–8 averages that noise away while the octree depth carries the real detail.
• Example: 4 for drone photogrammetry; 1 for TLS/LiDAR input; raise toward 8 if a noisy cloud still meshes bumpy.

Trim factor (× point spacing)

• Default: 2.5. 0 keeps the full watertight surface.
• What it does: Poisson extrapolates surface beyond the real data: a rim past every edge of the cloud, and closed bubbles around small clusters of stray points. The trim keeps a vertex only when at least 3 input points lie within factor × the cloud's point spacing (the median distance between neighbouring points, measured over the whole cloud), and deletes the triangles whose three corners all fail that test, so the true edge of the data is not eaten into. Lower trims more aggressively (tighter to the data, but can punch holes); higher keeps more invented surface; 0 disables trimming.
• Example: leave at 2.5. On a test sea cliff, compared with the old setting (6, one point), it cut the share of mesh with no point within 8 cm from 38 % to 16 % on the worst patch while removing under 0.5 % of the measured surface; at 2 it began punching holes. Raise to 3–4 if a sparsely sampled area comes out holed; set 0 only when you specifically want a closed watertight mesh.

Smallest piece (octree cells)

• Default: 25. 0 keeps every piece.
• What it does: after the trim, deletes every disconnected piece of mesh whose area is smaller than this many octree cells squared. The trim turns Poisson's bubbles around stray clusters into small loose fragments; this removes them. The largest piece is never deleted. Because it is counted in octree cells, one value means the same thing at every depth (at an 8 cm cell, 25 is about 0.17 m²).
• Example: leave at 25. Raise it if loose fragments remain; set 0 to keep every piece and clean up by hand with Progressive Component Select (below).

Mark the filled-in surface instead of deleting it

• Default: off.
• What it does: keeps the whole surface Poisson made, and records the faces the trim and the smallest-piece step would have deleted instead of deleting them. They get a 1 in the mesh's Interpolated triangle layer, and the rest get 0. Trim factor and Smallest piece still decide which faces those are. Deleting the marked faces would leave exactly the mesh you get with the box off, so one reconstruction gives you both:
  • a closed surface for viewing, texturing and VR;
  • its unmarked part as the surface the points measured.
• Seeing and excluding the marked faces:
  • To see them, colour the mesh by Interpolated (right-click → Visualization → False Color → By Attribute).
  • To leave them out of exports and out of Grow Planar Patches and Auto Structural Mapping, tick the layer's Use Filter, set its Filter Maximum to 0, and turn on the mesh's Use Attribute Filters. The filter does not hide faces in the 3D view.
• Example: turn it on when the mesh is for viewing or VR as well as for measuring. It is also useful to see how much of the surface Poisson filled in before you settle on a trim factor.

Leave out LAS vegetation and noise points

• Default: on.
• What it does: for a cloud imported from LAS, leaves out the points in the vegetation classes (3 low, 4 medium, 5 high) and the noise classes (7 low noise, 18 high noise) before meshing. Poisson closes a surface over whatever it is given, so vegetation left in becomes a skin of invented ground over the canopy. Ground, buildings, water and the other classes are kept. The log reports how many points were left out. Clouds without LAS classes are not affected.
• Example: leave on for airborne or drone lidar. Turn it off only if the vegetation is what you want to mesh, or the classification is known to be wrong.

Thin the points to the octree resolution first

• Default: on.
• What it does: keeps one point per half octree cell before solving. Poisson cannot show anything finer than one cell, so the extra points only cost memory and time. Colour is still transferred from every point of the full cloud.
• Example: leave on. Turning it off solves on every point: slower and more likely to run out of memory, with no more detail in the mesh.

Use the legacy PCL solver

• Default: off.
• What it does: solves with the Poisson code bundled in PCL, which VRGS used until October 2026, instead of PoissonRecon 18. PoissonRecon follows the points as closely or closer in about half the memory. The old solver is kept for one release so a new mesh can be compared with one it made.
• Example: leave off.

Where the mesh is measured: the support layers

Poisson fills gaps, so part of every Poisson mesh is surface the solver interpolated rather than surface the points measured. Each Poisson mesh carries two vertex layers that say which is which. Right-click the mesh → Visualization → False Color → By Attribute and pick one:

• Support Distance: how far each vertex is from the cloud, measured to its third-nearest point and given in model units (metres in a projected project). This is the number the trim tests. Measured surface reads roughly one point spacing; surface Poisson filled in reads several. A thin band of vertices above the trim distance along the edge of the data is expected: the trim keeps it so as not to eat into the edge.
• Poisson Density: how fine a surface the points support at each vertex, as an octree depth. Higher is better supported, and filled-in surface reads several levels lower than the surface around it. Only PoissonRecon, the default solver, produces it; the legacy PCL solver cannot.

A mesh made from an SfM dense cloud also carries the cloud's Fusion Views and Fusion Sigma (see Inspecting the dense cloud): each vertex takes the values of the cloud point nearest to it. On filled-in surface that point can be far away, so read these together with Support Distance.

A mesh made with Mark the filled-in surface instead of deleting it also has the Interpolated triangle layer: 1 on the faces the trim and the smallest-piece step would have deleted.

When Poisson is run again on an existing mesh, every vertex is replaced. The mesh's colour and its number-valued vertex attributes follow the new vertices, each taking its nearest old vertex's value; attributes that cannot follow (vector attributes, and every triangle attribute except Interpolated) are emptied, and the log names them.

The log reports the median support distance of each new mesh. Before measuring on a Poisson mesh (taking a dip, fitting a plane, tracing), colour it by Support Distance to check that the area you are measuring is supported by points. Meshes made before this release do not have these layers; mesh the cloud again to get them.

Meshing a laser scan: give it its scanner position

Poisson needs every normal to face out of the rock. An SfM dense cloud's normals already do. A cloud without normals of its own gets them estimated from each point's neighbours, and those have no side until something says which way is out. VRGS looks for a viewpoint, in this order:

1. the cloud's scanner origin, if it has one: right-click the cloud → Transform → Set Scanner Origin, whose matrix's translation is the scanner position, or Transform → Import Transform Matrix for a scan exported in its scanner's own coordinates;
2. a scan position with the same name as the cloud;
3. the coordinate origin, when the cloud sits around it, as a scan still in its scanner's own coordinates does;
4. for a LAS cloud, a point above the middle of the survey.

A scanner origin, a scan position and a point above a LAS survey saw every point, so each normal simply faces it. The coordinate origin is only a guess at a scanner, so there the sides are passed from neighbour to neighbour until they agree across the surface, and the viewpoint only decides which way each connected piece faces as a whole. The same happens when nothing applies, with the middle of the cloud as the viewpoint. The log names the one it used.

A cloud merged from several scan positions needs nothing from you: leave its scanner origin unset, because no one position saw all of it. Giving it the origin of one scan faces everything toward that scan, and whatever only the others saw turns away and can close sheets and bubbles. For a single laser scan, set its scanner origin. If a mesh still comes out inside out, set the origin of a single scan and mesh again, or turn the mesh round with Quality & Cleanup → Restructure → Reverse Winding. Show Normals on the mesh shows which way its normals point.

Cleaning up after Poisson

Smallest piece removes the small disconnected fragments automatically. Larger ones can survive it: vegetation, scaffolding, patches of sky floating near the outcrop. Progressive Component Select is the quickest way to get rid of those: it sorts the mesh's disconnected pieces smallest-first and lets you delete them with a slider, and it cannot select the main surface however far you drag. See Preparing a Model for Interpretation.

Create Mesh (Greedy Projection)

Greedy projection triangulates the points directly — it follows the cloud closely and is fast, but it does not fill gaps (sparse areas stay holed). Use it when you want the raw measured surface rather than an interpolated one.

Field	Default	What it does
Search radius	0.5	Maximum edge length / connection distance, in model units. The single most important value — set it to a few times the point spacing.
Max edge multiplier (μ)	2.5	Caps an edge at μ × the local point distance, so dense areas use short edges and sparse areas longer ones.
Max nearest neighbours	100	How many neighbours each point may connect to. Higher closes more triangles (slower).
Max surface angle	45°	Don't connect points across a normal change larger than this — preserves sharp edges.
Min triangle angle	10°	Lower bound on triangle angles (avoids slivers).
Max triangle angle	120°	Upper bound on triangle angles.

Poisson vs Greedy

Use Poisson for a clean, closed surface you'll texture or interpret. Use Greedy for a fast, faithful triangulation of exactly the measured points when you don't want gaps filled in.

---

Texturing the mesh

Texture Mesh from Photos… projects the solved photographs back onto the mesh and bakes a photographic texture — far more detail than the per-vertex colour the mesh inherits from the cloud. It needs a mesh (run Create Mesh first) and the workflow's photos. The bake runs on a background thread and the texture is saved with the project.

The bake dialog

If the workflow has more than one mesh, VRGS first asks which one to texture. Then one dialog asks everything:

• The mesh and the photographs — the mesh's triangle count, and how many of the workflow's photographs have a solved pose and will be projected.
• Texture (only when part of the mesh is selected) — the whole mesh alike, the selected part only as a new mesh, or the whole mesh with full detail on the selection. See Texturing part of a mesh.
• Texture budget — Recommended, a number of Pages of a chosen size, or a Texel size.
• Bake onto a decimated copy of … million triangles — see below.

The line under the budget says what it gives each triangle — "About 340 texels per triangle over 1,639,133 triangles", for example — and warns when that is very thin. Click Texture to start the bake or Cancel to leave.

You do not have to change anything. The dialog opens on the recommendation, worked out from your own data:

Recommended: 2 page(s) of 8192 x 8192  (512 MB)
The photographs resolve about 0.043 units per pixel here; more texture than that
stores blur, not detail.

The recommendation is arithmetic, not a house default. A photograph resolves the ground at range ÷ focal length in pixels, so the whole survey contains about mesh surface area ÷ gsd² genuinely distinct texels — and asking for more texture than that stores interpolation, at full cost in memory and bake time. VRGS sums the real triangle areas, takes the median ground sample distance across the posed photographs (a median so one distant or badly-posed camera cannot skew it), then picks the smallest page size that covers the requirement in four pages or fewer. When the mesh, not the photographs, limits what can be stored, the dialog says so. If no recommendation can be worked out, Recommended is greyed out and the dialog opens on Pages.

This is the setting people get most wrong

Texture resolution is easy to over-buy. A survey whose imagery supports four pages of real detail will happily accept a request for 128 — and spend gigabytes of disk and hours of bake time storing blur. The recommendation exists so that the number of pages is tied to what the photographs actually contain rather than to a guess.

Pages

Fix the number of texture pages and their size, and VRGS shares those texels out over the surface as described in How the texels are shared out. Use it when you want a hard limit on texture memory rather than a guaranteed detail. Until you type a number, the page count follows the page size you pick: the recommendation's count at its own size, otherwise about 64 texels per triangle, allowing for the ~30 % of each page that goes on the padding every atlas chart needs:

pages = triangles × 64 ÷ (page size² × 0.7)

The page sizes on offer, with what each page costs:

Page size	Memory per page
2048	16 MB
4096	64 MB
8192	256 MB
16384	1 GB

• Why 16384 is the ceiling: graphics hardware will not create a 2D texture larger than this — 16384 is the limit on AMD and Intel GPUs, and the Vulkan standard only guarantees 4096. Some high-end NVIDIA cards manage 32768, but a page that size is 4 GB and sits on the single-allocation limit most drivers report, so it would work on one machine and fail on the next.
• Example: 4096 suits most meshes; 8192 where you need more than about four pages at 4096; 1 page for a light preview texture.

Bigger pages are not automatically cheaper

Nine pages at 4096 is 576 MB; one page at 16384 is 1 GB for the same texel count. Fewer, larger pages pack slightly better and cost fewer draw calls, but they are not the smaller option. The recommendation weighs this for you.

Texel size

Give the real-world size each texel should cover, in project units, and VRGS packs the atlas at that density, in pages of the size chosen above: 0.005 m means each texel is 5 mm on the outcrop (200 texels per metre). It opens on the photographs' own ground sample distance. Smaller is sharper but needs more pages; there is a cap of 8 pages, and if your texel size would need more, VRGS coarsens the density and notes it in the log rather than exhausting memory.

How the texels are shared out

The budget does not give the whole mesh one texel density. Each atlas chart gets the density its photographs support, one texel per photo pixel at the finest photo that frames it, up to one ceiling for the whole mesh. The ceiling is the highest the page budget holds, or with Texel size: the size you typed, which charts only come down from. So:

• Ground the photographs barely resolve takes fewer texels, down to an eighth of the ceiling's resolution, and the texels it frees go to ground they resolve finely. Surface no photograph frames takes that lowest density.
• When everything fits at the density its photographs support, the bake uses fewer pages than the budget allows. A page count is a limit, not a promise.
• A last page that would be under 5 % full is dropped by packing its charts a little coarser, and the log reports the pages dropped.

The log gives the ceiling, the share of the surface given less, and how much of each page ended up as surface. Colour the mesh by the texture resolution attributes to see the result.

Bake onto a decimated copy

A dense mesh unwraps into millions of tiny charts whose padding fills most of the texture. Ticked, the bake runs on a simplified copy of the mesh — a new mesh in the workflow, with the size you type — and the same pages hold several times the surface detail. The copy is named for its size (<mesh> (19.3M)), and the full mesh is not changed. The bake's report gives how far the copy sits from the full mesh, in units and in texels. Beyond 2 texels it warns, because the photographs land that far from where they belong; a larger copy follows the surface more closely. The box starts as the workflow's Texture onto decimated copy setting says: always at that size, never, or (the default) ticked when the budget suggests one, at the suggested size.

Texturing part of a mesh

Select triangles on the mesh first — with the Edit tab's selection tools, or with Select Mesh Surface No Photo Sees — and the dialog adds a Texture choice:

• The whole mesh alike — as if nothing were selected.
• The selected part only, as a new mesh — the selection is copied into a new mesh (<mesh> (selection)), which is baked with a recommendation of its own. The copy is baked as it is, never decimated.
• The whole mesh, full detail on the selection — one texture for the whole mesh, with the selection at full resolution and the rest at the percentage you give (25 % by default, from the workflow's Texture detail outside the selection). A quarter of the resolution is a sixteenth of the texels, and the texels saved go to the selection. Atlas charts are split at the selection's edge, so the two densities do not share a chart.

The region of interest is a different tool: it limits dense matching and meshing before the mesh exists, while a selection limits only the bake.

How a triangle is textured

VRGS ranks the photographs that can see each triangle — most head-on and highest-resolution wins — rejecting back-facing and very oblique views and checking occlusion, so a photo can never texture a surface hidden behind the mesh. Triangles no photo can see fall back to the mesh's per-vertex colour, so there are no black holes.

The occlusion test is a ray cast, and on a rough surface it is deliberately forgiving: its tolerance scales with the size of the triangle being tested, so a ray that clips a neighbouring bump a few centimetres early is not mistaken for a real obstruction. Without that, whether a triangle textured at all came down to whether its ray happened to graze a nearby lump, which showed up as flat facets scattered through otherwise good texture.

If a triangle loses every candidate to the occlusion test, VRGS textures it from its best-scoring photograph anyway rather than leaving it flat. Photo content that may be slightly bled from an occluder reads as texture; a flat facet reads as a hole. Only triangles that no photograph framed at all fall back to vertex colour. The log separates the two, because they need opposite fixes:

[INFO] Texture bake: occlusion outcome: 21313 triangle(s) lost every candidate to
       the occlusion test, of which 21313 were textured anyway from their
       best-scoring photo instead of going flat; 3017 were framed by NO photo at
       all and are the only genuine vertex-colour fills

A large second number means a coverage problem — those parts of the outcrop were never photographed from a usable angle.

Every texel is then blended from the photos that see it, weighted by how well each one sees that texel — how square-on, how close, and how far from the edge of its frame. Because those weights depend on the point in space rather than on which triangle it belongs to, the mix changes smoothly across the whole surface, and the exposure/white-balance seams you would otherwise get between neighbouring triangles that chose different photos are dissolved.

Patches showing flat colour instead of photographic detail are triangles no photo could see (outside every image, or framed only at an impossibly grazing angle).

Lens distortion

Texture apply lens distortion (SfM workflow properties, default on) controls whether the solved lens model is applied when sampling a photograph.

Leave it off for any camera that de-warps in firmware — all DJI drones, most phones — because the image is already rectilinear even though it is the original file. Turn it on only for a genuinely raw lens with a solved model.

You do not have to work this out. Every bake measures it. Over roughly 4,000 triangles that two photographs both see, VRGS compares the colour each photo reports for the same point in space, with the model applied and without. The correct setting is the one where overlapping photographs agree:

[INFO] Texture bake: distortion self-check over 3866 twice-seen triangles --
       cross-photo colour disagreement with distortion ON 0.0779, OFF 0.0779
       => OFF agrees better by 0%

If the setting you used is more than 5% worse than the alternative, VRGS says so in the messages panel and tells you which way to change it.

Once the camera model is right the two readings become identical, as above, and the setting stops mattering at all — which is the real sign that the intrinsics are honest rather than that the toggle happens to be in the lucky position.

Getting this wrong looks like banding, not blur

Applying a distortion model that does not belong to the image displaces every sample radially from the centre of that photograph — nothing at the middle, a few texels at the corners. Each texel is blended from several photographs that see it at different radii, so they disagree by different amounts, and the blend turns that into smeared, evenly spaced bands across the model. It looks like a texturing bug and is actually a camera-model one.

Texture resolution attributes

Each bake writes two per-triangle attribute layers, so you can see how well resolved any part of the model is instead of guessing:

• Texture GSD (units/texel) — the real ground sample distance, in project units. It is the worse of two independent limits: what the atlas can store (set by page size and count) and what the imagery carries (range ÷ focal length, set by flying height and lens).
• Texture resolution 0-1 — the same information normalised, 1 = finest. Use this one on an unscaled mesh, where an absolute distance is meaningless. It is mapped logarithmically between the 5th and 95th percentiles: logarithmic because GSD spans orders of magnitude, and percentile-clipped so a handful of sliver triangles cannot flatten everything else onto one colour.

Colour the mesh by either layer from the Attributes node. The log also reports which limit dominates:

[INFO] Texture bake: GSD per triangle (project units/texel) p5 0.021, median
       0.043, p95 0.11 -- 62% of triangles are SOURCE-limited (photo resolution),
       the rest TEXTURE-limited (add pages or decimate)

That split is the actionable part. Source-limited means the photographs are the constraint — more pages will not help, you would need to fly lower or use a longer lens. Texture-limited means the atlas is the constraint, and more pages (or a coarser mesh) will sharpen it.

If the texture looks soft

Blending is weighted heavily toward the single best view, so it should stay sharp. If a bake looks blurred or ghosted, the usual cause is a small pose error letting two views disagree. Textures are baked with blending on, up to 3 photos per texel, at a sharpness of 4 — higher biases harder toward the one best photo, lower spreads the blend wider.

How long the bake takes, and how to stop it

A single progress bar tracks the whole bake and names the stage it is in: UV unwrap, building occlusion tree, decoding photos, scoring photos per triangle, rasterizing, finalizing. The ✕ on the progress bar cancels the bake, including part-way through the unwrap; a cancelled bake leaves the mesh's existing texture untouched.

UV unwrap is the slow stage. VRGS splits the mesh into chunks of at most 100,000 triangles and unwraps them in parallel across your CPU cores — the log records the split:

[INFO] Texture bake: 6279507 triangles in 63 unwrap chunk(s)

Without that split a large mesh is unwrapped as a single unit on one core, and the cost grows far faster than the triangle count — a multi-million triangle mesh would appear to hang for hours. Photo decoding, per-triangle photo scoring and rasterisation all run in parallel too.

Photographs that do not all fit in memory are read at full resolution a few at a time. The checks before the texture, such as the colour balance and the distortion self-check, use reduced copies, and the log says so at the start. The texture itself reads the full frames for one part of the mesh after another, using about 70 % of the memory free once the pages are allocated, so a survey far larger than memory is still sampled at full resolution. Only a part of the mesh whose photographs do not fit on their own is read reduced to fit. When every photograph fits, they are all held in memory for the whole bake.

Decimate before texturing a very dense mesh

The texture, not the geometry, carries the visible detail — so a mesh far denser than the atlas can resolve costs time and memory for nothing. At the end of a bake the log reports the budget:

[INFO] Texture bake: 21.4 texels per atlased triangle

Below about 16 texels per triangle VRGS also warns in the messages panel. A mesh of a few hundred thousand triangles textured at the same page budget gives a sharper result than a multi-million triangle one, and bakes far faster. Tick Bake onto a decimated copy in the bake dialog, or decimate the mesh first and then texture.

Showing one photo on the mesh

Use as Mesh Texture projects one photograph onto its mesh through its own solved camera, in the Vulkan 3D view, without baking anything. The mesh's own texture still shows wherever the photo does not see the surface, and the photo fades out at its frame edge. Use it to compare one photograph with the model, or to read detail the bake lost.

It is on the right-click menu of the photograph view and of a photo under the mesh's Photogrammetric Images node in the Data Tree, and a right-click on a camera marker in the 3D view shows that same menu. It is ticked while that photo is shown; choose it again to go back to the texture, or choose another photo to replace it. One photo shows at a time, for the session: the mesh's texture is not changed and nothing is saved. It is greyed out unless the photo belongs to a mesh, has a solved camera position, a camera calibration and an image file, and VRGS is rendering with Vulkan.

Apply Lens Distortion, next to it, is on by default and projects through the photo's lens model. Turn it off for photos the camera already de-warped. It applies to every photo, for the session.

---

Exporting a tiled model (SLPK)

The workflow's mesh is one object, and a photogrammetry mesh can be tens of millions of triangles with several large texture pages. That is fine for interpreting it, but heavy to stream, to open on a modest machine or to hand to someone else. Export Tiled Model (SLPK)… on the workflow's right-click menu writes the mesh as an Esri Scene Layer Package (.slpk, an I3S 1.8 integrated mesh). The package is a tree of tiles with levels of detail: distant ground is drawn from a few coarse tiles and nearby ground from the full detail.

1. Texture the mesh first (Texture Mesh from Photos…). An untextured mesh can be exported, and VRGS asks before it does: it is written in the mesh's display colour.
2. Right-click the workflow → Mesh and Texture → Export Tiled Model (SLPK)…. If the workflow has more than one mesh (for example a decimated, textured copy), pick the one to export.
3. Check the settings (below), choose Export… and pick where to save the .slpk.

The package is built in the background, with its own progress bar. The ✕ on the bar cancels the export and no file is left behind. The messages panel reports how many tiles and levels were written and the file's size. With Load the package into this project ticked (the default), the package then appears under Tiled Model in the Data Tree, in place over the mesh. See Tiled Model.

The same export is in the mesh's own Export dialog, as Esri Scene Layer Package, tiled (I3S), for any textured mesh in the project, not only one from an SfM workflow.

Setting	Default	What it does
Triangles per tile	50000	How much each tile holds, at every level. The finest tiles hold the mesh as it is, and each coarser tile is four finer ones simplified back to this budget. Fewer triangles per tile makes more, smaller tiles that stream sooner. More makes fewer, heavier ones.
Finest tiles' texture, up to	4096 px	The most texture a finest tile may carry. Each tile gets as much as its source holds (the bake's resolution, or what the photographs resolve when baking from them), up to this size.
Coarser tiles' texture	2048 px	The texture size of every tile above the finest level. Each is made from the textures of the tiles below it.
JPEG quality	85	Texture compression, 10–100.
Draco-compressed geometry	on	Adds a Draco-compressed copy of each tile's geometry, which is much smaller to stream. Both VRGS and ArcGIS use it when it is there.
Bake the tile textures from the photographs	off	Bakes each finest tile's texture straight from the solved photographs instead of cutting it from the mesh's texture. See Baking the tiles from the photographs. Only from the SfM workflow's menu.
Load the package into this project	on	Adds the package under Tiled Model once it is written.

Baking the tiles from the photographs

By default each tile's texture is cut from the mesh's own texture, the few pages Texture Mesh from Photos baked. That is quick, but a tile can never show more detail than those pages hold. On a large model spread over a handful of 4096 px pages, that is far less than the photographs resolve.

With Bake the tile textures from the photographs ticked, every finest tile is given a page of its own (up to the Finest tiles' texture size) and the texture bake fills those pages straight from the photographs:

• As detailed as the photos allow. Each tile is as dense as the photographs that frame that tile resolve its surface (a tile under a low, close pass gets more than one at the far edge of the site), so the model's total detail grows with the number of tiles rather than being capped by the mesh's texture.
• No seams between tiles. The choice of photograph, the occlusion test and the colour balance are worked out once over the whole mesh, exactly as Texture Mesh from Photos does. Neighbouring tiles therefore agree, with no jump in colour or photograph at their borders. The workflow's Texturing settings apply.
• Coarser tiles follow. Each is made from the freshly baked tiles below it.
• No second texture needed. The mesh's texture is not used at all, so an untextured mesh can be exported this way directly.

It costs a full texture bake, into many more pages than usual, so expect it to take several times as long as Texture Mesh from Photos. Both progress bars show, and the ✕ on either cancels the export. The finished tile textures are kept in a folder beside the package while it is built, and deleted afterwards. The messages panel reports how many triangles were photo-textured, and warns when a tile had to be given less detail than the photographs hold to fit its page. A larger Finest tiles' texture or fewer Triangles per tile avoids that.

The option needs the workflow's solved photographs. It is greyed out in the mesh's general Export dialog, and when the workflow has no solved photo. Do not start one while a Texture Mesh from Photos bake is running: the two share the texture-bake progress bar, and its ✕ cancels whichever registered last.

Coordinate system. The package is written in the project's coordinate system. When that has an EPSG code it is named by it (with a vertical datum's code too, for a compound CRS); otherwise its WKT is written. ArcGIS Pro opens a projected package like this in a local scene. A global scene and ArcGIS Online need a package in WGS84, which this export does not write. A project with no coordinate system can still export, after a warning: VRGS loads the package back in place, but ArcGIS cannot place it on a map.

What the warnings mean

• finest tiles' textures were reduced — a finest-level tile needed more than the Finest tiles' texture size to keep the bake's detail. Raise that, or lower Triangles per tile, to keep all of it.
• tile(s) were given less texture detail than the photographs hold — the same, when baking from the photographs.
• tile(s) are framed by no photograph — when baking from the photographs, no solved camera sees those tiles. They take the mesh's vertex colour at the coarsest density any tile was given. More photographs of that part of the site, registered in the reconstruction, are the fix.
• coarser tile(s) could not be simplified to the tile budget — texture seams pin the edges a coarse tile could otherwise remove. These tiles draw more slowly from a distance. The export is still correct.
• texture page(s) had no image file — a texture page's image is missing from the project folder and there is no copy in memory. Those triangles are grey.