The project directory structure

A VRGS project is two things on disk: a small .vgpx project file, and a data folder beside it named after the project with Data appended. Both are needed — the .vgpx on its own will not open a project, because the interpretations live in the database inside the data folder.

📜MyProject.vgpx        // the project file (JSON): settings, coordinate system, display options

📦MyProject Data
 ┣ 📂DATABASES          // Database directory
 ┃ ┗ 📜SQLDBv4.db       // sqlite database - every interpretation in the project
 ┣ 📂VGP_BACKUP         // Backup directory
 ┃ ┣ 📜Sat_Oct_24_172750_2020.zip  // Backup of the last saved project
 ┃ ┗ 📜Sat_Oct_22_201643_2020_UpgradeFrom_266.zip
 ┣ 📂POINTCLOUDS        // point clouds, one binary PLY file each
 ┃ ┗ 📜TreforScan.ply
 ┣ 📂GAUSSIANSPLATS     // Gaussian splats, one standard 3DGS PLY file each
 ┣ 📂TRIMESH            // meshes, and the texture images they use
 ┃ ┣ 📜TreforLowRes.tin_v3
 ┃ ┗ 📜TreforLowRes.jpg
 ┣ 📂ORTHOPANELS        // orthopanels, one .orthopanel file each
 ┣ 📂ORTHOIMAGES
 ┃ ┗ AA.tif
 ┣ 📂TILEMODELS         // tiled models
 ┣ 📂ASSETS             // location of user defined assets
 ┣ 📂BILLBOARDS         // billboard textures
 ┣ 📂HTML               // field guide and HTML pages
 ┣ 📂JSON_WELL_LOGS
 ┣ 📂LIBRARY            // this project's own log patterns and symbols
 ┣ 📂LOGIMAGES
 ┣ 📂MULTIMEDIA         // files linked from multimedia annotations
 ┣ 📂PLUGINS
 ┣ 📂PYTHON             // project Python scripts
 ┣ 📂RAG_DB             // Athos's index of this project's literature
 ┣ 📂RECYCLING          // deleted objects and unused data files, recoverable until you clear it
 ┣ 📂SEGMENTATION
 ┣ 📂SFM_WORKSPACES     // photogrammetry (SfM) reconstruction workspaces
 ┣ 📂SLIDES
 ┃ ┣ 📜PresentationSlide1.jpg
 ┗ 📜ProjectPrefs.json  // project preferences, colour maps, autosave settings

Most of the sub-folders are created when the project is, whether or not you ever put anything in them, so an empty folder is not a sign that something went wrong.

The model files

VRGS keeps its own copy of every model you import, which is what makes reopening a project so much faster than the original import.

Model	File	Opens outside VRGS?
Point cloud	POINTCLOUDS\<name>.ply	Yes. It is a binary PLY with full double-precision coordinates and each attribute layer as a scalar field, so CloudCompare and other PLY tools read it.
Gaussian splat	GAUSSIANSPLATS\<name>.ply	Yes. It uses the standard 3D Gaussian splatting layout, which splat viewers read. Positions are stored about a local origin kept in the file's header, so in another viewer the splat sits near the origin and not at its project coordinates.
Mesh	TRIMESH\<name>.tin_v3, with its texture images beside it	No. It is VRGS's own compressed format. To use a mesh elsewhere, export it.
Orthopanel	ORTHOPANELS\<name>.orthopanel	No. It is VRGS's own binary format.

Look at these files, do not edit them

Open a copy of a model file in another tool, and do not put an edited file back. VRGS keeps a point cloud's layer names, colour maps, filters and scan orientation in a comment in the PLY header. A file saved by another tool generally loses that comment, and VRGS then refuses to read it.

What older projects hold

A project last saved by an earlier VRGS keeps its models in older files, and VRGS still reads them all:

Model	Older file
Point cloud	.pcl at the root of the data folder
Gaussian splat	.gsplat at the root of the data folder
Mesh	.tin at the root of the data folder, with .dxt and .povl files and texture images beside it
Orthopanel	ORTHOPANELS\<name>.orthopanel, in an older layout under the same name

Opening a project that holds any of these asks first, and offers to back up the project and its data folder; see Upgrading an older project. Each model then gets its new file and the old one is deleted, not recycled, so that backup is the way back. A texture image that another mesh still uses stays where it is. A model that cannot be converted stays in its old file, with a warning in the messages panel, and goes on working.

Older files the project no longer uses can be moved out of the way with Recycle unused data files. If the project file or database is lost, the models can often still be rebuilt from these files; see Recovering models from a data folder.

Moving or archiving a project

Copy the .vgpx and the Data folder together, and keep them side by side. A .vgpx on its own has no interpretations in it, and a data folder on its own has no project to open.

Older projects

Projects created with VRGS 3.3 and earlier have a binary .vgp file where the .vgpx is shown above. VRGS still opens those; once one has been saved by 3.4 it gains a .vgpx sibling, and that is the file to open from then on. The old .vgp is left alone rather than rewritten.

Accessing the database file

The database is a plain SQLite file at <project> Data\DATABASES\SQLDBv4.db, so anything that reads SQLite can read it — the sqlite3 command line, a GUI browser, or Python's sqlite3 module from the VRGS Python console.

Close the project in VRGS first, or open a copy. VRGS holds the database open while the project is loaded, and writing to it from outside is the one reliable way to corrupt a project.

You may not need the database at all

Two routes get the data out without touching SQLite: the Spreadsheet view on any interpretation group (right-click the group → Spreadsheet), and the export routes in Getting Data In and Out. The Athos assistant can also query the project database from a plain-English question.