📌RenderFarm Studio (RF Studio) – introducing an X-Plane 12 scenery tool
💬 0 replies
The current version is 0.11.2-beta (23 October 2026). This introduction describes the features as of 0.10.0-beta; what came after is in the release thread.
Hi all,
We are Simulators Czech, and we have been building RF Studio, a Windows desktop tool for X-Plane 12 scenery work. It reads and safely edits DSF tiles including the terrain mesh, builds overlays in a 3D editor that tries to draw the scenery the way X-Plane will, manages scenery_packs.ini with a preview and a backup, and checks airports against ICAO rules.
Since 16 October 2026 our invited testers have the second beta, 0.10.0-beta, and everything described below is in it. We would like to show what the Studio does, be upfront about what has been verified in X-Plane itself and what only by checks and tests, and above all hear what you, as scenery developers, would need from a tool like this.
The 3D editor with a whole tile of Mauritius (476,878 objects, facades and forests) taken over from our own 2 GB DSF – Port Louis with an orthophoto, objects as models and forests at True density.
Why another tool
Short of regenerating the whole tile (MeshTool, Ortho4XP), local terrain changes for X-Plane 12 usually end up in an overlay: an orthophoto is draped over the terrain, relief is faked with an OBJ model, or one of the new flatten polygons (::FLATTEN::.pol, X-Plane 12 and WED 2.7 – the Studio supports them too) moves the existing mesh points to a single height. An OBJ is not terrain, though: trees, buildings and roads still follow the original mesh, so they end up buried under the new surface or floating above it.
RF Studio therefore edits the terrain mesh inside the DSF with its own reader and writer:
Only the parts of the file that an edit touches are rewritten. A DSF loaded and saved by the Studio without edits is byte-identical to the original (for Laminar's 7z-packed DSFs: to the unpacked file) – no round trip through DSFTool text, no re-quantisation of the whole tile.
Every result is a new DSF in the Studio cache. Source files and scenery packages are never overwritten.
Each written file is re-read and verified by our own reader (an output that fails is not stored as a version), optionally also by Laminar's DSFTool as an independent check.
Editing the buildings, autogen and forests of an existing DSF works the same way: the output is a copy in which only what you edited changes.
What it does
DSF view
Header, statistics and a 3D view of the mesh for DSFs from your X-Plane installation (including Laminar's 7z-packed Global Scenery), Custom Scenery, Ortho4XP and the Studio's own outputs; comparison of two versions, a density map and an estimate of the load in X-Plane.
Defect detector: fans of thin triangles, cracks, shore steps, jagged roads, buildings standing in roads. Some of them can be repaired (local mesh rebuild, shore smoothing, levelling a road corridor).
Densified mesh places: finds spots in someone else's DSF where the mesh is much denser than its surroundings – typically inserted lidar, a flattened airport or a manual terrain edit you would never spot otherwise.
The Map view shows all DSFs of a tile, which mesh X-Plane actually uses, terrain and forests from the DSF, orthophotos and the difference between two DSF versions.
DSF view: the terrain mesh of a 2 GB DSF in 3D with textures and wireframe (Le Morne Brabant).
3D editor – overlays the way X-Plane draws them
Objects, facades, forests, draped polygons, lines, object strings, roads (snapping into junctions, Bézier curves), autogen, exclusion zones and terrain flatten in 3D over the real terrain mesh, with the X-Plane library and its 3D preview at hand.
Exclusion zones as rectangles or exact polygons (polygons need X-Plane 12; forest exclusions only support rectangles, so for forests the polygon is split into as few rectangles as possible). You choose what to exclude – objects incl. autogen, facades, forests, draped polygons, lines, strings, roads, beaches – before you draw.
OSM import from a file (.osm, .pbf, .gpkg, .shp) or from Overpass (downloaded only after you confirm), plus import of an overlay DSF or a WED project.
Export to a new overlay DSF written by our own encoder, as a WorldEditor project (earth.wed.xml) to finish in WED, or as a ready scenery package with a README and OSM attribution.
In this release the editor moved a lot closer to what you will see in the sim:
Flatten (::FLATTEN::) is no longer drawn as a flat slab. The backend finds the mesh vertices inside the polygon and the editor shows exactly the triangles X-Plane will change, including the slopes down to the vertices outside. Properties tell you how many vertices lie inside – on Laminar's sparse mesh a small polygon tends to produce a pyramid, or nothing at all.
Draped polygons, .lin lines and the draped parts of roads lie on the mesh triangles and are drawn in LAYER_GROUP order; .lin lines by their S_OFFSET layers at their real width (the red airport line is 0.47 m wide, not 12.4 m as before).
Objects are drawn by a single instance layer for the whole scene – all of them as models up to the LOD distance, including their draped part (ATTR_draped, TEXTURE_DRAPED) and their height above ground (AGL, the C_AGL comment used by Global Airports).
Forests are not drawn on water (SKIP_SURFACE water) and only up to the LOD from the .for. With True density, every tree within a circle around the camera is drawn as in X-Plane, thinned further out (the "trees 1 : N" label tells you how much).
Facades close according to RING in the .fac and use whole-metre heights like the DSF. Point autogen .agp is assembled per Laminar's spec (GROUND_PT, OBJ_GRADED, OBJ_DELTA).
Bridges: a road with a level above 0 is drawn as a deck above the terrain. The height per level is an estimate for now (see below).
Terrain flatten (::FLATTEN::) the way X-Plane applies it: the triangles that will change and the number of mesh vertices inside. In the background an L-shaped polygon exclusion – the buildings it removes are shown in red.
Existing scenery – what X-Plane really draws at the spot
The Existing scenery layer shows, read-only, the overlays and the base mesh according to scenery_packs.ini, with the exclusions of higher packs already applied. Up to the LOD the editor draws it the same way as the project: roads with bridges, textured draped polygons, lines, strings, facades, MSL and AGL objects and expanded .agp.
Airport filter as in X-Plane: a custom airport above Global Airports hides the Global Airports content for its ICAO (no double airport). A forest inside an exclusion gets a clearing instead of losing the whole forest.
Source: As X-Plane, By project or Custom – a what-if in the editor only; the ini does not change.
Tile stack: which pack provides the mesh, which meshes are covered or disabled, which overlays are drawn and what the exclusions of higher packs remove – with a link to the ini line. The same stack appears in the Map, in the X-Plane test and in the ini editor.
A click on someone else's building shows the pack and the file and offers Exclusion here, and for the project's base scenery also Take over for editing.
Existing scenery at LKPR drawn the way X-Plane draws it (Global Airports, draped polygons, roads, objects) with the tile stack; a click on a building shows where it comes from.
Editing an existing DSF – the same safe way as terrain
You can take over the buildings, autogen, forests and facades of an existing DSF into a project and change them one by one. The output is a copy of the original DSF in which only what you edited changes – everything else stays byte for byte, and no exclusion zone is needed. On Laminar's DSF around LKPR: one deleted and one lowered facade = 301 new bytes, the remaining 24.98 MB unchanged.
The take-over dialog shows the counts by kind up front with a time and memory estimate, and takes over only the kinds you tick.
The take-over remembers a fingerprint of every original. If the base DSF changes in the meantime, the Studio notices and offers Take over again without losing your edits.
Parts from the base package can be bundled into the output with their textures, or kept as a reference.
Roads of the DSF network cannot go into the copy yet. You edit them with an overlay (a roads exclusion plus a new road), and the Studio says so up front in the take-over dialog, in the export and in Validate.
A project keeps the terrain (mesh) and the scenery to edit apart. For an overlay or an orthophoto without its own mesh, the terrain is the mesh X-Plane actually draws for that tile; if the project uses a different one, the editor warns you.
Edited copies of Laminar's default scenery or of other people's packs are for your own use – to share your work, use a .rfpatch (see Sharing).
The take-over dialog: counts by kind with a time and memory estimate; roads cannot be taken over yet and the dialog says so up front.
Terrain and water – directly in the mesh
Brush, Flatten, Set height, Smooth, Ramp – raster heights and mesh vertices change together.
Mesh vertices (new tool): pick a vertex, change its height by dragging or by number, insert (Shift+click) or remove a vertex with a local re-triangulation (CDT). The height goes into every copy of the vertex across pools (fine pools with a step of about 9 mm), textures as well as water and road edges are preserved, and a vertex where a texture boundary bends is not removed. The wireframe and vertices are drawn only around the cursor, so the tool stays fast even over a dense mesh.
Water: a new water body with a local mesh rebuild along its edges, native X-Plane 12 water and a bottom depth.
Surface: the polygon edges are cut into the mesh and the inside gets a different terrain type (or water becomes land).
Insert detailed DEM from a GeoTIFF or a mosaic: vertices are added until the mesh fits the DEM within your tolerance (at most 100 km² per operation). The textures of the original triangles can be kept, masks leave airports and roads untouched, and water is never changed.
Merge with another DSF of the same tile inside an area, and Simplify mesh with a guarded height deviation.
The After edit preview shows the new mesh in the main 3D view, with the entities standing on it, before anything is written, plus a BEFORE / AFTER slider.
Heights in the editor (distant terrain, height at a point, "From terrain") come from the mesh as X-Plane draws it, not from the elevation raster. After a DEM insert, distant terrain computed from the raster used to be off from the mesh by a median of 2–7 m (up to 52 m); now it matches (1,042 points in 4 DSFs: median 0.000 m, max 0.02 m).
The new Mesh vertices tool: wireframe and vertices only around the cursor, vertices with a changed height and a newly inserted vertex, with the list of steps and the change preview summary on the right.
Insert detailed DEM (the sample hill from the built-in guide): the mesh before and after with the BEFORE / AFTER slider.
X-Plane scenery – a scenery_packs.ini editor (new)
The list in X-Plane's priority order (numbers as in Log.txt, 0 = highest), checkboxes, drag and drop, Alt+↑/↓, filters (pack type, tile, ZZ_ / YY_ prefixes), bulk enable and disable. Folders missing from the ini are listed at the top.
Every change goes into a draft first. The Preview shows the byte and text diff and the affected tiles – the winning mesh before and after, and the overlays drawn.
Writing only after you confirm: a backup into a folder in the X-Plane installation, an atomic write checked by sha256 against the preview, and a write log. Unchanged lines, line endings, the BOM and unknown lines stay byte-identical. For the first 60 s after X-Plane starts (it rewrites the ini on start-up) writing is blocked, and the Studio never closes X-Plane.
Checks with a link to the line and a fix you can add to the draft: several enabled meshes for one tile, an overlay with exclusions above Global Airports, a custom airport below Global Airports, a missing folder or a broken link, a duplicate line, two lines reaching the same data through a junction, an archive or a .lnk in Custom Scenery, a tab or cp1250 in the ini and more.
Backups with restore through the preview, profiles (saved sets of enabled packs), a recommended order as a suggestion, a Tile mesh from… quick action, and pack details with a minimap of the pack's tiles on an OSM base map.
The whole Studio – library, Existing scenery, the X-Plane test and the airport checks – reads the ini with one parser and numbers priorities the same way.
X-Plane scenery: scenery_packs.ini in X-Plane's priority order, a change draft and pack details with a tile minimap.
The preview before the ini is written: the byte diff and the affected tiles with the winning mesh before and after. Nothing is written until you confirm, and a backup comes first.
Airports
Runway, taxiway and apron slopes checked against ICAO Annex 14 limits; bumps (30 m straightedge) against our own heuristic limits, since ICAO has none – for judging the look in the sim, not for certification.
Flattening an airport from apt.dat (runway profiles, smoothed paved areas, blended edges) – one airport or many at once.
ICAO Annex 14 obstacle limitation surfaces (tables of the 8th edition, 2018) drawn in 3D. Terrain, objects, forests, buildings and autogen that penetrate them are listed with GPS coordinates – from the base DSF, overlays and the project (obstacle heights partly estimated). Terrain above the surfaces can be lowered with a safety margin.
ICAO Annex 14 obstacle limitation surfaces at LKPR, penetrating obstacles in red.
Orthophotos, Ortho4XP and beaches
From a GeoTIFF or an image: textures draped over the terrain (variant A, LAYER_GROUP beaches 2) or baked into the mesh (variant B).
The editor places orthophotos by the photo coordinates at each corner, as X-Plane does, and an import from a DSF or WED keeps the original UV of every vertex.
Ortho4XP tiles are recognised, and when the mesh is edited, new triangles get the right photo texture and coordinates.
Beaches can be added, retyped or removed along the shore.
Test in X-Plane
Test in X-Plane copies the result as a ZZZ_RFS_… test pack into Custom Scenery and inserts it into the ini at a recommended place – after a preview of the exact change and a backup; it shows the tile stack too. End test restores the ini to its previous state and moves the pack to a bin folder (nothing is deleted).
X-Plane screenshots: with XPPython3 and a small Studio plugin (installed only after you confirm), the Studio sets the camera of a running X-Plane, the time and clear weather, and saves a screenshot. The reliable mode is an AFTER shot; the automatic BEFORE/AFTER mode reloads the scenery, which hung X-Plane 12.4.4 in our test.
A screenshot taken by the Studio in X-Plane 12.4.4 (AFTER shot): an edited copy of existing scenery near LKPR.
Sharing
Projects as .rfproj files (including your own parts), and small .rfpatch patches with just your edits instead of a whole DSF – the recipient replays them on their own DSF and, on the same base, gets a byte-identical result.
What is verified in X-Plane – and what is not yet
We prefer to be explicit about this. "Checks" means: our reader and DSFTool read the file back, the mesh has no cracks, triangle orientation and vertex copies are consistent, and the result matches our tests. That does not prove how it looks in the sim.
Feature
How it has been verified
Overlays exported by the editor
visually in X-Plane 12
Edited Laminar DSFs; terrain height tools (objects, forests and roads stand on the new mesh); Insert detailed DEM; orthophoto variants A and B
visually in X-Plane 12
Polygon exclusions for objects, autogen, facades and forests (a forest is clipped at the edge)
X-Plane 12.4.4
::FLATTEN:: – a single polygon on Laminar's mesh and on our own, with and without an airport filter
X-Plane 12.4.4
Copy of an existing DSF with edited buildings (LKPR)
X-Plane 12.4.4
X-Plane screenshots in AFTER mode
X-Plane 12.4.4 (the BEFORE/AFTER mode hung X-Plane in our test)
Water, Surface, Merge, Simplify, beaches and the new Mesh vertices tool
Polygon exclusions for roads, lines, strings, draped polygons and beaches
file check only
scenery_packs.ini editor
byte-exact write tests (CRLF, BOM, tabs, cp1250, a copy of a real ini); how X-Plane treats a newly added folder, a duplicate line and Global Airports written as a path has not been tried in the sim yet
WED export
read back by the Studio, not yet opened in WED
Ortho4XP tiles
only a synthetic tile in the 1.3x format, not a real one yet
.rfpatch
byte identity on the same base verified for heights, raster, delete, add, retexture, brush and DEM; not yet for water, airport and road edits
And where the editor still only estimates what X-Plane will draw:
Bridge height: 5 m per road level is our estimate. The DSF carries only the level number and X-Plane computes the deck height itself; on flat ground level 1 most likely gives a higher deck with piers. The Studio writes the same into the DSF as WED does, so the estimate only affects the drawing in the editor.
Overlapping flatten polygons with different heights: which one wins is not documented by Laminar, and WED reorders flatten polygons by height when it writes the DSF. The Studio warns about such an overlap in Validate and before a WED export; the safest choice is not to overlap flattens of different heights.
Autogen assembly (.ags, .agb, .agp) and the trees in .agp follow the spec, but we do not have side-by-side Studio × X-Plane screenshots yet.
Feedback from people who know these areas well – WED and Ortho4XP users especially – is very welcome.
Under the hood
The backend is Python, the UI is React + three.js in a WebView2 window. Editor projects are SQLite files with an R*Tree index; reading large projects, placing trees and building the BVH trees for picking run in Web Workers, and terrain windows are computed by helper processes (up to 4) with a disk cache. The DSF reader and writer are our own; DSFTool is only an optional independent check. The full suite of more than 2,300 automated tests passed before the release.
Large projects: a whole-tile project opens in parts and there is no longer a cap on the number of entities (we tried 1.43 million) – the editor only warns based on free memory. Edits recompute only the entities that changed, and no request to the backend is larger than 64 MB – large changes are sent in parts of at most 32 MB.
Numbers from measurements
Measured on 16 October 2026: i5-11600K, 32 GB RAM, Radeon RX 9070 XT, Windows 11, Microsoft Edge 156 with the same Chromium engine as WebView2 in the app, a 1600 × 900 window (3D canvas 940 × 712 px), 75 Hz monitor. Project: a whole tile of Mauritius, 476,878 entities (362,478 objects, 94,974 forests, 19,425 facades), base DSF 2 GB. The "Before" column is the build of 14 October; where another date is given, it is the state on that day.
opens in 8.4–8.6 s (13.2 s right after a backend restart)
Take-over state after saving
17.9 s (12 Oct)
0.25 s (2.0 s after start)
Validate the whole project
8.1 s (12 Oct)
0.8 s (12.9 s after start)
Saving a change of all 362,478 objects
error 413 (12 Oct)
25 s, 5 parts of ≤ 32 MB
Ray pick over 500,000 triangles (median)
22–40 ms (13 Oct)
0.02–0.15 ms (BVH in a Web Worker)
All 460 terrain windows of the island
128 s (1 process)
52 s (4 processes)
Camera jump to a new place / from the disk cache
–
2.0–2.6 s / 0.7–1.05 s
What the measurements told us:
The frame is now limited by the CPU, not the graphics card: about 11 µs per draw call in three.js plus the WebGL calls. On Mauritius the GPU has 4–10× headroom; an orthophoto adds 1–1.4 ms of GPU time, a 1.5× display scale (2.25× the pixels) with MSAA only 0.2 ms. The Edge GPU process uses 0.46–0.68 GB of VRAM, of which OBJ textures take 64–75 MB.
Where the ceiling is: a synthetic stress project with 1.07 million entities, whose forests and facades are about 4–5× denser than on a real Czech tile (+50+015), holds at LOD 2.5 km, but at LOD 5 km it stalls for up to 4.5 s and the browser heap grows to 10.4 GB. That is the next piece of work (see What comes next).
We measured in Edge, not in the exe itself, and only on a strong graphics card; weaker GPUs have not been measured yet.
What it does not do
It does not overwrite source files. It writes into the X-Plane installation only in the X-Plane scenery view (scenery_packs.ini), in Test in X-Plane and for screenshots – always after you confirm, with a backup and without deleting anything.
It does not download data – you supply DEMs, orthophotos and OSM files yourself. The only exceptions are OSM base map tiles and Overpass on request.
It does not generate whole tiles: one DEM insert handles at most 100 km². A whole region belongs in a scenery generator.
It does not start X-Plane on its own – only for screenshots, on your request, and it never closes an X-Plane it did not start.
It does not judge how things look in the simulator: it checks geometry and file structure; the final look is up to you in X-Plane.
Not yet: roads in the copy of an existing DSF (overlay only), moving a mesh vertex sideways, and a soft edge for an orthophoto baked into the mesh (variant B).
What comes next
Performance on dense whole tiles at LOD 5 km: fewer draw calls (merged layers, trees through an atlas), writing the merged layer and the BVH copy in a Web Worker, smaller geometry. The goal: no stall above 100 ms and a heap below 3 GB.
Tests in X-Plane itself: bridge height by road type and level instead of the 5 m estimate, the order of overlapping flattens, the orientation of .agp and its trees – with side-by-side Studio × X-Plane screenshots.
Measurements and default settings for weaker graphics cards.
We follow Laminar's announced next-generation scenery and will adapt once the formats are public.
The beta
0.10.0-beta is for invited testers, so there is no download link here. If you would like to try it or have ideas, write to RFstudio@simulators.cz.
Free for non-commercial use (closed-source freeware, EULA version 1.1): sceneries you make with it may be shared for free; selling them needs our prior written consent. Please do not pass the beta on.
64-bit Windows 11 (Windows 10 should work but has not been tried yet) with the Microsoft Edge WebView2 Runtime. The installer (about 180 MB) is not code-signed yet, so SmartScreen will warn.
The UI, backend messages, F1 help and the full manual are in English and Czech.
Report a problem (Help, F1) creates a zip with your description, logs and settings; the home folder, user name and computer name are replaced by placeholders and you see the exact contents before saving – nothing is sent automatically.
We are most interested in which DSF and scenery_packs.ini workflows are missing from your toolset today and how you test your scenery in X-Plane.
Hi all,
We are Simulators Czech, and we have been building RF Studio, a Windows desktop tool for X-Plane 12 scenery work. It reads and safely edits DSF tiles including the terrain mesh, builds overlays in a 3D editor that tries to draw the scenery the way X-Plane will, manages
scenery_packs.iniwith a preview and a backup, and checks airports against ICAO rules.Since 16 October 2026 our invited testers have the second beta, 0.10.0-beta, and everything described below is in it. We would like to show what the Studio does, be upfront about what has been verified in X-Plane itself and what only by checks and tests, and above all hear what you, as scenery developers, would need from a tool like this.
Why another tool
Short of regenerating the whole tile (MeshTool, Ortho4XP), local terrain changes for X-Plane 12 usually end up in an overlay: an orthophoto is draped over the terrain, relief is faked with an OBJ model, or one of the new flatten polygons (
::FLATTEN::.pol, X-Plane 12 and WED 2.7 – the Studio supports them too) moves the existing mesh points to a single height. An OBJ is not terrain, though: trees, buildings and roads still follow the original mesh, so they end up buried under the new surface or floating above it.RF Studio therefore edits the terrain mesh inside the DSF with its own reader and writer:
What it does
DSF view
3D editor – overlays the way X-Plane draws them
In this release the editor moved a lot closer to what you will see in the sim:
::FLATTEN::) is no longer drawn as a flat slab. The backend finds the mesh vertices inside the polygon and the editor shows exactly the triangles X-Plane will change, including the slopes down to the vertices outside. Properties tell you how many vertices lie inside – on Laminar's sparse mesh a small polygon tends to produce a pyramid, or nothing at all..linlines and the draped parts of roads lie on the mesh triangles and are drawn inLAYER_GROUPorder;.linlines by theirS_OFFSETlayers at their real width (the red airport line is 0.47 m wide, not 12.4 m as before).ATTR_draped,TEXTURE_DRAPED) and their height above ground (AGL, theC_AGLcomment used by Global Airports).SKIP_SURFACE water) and only up to the LOD from the.for. With True density, every tree within a circle around the camera is drawn as in X-Plane, thinned further out (the "trees 1 : N" label tells you how much).RINGin the.facand use whole-metre heights like the DSF. Point autogen.agpis assembled per Laminar's spec (GROUND_PT,OBJ_GRADED,OBJ_DELTA).Existing scenery – what X-Plane really draws at the spot
scenery_packs.ini, with the exclusions of higher packs already applied. Up to the LOD the editor draws it the same way as the project: roads with bridges, textured draped polygons, lines, strings, facades, MSL and AGL objects and expanded.agp.Editing an existing DSF – the same safe way as terrain
You can take over the buildings, autogen, forests and facades of an existing DSF into a project and change them one by one. The output is a copy of the original DSF in which only what you edited changes – everything else stays byte for byte, and no exclusion zone is needed. On Laminar's DSF around LKPR: one deleted and one lowered facade = 301 new bytes, the remaining 24.98 MB unchanged.
Edited copies of Laminar's default scenery or of other people's packs are for your own use – to share your work, use a
.rfpatch(see Sharing).Terrain and water – directly in the mesh
X-Plane scenery – a scenery_packs.ini editor (new)
Airports
Orthophotos, Ortho4XP and beaches
LAYER_GROUP beaches 2) or baked into the mesh (variant B).Test in X-Plane
ZZZ_RFS_…test pack into Custom Scenery and inserts it into the ini at a recommended place – after a preview of the exact change and a backup; it shows the tile stack too. End test restores the ini to its previous state and moves the pack to a bin folder (nothing is deleted).Sharing
.rfprojfiles (including your own parts), and small.rfpatchpatches with just your edits instead of a whole DSF – the recipient replays them on their own DSF and, on the same base, gets a byte-identical result.What is verified in X-Plane – and what is not yet
We prefer to be explicit about this. "Checks" means: our reader and DSFTool read the file back, the mesh has no cracks, triangle orientation and vertex copies are consistent, and the result matches our tests. That does not prove how it looks in the sim.
::FLATTEN::– a single polygon on Laminar's mesh and on our own, with and without an airport filter.rfpatchAnd where the editor still only estimates what X-Plane will draw:
.ags,.agb,.agp) and the trees in.agpfollow the spec, but we do not have side-by-side Studio × X-Plane screenshots yet.Feedback from people who know these areas well – WED and Ortho4XP users especially – is very welcome.
Under the hood
The backend is Python, the UI is React + three.js in a WebView2 window. Editor projects are SQLite files with an R*Tree index; reading large projects, placing trees and building the BVH trees for picking run in Web Workers, and terrain windows are computed by helper processes (up to 4) with a disk cache. The DSF reader and writer are our own; DSFTool is only an optional independent check. The full suite of more than 2,300 automated tests passed before the release.
Large projects: a whole-tile project opens in parts and there is no longer a cap on the number of entities (we tried 1.43 million) – the editor only warns based on free memory. Edits recompute only the entities that changed, and no request to the backend is larger than 64 MB – large changes are sent in parts of at most 32 MB.
Numbers from measurements
Measured on 16 October 2026: i5-11600K, 32 GB RAM, Radeon RX 9070 XT, Windows 11, Microsoft Edge 156 with the same Chromium engine as WebView2 in the app, a 1600 × 900 window (3D canvas 940 × 712 px), 75 Hz monitor. Project: a whole tile of Mauritius, 476,878 entities (362,478 objects, 94,974 forests, 19,425 facades), base DSF 2 GB. The "Before" column is the build of 14 October; where another date is given, it is the state on that day.
What the measurements told us:
What it does not do
scenery_packs.ini), in Test in X-Plane and for screenshots – always after you confirm, with a backup and without deleting anything.What comes next
.agpand its trees – with side-by-side Studio × X-Plane screenshots.The beta
We are most interested in which DSF and
scenery_packs.iniworkflows are missing from your toolset today and how you test your scenery in X-Plane.Thanks for reading!
Simulators Czech