more refinements
This commit is contained in:
Nova
@@ -4,7 +4,12 @@ sidebar_position: 2
|
||||
|
||||
# Installation
|
||||
|
||||
Stardust officially works on Linux distributions, it may work on BSD/Fuchsia but that support is not guaranteed. Windows/macOS support is not planned at this time.
|
||||
As Stardust is a display server, it is split into multiple parts. Make sure to install the parts in order to avoid issues, and don't be afraid to ask questions in the Matrix or Discord servers!
|
||||
|
||||
1. [libstardustxr client/server](#libstardustxr-server-client-and-fusion)
|
||||
2. [libstardustxr-fusion](#libstardustxr-server-client-and-fusion)
|
||||
3. [stardust-xr](#stardust-xr-reference-server)
|
||||
4. Other clients (such as the [tests](#stardust-client-tests))
|
||||
|
||||
## [libstardustxr](https://github.com/StardustXR/libstardustxr) (server, client, and fusion)
|
||||
|
||||
@@ -53,7 +58,10 @@ AUR: `stardust-xr-git`
|
||||
4. GLX+Xlib
|
||||
5. fontconfig
|
||||
6. dlopen
|
||||
7. OpenXR Loader (required even if run in flatscreen mode)
|
||||
7. libseat (such as [seatd](https://sr.ht/~kennylevinsen/seatd/))
|
||||
8. wayland
|
||||
9. xwayland
|
||||
10. OpenXR Loader (required even if run in flatscreen mode, generally just named `openxr`)
|
||||
|
||||
### Download
|
||||
```bash
|
||||
@@ -70,5 +78,30 @@ ninja
|
||||
|
||||
### Install
|
||||
```bash
|
||||
ninja install
|
||||
meson install --skip-subprojects
|
||||
```
|
||||
|
||||
|
||||
## [Stardust Client Tests](https://github.com/StardustXR/stardust-client-tests)
|
||||
|
||||
### Build system
|
||||
1. Meson >= 0.55.0
|
||||
2. Ninja (tested on 1.10.2)
|
||||
|
||||
### Build dependencies
|
||||
1. [libstardustxr](#libstardustxr-server-client-and-fusion)
|
||||
2. Flatbuffers >= 1.12.0
|
||||
3. sdbus-cpp
|
||||
|
||||
### Download
|
||||
```bash
|
||||
git clone https://github.com/StardustXR/stardust-client-tests.git
|
||||
cd stardust-xr
|
||||
```
|
||||
|
||||
### Build
|
||||
```bash
|
||||
meson build --prefix=/usr
|
||||
cd build
|
||||
ninja
|
||||
```
|
||||
@@ -7,38 +7,6 @@ sidebar_position: 1
|
||||
## Description
|
||||
Stardust XR (informally known as Stardust) is an XR display server for Linux-based distros. 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.
|
||||
|
||||
Put simply, Stardust is a system UI framework where multiple different clients (programs that connect to Stardust directly) can create objects for the user to interact with. 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.
|
||||
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.
|
||||
|
||||
## 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. 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 initial connection and establishes anonymous pipes for communication.
|
||||
|
||||
## [Protocol](stardust-protocol/protocol.md)
|
||||
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 and reliable.
|
||||
|
||||
## 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. However, if a more fully featured application works better in Stardust it can do that too.
|
||||
Put simply, Stardust is a system UI framework 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.
|
||||
39
docs/getting-started/tech-overview.md
Normal file
39
docs/getting-started/tech-overview.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
# 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. 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.
|
||||
|
||||
## [Protocol](stardust-protocol/protocol.md)
|
||||
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 and reliable.
|
||||
|
||||
## 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. However, if a more fully featured application works better in Stardust it can do that too.
|
||||
@@ -19,7 +19,6 @@ const FeatureList = [
|
||||
description: (
|
||||
<>
|
||||
Stardust is made using <a href="https://stereokit.net">StereoKit</a>, an XR application/rendering toolkit allowing for a fast and lightweight display server.
|
||||
The compiled server binary when statically linking StereoKit is less than 20MB and uses ~50MB of RAM (varies depending on clients).
|
||||
</>
|
||||
),
|
||||
},
|
||||
|
||||
Reference in New Issue
Block a user