rename filenames to reflect order

docs/01_getting-started/01_overview.md

@@ -0,0 +1,12 @@
+---
+sidebar_position: 1
+---
+
+# Overview
+
+## Description
+Stardust XR (informally known as Stardust) is an XR display server for Linux-based distros (possibly most unix-based too, but untested). Unlike display servers of the past that were run on bounded 2D screens, Stardust has to break convention in order to account for unbounded 3D space in any potential virtual or real environment.
+
+Unlike many display servers, Stardust is not trying to reinvent how applications interface with the system. Stardust uses Wayland and will use OpenXR for 2D/XR app integration. Stardust however has a special protocol for creation of virtual objects such as 3D UIs around 2D apps (called Panel Shells) and handling of data as objects (called Items, can represent files or Wayland surfaces or such). Stardust is not a collaborative 3D space, instead focusing on your own personal device and interactions with it.
+
+Put simply, Stardust is a system UI base where multiple different clients (programs that connect to Stardust directly) can create objects for the user to interact with their apps and device. The user can choose to use the objects that work best for their current scenario, and default setups can easily be created so users start out with all the essentials.

docs/01_getting-started/02_tech-overview.md

@@ -0,0 +1,39 @@
+---
+sidebar_position: 2
+---
+
+# Technical Overview
+
+## Server
+The server is what renders all the meshes of each client, takes in input from input methods, and spits out input to input handlers according to the SUIS (Spatial Universal Interaction System). As well, the server is going to be part Wayland compositor and OpenXR runtime so all 2D and XR applications can be used together at once (if the hardware allows). It is the glue of Stardust, allowing any number of clients and apps to work in harmony while allowing the user full control in an intuitive way.
+
+As new technologies come out, keeping the same server and trying to progressively upgrade it may lead to bloat and issues, so the protocol is designed to make creating new servers possible without too much hassle or to make servers modular. Old interfaces can be deprecated without breaking the overall system, and new interfaces can be added if needed due to the object-oriented design. The design is highly inspired by game engines, however the reference server is made in StereoKit due to it being more optimal.
+
+### Reference Server
+Stardust has a reference server, but unlike other display servers this reference server is just as functional as any other Stardust server would be, because all the functionality is implemented in the clients. The server is just the glue.
+
+The reference server uses StereoKit as its backend for many reasons:
+- Much more lightweight than any other framework/other engine
+  - It was originally designed to run AR apps on HoloLens, and now it works on Quest
+  - It's able to render thousands of objects on a HoloLens without breaking a sweat
+- Does not include unnecessary features that slow down performance
+  - Physics and UI are not needed for Stardust, but those do not actively run and can always have an option to not be compiled at all.
+- Uses C-style C++ meaning not bytecode or interpreted (however has a C# API that is not used by Stardust)
+- Uses immediate mode rendering meaning the logic is many times easier to implement
+- Exposes its rendering insides whenever needed
+  - Very needed for Wayland when it needs to display EGL Wayland surface textures on meshes
+  - Overriding the depthbuffer per-pixel in fragment shader is useful for XR depth compositing
+- Is constantly getting new updates faster than most engines
+  - World semantics for OpenXR was implemented ~1 week after the official OpenXR extension release
+- Is optimized to load resources JIT
+  - Many game engines are best at caching their assets, but this is not practical in a display server
+- Uses OpenXR as its backend out of the box
+
+## IPC
+The Stardust XR IPC uses Unix domain sockets for communication and a protocol based on flatbuffers/flexbuffers.
+
+## Protocol
+The Stardust XR protocol is object-oriented, depending on a scenegraph on the server end and scenegraph or functionally equivalent structure on the client end. This allows easier implementation of the protocol while still remaining fast, reliable, and extensible.
+
+## Clients
+The clients tell the server what models to draw, where they would like to accept input in, etc. Stardust clients are much more suited to widgets or user interfaces to 2D/XR apps.

docs/01_getting-started/03_setup.md

@@ -0,0 +1,17 @@
+---
+sidebar_position: 3
+---
+
+# Setup
+
+First you need to install and run the server from https://github.com/StardustXR/server. Follow the README. If you have issues getting OpenXR to work, try running https://gitlab.freedesktop.org/monado/demos/xrgears first.
+
+After the server is running, you'll need to run some clients. Here's a demo showing some off:
+![A showcase of some different clients](/img/docs/clients/demo_01.mp4)
+
+Non-exhaustive list of clients:
+- [Flatland](https://github.com/StardustXR/flatland): A panel item UI (XR equivalent of a window manager) so you can interact with your apps using virtual touchscreens. To show Wayland apps, run them with the proper `WAYLAND_DISPLAY` environment variable, in the server's startup script, or use a stardust launcher such as gravity or protostar. Flatland works great in 3DoF or 6DoF with direct touch and pointer interaction.
+![A flat panel containing the prism launcher](/img/docs/clients/flatland.png)
+- [Gravity](https://github.com/StardustXR/gravity): Command line tool to launch programs inside of stardust at a particular offset in space. This is nestable so you can run a script using gravity, and then gravity inside that script to make a whole composed setup out of thin air! It also ensures that everything launched through it will properly connect to the stardust server, such as wayland clients.
+- [Protostar](https://github.com/StardustXR/protostar): Prototype app launcher library/examples. Grab app icons and drop them in space to launch apps where they're dropped.
+- [Magnetar](https://github.com/StardustXR/magnetar): Workspaces in 3D. Any object inside the rings will move with them, so you can move a bunch of stuff out of the way temporarily when you don't need it.

docs/01_getting-started/04_making-clients.md

@@ -0,0 +1,29 @@
+---
+sidebar_position: 4
+---
+
+# Making Clients
+
+A Stardust client is at its core an executable that connects to a stardust server instance at `$XDG_RUNTIME_DIR/stardust-[0-32]`, sends and receives messages according to the Stardust protocol.
+
+## Rust
+
+Stardust uses Rust due to its speed and reliability in build and runtime, so you will need to install cargo (preferably through [rustup](https://rustup.rs/)). If you're unsure how to use Rust then a great guide is at https://doc.rust-lang.org/book/.
+
+## stardust-xr
+
+`stardust-xr` is a connecting library for servers and clients that deals with the lowest level of connecting to ensure basic compatibility is ensured. As a client developer you most likely won't need it, but it's good to know about it.
+
+## Fusion
+
+`stardust-xr-fusion` is the high level library you'll probably be using to create your clients. It features structs for all Stardust objects and trait-based + async systems for handling events from the server.
+
+To get started, create a new Rust project using
+```bash
+cargo new
+```
+and include the `stardust-xr-fusion` dependency in your `cargo.toml`. Documentation will be available at https://docs.rs/crate/stardust-xr-fusion/latest.
+
+## Molecules
+
+`stardust-xr-molecules` is an even higher level widget library built on Fusion similar to [MRTK](https://github.com/microsoft/MixedRealityToolkit-Unity) to get your clients up and running faster. Documentation will be available at https://docs.rs/crate/stardust-xr-molecules/latest.

docs/01_getting-started/_category_.json

@@ -0,0 +1,4 @@
+{
+	"label": "Getting Started",
+	"position": 1
+}