Install and first launch
System requirements, the installer, what happens on first launch, where worlds and caches live, and how to read the terrain capability status.
Dayside is a Windows desktop app. It installs from a single MSI, brings everything it needs with it, and runs entirely on your machine. There is nothing to sign in to and no web version.
What you need#
| OS | Windows 10 or 11, 64-bit |
| GPU | NVIDIA. Needed only for Generate; painting, rendering and export do not use it. |
| Memory | 16 GB RAM. 32 GB for 32K exports. |
| Disk | 20 GB, plus room for your worlds. |
The GPU requirement applies to two things only: terrain synthesis (Generate, Enhance world terrain) and the optional AI colour pass (Enhance section colour). Both take the native CUDA path, so they need an NVIDIA card.
Everything else is CPU work: painting, stamps, the coastline lasso, the colour render (Acquire), the globe colour pass, and every export. If you bring your own already-realistic heightmap, you can run the entire colour and export loop with no capable GPU at all. When no validated generation backend is present the app says so and tells you that import remains available; it does not silently fall back to something slower.
Install the MSI#
- Run the installer and accept the elevation prompt. It installs per machine.
- Launch from the Start menu shortcut.
There is nothing else to fetch. The installed tree carries its own Python runtime under runtime\python, the server and engine under runtime\site-packages, the interface under resources\ui, and a pinned WebView2 runtime under runtime\webview2, so the app does not depend on whatever version of Edge WebView2 the machine happens to have.
The 90 m terrain model ships inside the installation as a verified depot of about 1.1 GB. On a retail install you never download or install it by hand: if it goes missing, the fix the app offers is to repair or reinstall.
If the app ever reports that a packaged component is missing or has changed, use your package manager's Repair action before anything else. The launcher verifies the installed policy files against identities baked into the binary and refuses to start a mismatched tree, so a partial or edited installation fails loudly rather than running in an unknown state.
First launch#
The launcher starts the local engine, then opens the worlds picker. Only one copy of the app runs at a time; a second launch hands focus to the first.
On a machine with no worlds yet, the picker is replaced by a first-run panel: a NO WORLDS YET chip, buttons for Import a world and New world, and a status line reading FIRST RUN · THE ENGINE IS HEALTHY AND WAITING. That last line is the useful one. It tells you the engine came up.
If the engine has not come up, you get an ENGINE OFFLINE panel with a Retry connection button instead, and the picker retries by itself every 5 seconds. Your worlds are untouched in this state; nothing can render until the engine is back.
Click New world and the setup wizard opens. Its header carries a capability chip that probes this machine:
Checking this PC…while the probe runs.- This PC can import, colour and export when the base capability is present.
- Some components need attention otherwise, with a Check again button and whatever repair actions the engine declares.
That chip covers the base loop. It does not promise that terrain generation is ready, which is a separate readout.
Check the terrain capability status#
Open a section and click Generate. The dialog's footer, on the left, states the generation backend:
- Native NVIDIA CUDA ready means terrain synthesis will run on the GPU. The Generate button carries a lightning icon.
- Anything else means no validated backend was found. The message names the reason, the button carries a CPU icon, and the dialog reminds you that import remains available.
Above the footer, one capability message covers the components:
| State | What it says | What you do |
|---|---|---|
| Provisioning | Installing terrain-diffusion… or Downloading the <model> model…, with a stage and a percentage | Wait. |
| Model missing | The engine's own message, then a fix line | On a retail install the fix reads Repair or reinstall Dayside to restore the packaged model. |
| Runtime missing | The engine's own message, then a fix line | On a retail install the fix reads Repair or reinstall Dayside to restore the packaged runtime. |
| Ready | Nothing. The message disappears entirely. | Nothing. |
A retail install shows no Install or Download buttons; provisioning is the installer's job there. Those buttons only appear on a developer install, which is also where the 30 m model and Base-lite entries can appear in the model list. The packaged model list is filtered to what the engine says this machine is allowed to run.
The same capability readout appears in Enhance world, where the terrain checkbox is disabled with a Runtime not configured badge if the runtime is absent.
terrain_components.py names the 90 m model only, and the Generate list is filtered server-side, so I have written it as "90 m ships, the rest appear when configured".Where your files live#
Everything the app writes for the current Windows user sits under one state root:
%LOCALAPPDATA%\Loresat\v1\| Folder | What it holds |
|---|---|
imported_worlds\ | worlds you created by importing a heightmap |
synthetic_worlds\ | worlds generated from a seed |
uploaded_worlds\ | worlds created from an uploaded project, created on demand |
render-queue\ | queued and completed render and export state. render-queue\v1\worlds.json is the registry of every world you have opened. |
renders\ | the render work directory |
paint_uploads\ | guide images and other paint-surface uploads |
onboarding\ | setup drafts in progress, including a heightmap you dropped but have not built yet |
preferences\ | saved setup preferences (preferences\onboarding.json) |
terrain-runtime\ | the terrain sidecar's own home, plus its numba and compiler caches |
sidecar-state\ | sidecar bookkeeping |
logs\ | engine stdout and stderr logs |
temp\ | scratch |
lifecycle\ | launch records and the clean-shutdown marker |
The AI colour add-on keeps its base model separately, alongside the state root:
%LOCALAPPDATA%\Loresat\model-cache\That holds the SD1.5 base model, roughly 4 GB, fetched once from its publisher at a pinned revision and hash-verified against digests built into the app before it is ever used. Dayside ships only its own trained adapter; the base model is not part of the installer. The Enhance section colour dialog shows the exact size and requires you to accept the CreativeML OpenRAIL-M licence before it downloads anything.
Loresat, not Dayside. That is deliberate and permanent. Loresat was this product's original name, and renaming the folder would orphan every world, preference and cached model already written under it on machines that have them. The paths above are what you will find on disk.Projects you open in place#
A project you open from a folder you chose is not stored under the state root. It lives where you put it, and the app saves changes in that folder. Removing such a project takes it out of your worlds list and leaves the folder on disk untouched. Only worlds inside the three managed directories above can be erased from disk, and that is a separate second confirmation.
Exports#
An export defaults to a folder beside the world:
<world folder>\loresat_exports\<time>_<section>_<destination>You can point it anywhere on the machine; the folder is created if it is missing, and the finished acquisition shows the full path to copy.
Reclaiming disk#
Render and export state is held to a budget, 20 GiB by default. When the budget is full, the queue asks its collector to trim the oldest unpinned completed jobs before admitting new work; if it still cannot fit, a render is refused with a storage error rather than filling the drive. The budget is settable with the LORESAT_RENDER_STATE_BUDGET_BYTES environment variable.
For a deeper clean, About & credits carries a data-removal tool. It previews exactly what it would delete, grouped into worlds, renders, preferences, logs and caches, asks you to type a confirmation phrase, and works on the current Windows user only. Installed application and model files are never touched. Removing data stops the engine, so you close the window and start the app again afterwards.