added docs for render machine

This commit is contained in:
2025-10-08 16:52:33 +01:00
parent 3729db43c0
commit 13932c2e58
3 changed files with 134 additions and 5 deletions

View File

@@ -133,3 +133,67 @@ is a high level function that encapsulates
#+END_SRC #+END_SRC
Free the entire session created. Free the entire session created.
* Render machine
_Note: We do not talk about how the game_
_itself is deployed here and we assume that
the game is avaliable to execute._
This node is incharge of computing the game
in it's CPU and GPU. This layer does not
distinguish if the game is running bare-metal
or on a virtualised environment but rather
focuses on game itself is rendered and
is pass through the /user machine/. Xplane
is called using the binary.
locally on the machine and the instructions
relating to which window it's running is
_yet to be decided (This is considered a todo_).
This section is split into 3 parts:
- Streaming part
- Keyboard and mouse passthrough
- API layer
** Streaming part
The flight sim session is streamed using
WebRTC. We will initially hook a chromuim
browser to detect the screen and over time
reduce this to a simple screencapture
native program to stream the video feed.
_TODO: Specifics to be documented._
** Keyboard and mouse passthrough
We plan to maintain a open source fork
of InputLeap. Input Leap is software that
mimics the functionality of a KVM switch,
which historically would allow you to use
a single keyboard and mouse to control
multiple computers by physically turning
a dial on the box to switch the machine
you're controlling at any given moment.
Input Leap does this in software,
allowing you to tell it which machine to
control by moving your mouse to the edge
of the screen, or by using a keypress to
switch focus to a different system.
_TODO: Diagramtic explaination of setup._
** API layer
We use the Xplane API REST server and UDP calls
to transmit data back to the
/Instructor machine/ for further analyses
and controlling the flight scenarious.
We will implement our own wrapper on
top of the Xplane API to create standarised
controls no matter the version of the flight
sim and we can more fine system control
such as new scenery files to pull.
_TODO: Internal Xplane APIs to use, Extact routes_
_and relation to transmitted to the instructor server._
* Network of Scenery files
Not documented until mid 2026.

Binary file not shown.

View File

@@ -1,4 +1,4 @@
% Created 2025-10-08 Wed 11:52 % Created 2025-10-08 Wed 16:48
% Intended LaTeX compiler: pdflatex % Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article} \documentclass[11pt]{article}
\usepackage[utf8]{inputenc} \usepackage[utf8]{inputenc}
@@ -25,7 +25,7 @@
\begin{document} \begin{document}
\section{Xplane WebRTC} \section{Xplane WebRTC}
\label{sec:org0e3cbea} \label{sec:org21772c5}
\begin{center} \begin{center}
\includegraphics[width=.9\linewidth]{./xprc.drawio.png} \includegraphics[width=.9\linewidth]{./xprc.drawio.png}
\end{center} \end{center}
@@ -76,7 +76,7 @@ approach and this open lot of areas of future research and hopefully better
performant flight simulators with better purposed algorithm to offload tasks to performant flight simulators with better purposed algorithm to offload tasks to
devices such as FPGAs or potato machines in abstraction layer similar to speaking nodes in an network. devices such as FPGAs or potato machines in abstraction layer similar to speaking nodes in an network.
\section{Architecture} \section{Architecture}
\label{sec:orgb730ec5} \label{sec:org7fd7def}
This chapter dives into the high architecture design of the This chapter dives into the high architecture design of the
project and each module is communicated in detail on the following project and each module is communicated in detail on the following
section below. section below.
@@ -86,7 +86,7 @@ section below.
\caption{High level architecture of the entire project} \caption{High level architecture of the entire project}
\end{figure} \end{figure}
\subsection{Game allocator} \subsection{Game allocator}
\label{sec:orgd67a679} \label{sec:orge51828f}
The game allocator stores information about the game sessions. This consists of attributes The game allocator stores information about the game sessions. This consists of attributes
such as: such as:
\begin{verbatim} \begin{verbatim}
@@ -110,7 +110,7 @@ information. A session consists of multiple pilots training with a single
instructor. Each pilot is assigned a node to render the game remotely instructor. Each pilot is assigned a node to render the game remotely
and the instructor can set the scenarios to be trained on. and the instructor can set the scenarios to be trained on.
\subsubsection{Interfaces} \subsubsection{Interfaces}
\label{sec:org380680a} \label{sec:org2d55851}
We will now motivate the higher level interfaces to construct a \uline{game allocator} We will now motivate the higher level interfaces to construct a \uline{game allocator}
this term is inspired from the use of terms like \emph{malloc} and \emph{free} in userspace this term is inspired from the use of terms like \emph{malloc} and \emph{free} in userspace
for allocating memory in a kernel. for allocating memory in a kernel.
@@ -161,4 +161,69 @@ is a high level function that encapsulates
FreeSession(Session) FreeSession(Session)
\end{verbatim} \end{verbatim}
Free the entire session created. Free the entire session created.
\section{Render machine}
\label{sec:orgf386a0c}
\uline{Note: We do not talk about how the game}
\uline{itself is deployed here and we assume that
the game is avaliable to execute.}
This node is incharge of computing the game
in it's CPU and GPU. This layer does not
distinguish if the game is running bare-metal
or on a virtualised environment but rather
focuses on game itself is rendered and
is pass through the \emph{user machine}. Xplane
is called using the binary.
locally on the machine and the instructions
relating to which window it's running is
\uline{yet to be decided (This is considered a todo}).
This section is split into 3 parts:
\begin{itemize}
\item Streaming part
\item Keyboard and mouse passthrough
\item API layer
\end{itemize}
\subsection{Streaming part}
\label{sec:org3e0d1c7}
The flight sim session is streamed using
WebRTC. We will initially hook a chromuim
browser to detect the screen and over time
reduce this to a simple screencapture
native program to stream the video feed.
\uline{TODO: Specifics to be documented.}
\subsection{Keyboard and mouse passthrough}
\label{sec:orgd4c9ff9}
We plan to maintain a open source fork
of InputLeap. Input Leap is software that
mimics the functionality of a KVM switch,
which historically would allow you to use
a single keyboard and mouse to control
multiple computers by physically turning
a dial on the box to switch the machine
you're controlling at any given moment.
Input Leap does this in software,
allowing you to tell it which machine to
control by moving your mouse to the edge
of the screen, or by using a keypress to
switch focus to a different system.
\uline{TODO: Diagramtic explaination of setup.}
\subsection{API layer}
\label{sec:org74f43ae}
We use the Xplane API REST server and UDP calls
to transmit data back to the
\emph{Instructor machine} for further analyses
and controlling the flight scenarious.
We will implement our own wrapper on
top of the Xplane API to create standarised
controls no matter the version of the flight
sim and we can more fine system control
such as new scenery files to pull.
\uline{TODO: Internal Xplane APIs to use, Extact routes}
\uline{and relation to transmitted to the instructor server.}
\section{Network of Scenery files}
\label{sec:org5c40c9a}
Not documented until mid 2026.
\end{document} \end{document}