added docs for render machine
This commit is contained in:
@@ -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.
@@ -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}
|
||||||
|
|||||||
Reference in New Issue
Block a user