added docs for render machine
This commit is contained in:
@@ -133,3 +133,67 @@ is a high level function that encapsulates
|
||||
#+END_SRC
|
||||
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
|
||||
\documentclass[11pt]{article}
|
||||
\usepackage[utf8]{inputenc}
|
||||
@@ -25,7 +25,7 @@
|
||||
\begin{document}
|
||||
|
||||
\section{Xplane WebRTC}
|
||||
\label{sec:org0e3cbea}
|
||||
\label{sec:org21772c5}
|
||||
\begin{center}
|
||||
\includegraphics[width=.9\linewidth]{./xprc.drawio.png}
|
||||
\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
|
||||
devices such as FPGAs or potato machines in abstraction layer similar to speaking nodes in an network.
|
||||
\section{Architecture}
|
||||
\label{sec:orgb730ec5}
|
||||
\label{sec:org7fd7def}
|
||||
This chapter dives into the high architecture design of the
|
||||
project and each module is communicated in detail on the following
|
||||
section below.
|
||||
@@ -86,7 +86,7 @@ section below.
|
||||
\caption{High level architecture of the entire project}
|
||||
\end{figure}
|
||||
\subsection{Game allocator}
|
||||
\label{sec:orgd67a679}
|
||||
\label{sec:orge51828f}
|
||||
The game allocator stores information about the game sessions. This consists of attributes
|
||||
such as:
|
||||
\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
|
||||
and the instructor can set the scenarios to be trained on.
|
||||
\subsubsection{Interfaces}
|
||||
\label{sec:org380680a}
|
||||
\label{sec:org2d55851}
|
||||
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
|
||||
for allocating memory in a kernel.
|
||||
@@ -161,4 +161,69 @@ is a high level function that encapsulates
|
||||
FreeSession(Session)
|
||||
\end{verbatim}
|
||||
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}
|
||||
|
||||
Reference in New Issue
Block a user