X-Plane smoothness depends mainly on the number of triangles and vertices in the DSF mesh (graphics memory and tile load time) and, for vegetation, on the number of instances (area × density). Every edit that densifies the mesh (DEM insertion, cutting the mesh with orthophoto B, inserted edges, airport flattening) makes the DSF bigger.
Performance estimate in the Studio
DSF › Overview › Load statistics – below the statistics is the X-Plane performance estimate: the category OK / Caution / Heavy, an estimate of graphics memory for the geometry and of the DSF load time.
In the editor, edit previews (DEM insertion, simplification, Terrain & water including the Mesh vertices edit, Beaches and orthophoto B) show the Performance impact of the edit: counts before → after and the category change.
Editor › Validate – below the problems is the Estimated overlay load in X-Plane for the project entities (from the saved version and the unsaved changes): objects, polygons (facades and wall length, forests and their area, draped polygons, lines, autogen), autogen (.ags / .agb with their area and .agp points – X-Plane expands them into more buildings, there is no measured per-item cost), roads and their length, exclusions. Every row shows the change in % against the project base DSF. Trees (instances) = area × density / SPACING² from the .for in the X-Plane library (for line fill perimeter / SPACING, for points one tree per point), with the share against measured reference tiles +50+015; forests without a known SPACING are not counted. Exclusions remove content of the base – no saving is computed. No MB or seconds are given without a measured source.
The estimate is rough and based on measured tiles: a DSF with 20.6 million triangles ran smoothly in X-Plane (still OK), a DSF with 71.6 million triangles and 70.1 million vertices took 195 s to load and overflowed graphics memory (Heavy). In between is Caution. For objects and polygons there is no measured per-item cost, so only the change in percent is shown. The expandable part Where the numbers come from (rough estimate) of every estimate lists the sources.
Recommendations
Large areas belong to a generator. The Studio is for local edits. One DEM insert operation handles at most 100 km² (over 40 km² the Studio warns); for a larger territory or when millions of points would be added it is better to feed the data (DEM, OSM, orthophoto) to a scenery generator such as RenderFarm and regenerate the tile – a generator keeps a point budget and handles roads, airports and shores properly.
Tolerance, not maximum. For DEM insertion and flattening a vertical error of about 0.2 m is usually enough; a smaller tolerance adds many points with little visible benefit.
TRNS transitions. The "drop" option of DEM insertion and simplification removes many overlay triangles (orthophoto B removes them under the photo by itself); the look of texture transitions changes though – check in X-Plane.
Simplification helps on sea and flat areas; points that exist only because of texture borders can be removed only a little.
Orthophoto: choose the ZL by the real resolution of the source (the Studio proposes it). Each higher ZL is about four times more data. A draped orthophoto (variant A) loaded several times slower per triangle than the mesh in a test.
Check the density in DSF › Density and with the defect detector (fans).
Performance of the Studio itself
Reading the header and the statistics of a whole DSF takes seconds even for a 2 GB file. The 3D window reads only the pools in the window (up to 0.05°).
DSF terrain window cache (dsf_okna folder in the cache): the DSF command index, the computed terrain windows and the distant-view grid are stored on disk. After a new start of the Studio or when the camera returns to the same place they are not computed again: the first window of a new place in a 2 GB DSF appears in about 1–2 s instead of 4–11 s and a window already computed in about 5–15 ms instead of 0.3–1 s. The very first opening of a new or rewritten DSF is not faster – it takes a moment longer (the cache is only being filled and written to disk). When RenderFarm (or another program) rewrites the DSF, the Studio recognises it by the file size and modification time, deletes the old cache of that DSF and computes the windows again. The folder has its own limit of 5 GB (the least recently used files are removed automatically); Settings › Working folder (outputs and cache) shows how much it takes. You can delete it at any time (when the Studio is not running or loading anything) – the windows are then simply computed again.
Parallel terrain loading: terrain windows that are not in the cache yet are computed by helper processes of the Studio – up to 4 at a time, only 2 while RenderFarm runs or free memory is low – and the editor requests them in parallel. A camera jump to a new place (9 windows) in a 2 GB DSF thus loads about twice as fast as one by one, e.g. in 1.7 s instead of 3.6 s; the first jump after the Studio starts, while the processes are still starting, takes about 3–5 s. The processes start only with the first window that has to be computed (that one is computed at once, without waiting for them) and end by themselves after 10 minutes of inactivity. Each keeps the index of the open DSF in memory (about 80–190 MB for a 2 GB DSF, released after 2 minutes of inactivity), together about 0.5–1.5 GB of extra memory while you work (about 0.5 GB for the 2 GB DSF of Mauritius, about 1.1–1.4 GB for the denser DSF +50+015). If the processes do not start or one of them crashes, the Studio computes the windows without them (slower) and writes it to the log – there is nothing you need to do.
Heavy jobs (defect detector over a whole tile, density, writing large DSFs, precomputes) run in the background and wait while RenderFarm runs or free memory is below the minimum from Settings (3 GB by default).
The defect detector and density run block by block with memory up to ~1 GB even for a 2 GB DSF; the detector over a whole large tile takes tens of minutes and an interrupted job continues from the last block.
The editor loads a window up to 0.05° whole; a larger window in pieces around the camera, 2–4 pieces in parallel.
A large project (a whole tile) is opened in parts: first the project head, then the entities and their provenance in parts. The parts are read, parsed and prepared by background data threads (Web Worker; the entities and their provenance in parallel); the editor receives the entities and provenance in small batches (2,000 at a time) and stays responsive between them. The data thread also prepares helper columns of the project (kind, first point, window piece and an id index), so after opening the editor no longer splits the entities into window pieces itself: for Mauritius (477 thousand entities) it takes 10–30 ms instead of 0.5–0.9 s, for the test project three times Mauritius (1.43 million entities) 20–30 ms instead of 1.4–2.7 s. The longest browser freeze until the first image dropped from 0.35–0.5 s to 0.07–0.16 s for Mauritius and from 0.55–0.6 s to 0.1–0.15 s for the triple, in the first 15 s after opening from 0.9–1.1 s to 0.55–0.65 s for Mauritius and from 1.7–2.1 s to 0.65–0.95 s for the triple (the rest is mostly the browser's memory clean-up and building the 3D scene). The remaining longest freeze until the first image, about 0.1 s, is a one-off growth of the entity provenance dictionary for the triple (1.43 million items – the browser rebuilds it at once when it grows) and building the project and the first drawing for Mauritius. The time to the first image is the same for Mauritius (3.5–4.3 s) and shorter for the triple (about 9 s instead of 9–13 s). Even a project above 1.1 million entities (more than 512 MB of data) opens, which did not open at all before. When the data thread does not start, the editor reads the project in parts itself as before.
The number of project entities has no limit (it used to be 2,000,000). When the project is large for the free memory, the 3D view shows a yellow Large project bar with an estimate: the core (check and export read the project whole) needs about 2.9 kB of RAM per entity, the editor in the browser about 576 B per entity and the browser gives it at most about 4 GB. Nothing is blocked; Hide hides the bar until the project is opened again – it comes back earlier only when the project grows by at least a tenth (a large import or take-over). The import preview and the take-over dialog warn beforehand.
Edits in a large project recalculate only the changed entities in the 3D view: an edit, add, delete, Undo and Redo move the split of entities into window pieces by the changes only (about 5 ms instead of 120–200 ms per step for Mauritius), Save and the running draft build the changes without going through the whole project (before up to about 0.1–0.25 s after an add or delete) and dragging an entity changes only the window piece it lies in (before every mouse move split all entities again, about 0.1 s). The Outliner list, the minimap, the counts in the project Properties, the lists of exclusions and terrain flattening and looking up an entity by id are also only moved by the changed entities after a change (helper columns of the project in typed arrays – about 17–20 MB for Mauritius, about 56–66 MB for the triple; the browser memory after opening is the same as before). Deleting hundreds of scattered entities at once (a rectangle selection and Delete) and its Undo also move the Outliner by the changed entities only: 250 entities take about 1 ms instead of 16–24 ms for Mauritius and about 3–5 ms instead of 80 ms for the triple. A large selection (Ctrl+A) is also kept by the helper columns: after the first use the selected entities for the selection panel and the handles are read in about 3–8 ms instead of 30–47 ms for Mauritius (about 10–25 ms instead of 100–125 ms for the triple), and Ctrl+click or deleting part of such a selection takes about 0.3–0.45 s instead of 0.55–0.85 s (0.8–1.4 s instead of 1.7–2.5 s for the triple). The data part of editing one entity thus takes about 1 ms instead of about 20–25 ms for Mauritius (about 3 ms instead of 23 ms for the triple); the rest of an edit is drawing the changed part of the 3D scene.
The editor clips a draped polygon (.pol) by the triangles of the loaded terrain mesh so it lies on the terrain like in X-Plane: over a dense mesh (RenderFarm, Ortho4XP) it therefore has more triangles. A very large polygon (over ~400 thousand checked mesh triangles) and places where the mesh is not loaded yet are subdivided as before.
Forests and facades near the camera are drawn without a separate component per entity: areas, outlines and facades are written into the merged layers by ranges (a change of one entity rewrites only its range, not the whole cell), tree placement and the triangulation of forest areas run in a background thread (the area heights are filled in pieces, forests are handed over for placement in batches from the camera outwards – also after opening a large project) and facades are built in bulk, in batches from the camera outwards. The number of trees in the scene costs the most: trees are drawn only up to the forest LOD from the .for (grass 2 km) and in the whole scene at most the Scene tree limit (250,000 by default, distant forests are thinned more; Mauritius with a LOD of 2.5 km used to have over 1.5 million trees); True density draws every tree within a circle around the camera (300 m, smaller for dense forest and grass; up to about 40 thousand instances per forest – the limit can be changed in Settings › Performance, 10,000–300,000); on weaker graphics lower the limit or turn True density off (the trees 1 : N label then shows more thinning). Existing scenery in 3D additionally draws roads, textured draped polygons, lines and split point autogen .agp up to the LOD like the project – in a dense city (0.1° window) these are thousands of items; a shorter LOD or turning 3D models off helps. Editing the project (move, delete, Undo) does not rebuild the layer: the read-only entities stay the same, “already in the project” is recomputed only around the changed entities and the outlines are draped on the terrain only once (Mauritius, 0.1° window at Port Louis: a commit with Existing scenery in 3D takes about 0.6 s instead of 1.8–2.1 s, about 0.5 s without the layer; measured in a browser without a graphics card).
The editor loads each object model (.obj) only once: all of its occurrences in the scene (project objects, facade objects, composite autogen and Existing scenery) share one mesh, texture and set of materials on the graphics card. A model leaves memory about 15 s after its last occurrence stops being drawn (so a short camera move does not load it again).
Objects are drawn as one instance layer for the whole scene: each model part is one graphics card draw call however many times it occurs (before, separately in every piece of the window). Up to the LOD distance all objects are models (before, even near houses above a budget of 3 million triangles were drawn only as dots), beyond it points (autogen and facade objects nothing). The graphics card keeps the exact LOD limit; after the camera stops, the editor only swaps the objects that crossed it (an object that enters the LOD during a fast approach is a point until then). The graphics card drops occurrences outside the view and beyond the LOD right at the start, without computing their vertices. Editing one object rewrites only its entry in the layer. On a weak graphics card a smaller LOD helps, or the Object triangle budget (off by default): then only the nearest objects are models while they fit into the budget, points beyond (autogen and facade objects nothing).
The cache grows and the Studio itself deletes only the deletable map tiles from it (by the Limit) and the least recently used DSF terrain windows (own limit of 5 GB). To bin… in History does not free space – the bin is the dsf_upravy\_kos folder in the cache on the same disk and the Studio never empties it. Free space by hand in File Explorer: delete the bin and the exports (editor_export) and orthophotos (orto) you no longer use, see The disk is filling up.
Based on the RF Studio manual (F1 › Manual, version 0.11.2-beta). Post your questions and experience in this thread.
What costs performance in X-Plane
X-Plane smoothness depends mainly on the number of triangles and vertices in the DSF mesh (graphics memory and tile load time) and, for vegetation, on the number of instances (area × density). Every edit that densifies the mesh (DEM insertion, cutting the mesh with orthophoto B, inserted edges, airport flattening) makes the DSF bigger.
Performance estimate in the Studio
.ags/.agbwith their area and.agppoints – X-Plane expands them into more buildings, there is no measured per-item cost), roads and their length, exclusions. Every row shows the change in % against the project base DSF. Trees (instances) = area × density / SPACING² from the.forin the X-Plane library (for line fill perimeter / SPACING, for points one tree per point), with the share against measured reference tiles +50+015; forests without a known SPACING are not counted. Exclusions remove content of the base – no saving is computed. No MB or seconds are given without a measured source.The estimate is rough and based on measured tiles: a DSF with 20.6 million triangles ran smoothly in X-Plane (still OK), a DSF with 71.6 million triangles and 70.1 million vertices took 195 s to load and overflowed graphics memory (Heavy). In between is Caution. For objects and polygons there is no measured per-item cost, so only the change in percent is shown. The expandable part Where the numbers come from (rough estimate) of every estimate lists the sources.
Recommendations
Performance of the Studio itself
dsf_oknafolder in the cache): the DSF command index, the computed terrain windows and the distant-view grid are stored on disk. After a new start of the Studio or when the camera returns to the same place they are not computed again: the first window of a new place in a 2 GB DSF appears in about 1–2 s instead of 4–11 s and a window already computed in about 5–15 ms instead of 0.3–1 s. The very first opening of a new or rewritten DSF is not faster – it takes a moment longer (the cache is only being filled and written to disk). When RenderFarm (or another program) rewrites the DSF, the Studio recognises it by the file size and modification time, deletes the old cache of that DSF and computes the windows again. The folder has its own limit of 5 GB (the least recently used files are removed automatically); Settings › Working folder (outputs and cache) shows how much it takes. You can delete it at any time (when the Studio is not running or loading anything) – the windows are then simply computed again..pol) by the triangles of the loaded terrain mesh so it lies on the terrain like in X-Plane: over a dense mesh (RenderFarm, Ortho4XP) it therefore has more triangles. A very large polygon (over ~400 thousand checked mesh triangles) and places where the mesh is not loaded yet are subdivided as before..for(grass 2 km) and in the whole scene at most the Scene tree limit (250,000 by default, distant forests are thinned more; Mauritius with a LOD of 2.5 km used to have over 1.5 million trees); True density draws every tree within a circle around the camera (300 m, smaller for dense forest and grass; up to about 40 thousand instances per forest – the limit can be changed in Settings › Performance, 10,000–300,000); on weaker graphics lower the limit or turn True density off (the trees 1 : N label then shows more thinning). Existing scenery in 3D additionally draws roads, textured draped polygons, lines and split point autogen.agpup to the LOD like the project – in a dense city (0.1° window) these are thousands of items; a shorter LOD or turning 3D models off helps. Editing the project (move, delete, Undo) does not rebuild the layer: the read-only entities stay the same, “already in the project” is recomputed only around the changed entities and the outlines are draped on the terrain only once (Mauritius, 0.1° window at Port Louis: a commit with Existing scenery in 3D takes about 0.6 s instead of 1.8–2.1 s, about 0.5 s without the layer; measured in a browser without a graphics card)..obj) only once: all of its occurrences in the scene (project objects, facade objects, composite autogen and Existing scenery) share one mesh, texture and set of materials on the graphics card. A model leaves memory about 15 s after its last occurrence stops being drawn (so a short camera move does not load it again).dsf_upravy\_kosfolder in the cache on the same disk and the Studio never empties it. Free space by hand in File Explorer: delete the bin and the exports (editor_export) and orthophotos (orto) you no longer use, see The disk is filling up.Based on the RF Studio manual (F1 › Manual, version 0.11.2-beta). Post your questions and experience in this thread.