aboutsummaryrefslogtreecommitdiff
path: root/research.tex
diff options
context:
space:
mode:
authorJaro <jarorutjes07@gmail.com>2024-10-01 12:01:44 +0200
committerJaro <jarorutjes07@gmail.com>2024-10-01 12:01:44 +0200
commitc26175bfa83d0e3d4269e25ed4e6f06f8e3e4cf7 (patch)
tree07346abc00e18334e67ea6ca4e845921cef31bcf /research.tex
parent779764d49e71c7f68508f4dcf3bbca99db359617 (diff)
added information about physics
Diffstat (limited to 'research.tex')
-rw-r--r--research.tex115
1 files changed, 92 insertions, 23 deletions
diff --git a/research.tex b/research.tex
index 29cee68..abbd5ac 100644
--- a/research.tex
+++ b/research.tex
@@ -472,7 +472,7 @@ is Zlib/LibPng licensed and provides a high-level object-oriented C++ \gls{api}.
Due to a severe shortage of libraries that fit our requirements, SoLoud appears to be
the most suitable (and only) audio library for use in this project.
-\section{Physics}
+\section{Scripting}
\subsection{Introduction}
@@ -480,7 +480,7 @@ the most suitable (and only) audio library for use in this project.
\subsection{Conclusion}
-\section{Scripting}
+\section{Physics}
%links
%ragdoll info: https://learn.unity.com/tutorial/creating-ragdolls-2019#649c42abedbc2a04c2145ce7
@@ -493,12 +493,12 @@ the most suitable (and only) audio library for use in this project.
%rigid body:https://docs.unity3d.com/ScriptReference/Rigidbody.html
\subsection{Introduction}
-This part of the research explains physcis concepts and the use of physics in a game engine. Furthermore, it examines the ease of using a physics engine compared to implementing physics from scratch. Ultimately, a recommendation will be provided on whether using a physics engine is more feasible than a custom implementation.
+This part of the research explains Physics concepts and the use of physics in a game engine. Furthermore, it examines the ease of using a physics engine compared to implementing physics from scratch. Ultimately, a recommendation will be provided on whether using a physics engine is more feasible than a custom implementation.
\subsection{Physics concepts}
-
+Some information about certain Physics topics. second partdescibes what physics we will be able to use and what it is.
%Physics core concepts: https://bluebirdinternational.com/game-physics/#:~:text=Game%20physics%20is%20implemented%20using,solid%20and%20deformable%20objects%2C%20respectively
%ragdoll https://bluebirdinternational.com/ragdoll-physics/
@@ -561,28 +561,11 @@ Aerodynamics shows the movement of air and its interaction with solid objects. I
\subsection{Implementation of Physics}
-To know what the best Physics solution is for a project a list has been created with physics concepts.This list shows how much effort it is to implement a feature and if an engine has the feature available. For this list three physics engines have been found that can provide 2d physics.
+This part shows some phiscics engines an certain physics features that could be needed within the project.
-\subsubsection{Physics comparison}
-
-\begin{itemize}
- \item Rigid Body Dynamics
- \item Soft Body Dynamics
- \item Particle Systems
- \item Fluid Dynamics
- \item Collision Detection
- \item Aerodynamics
- \item Ragdoll Physics
- \item Constraints %box2d
- \item Joint Limits %box2d
- \item Joint Motors %box2d
- \item Joint Springs %box2d
- \item World Simulation %box2d
- \item Solver %box2d
-\end{itemize}
\subsubsection{Physics Engines}
-
+available physics engines for complex Physics
\paragraph{Box2D}
\begin{description}
\item[Description:] One of the most popular and widely used open-source 2D physics engines, Box2D is known for its simplicity, robustness, and efficiency.
@@ -601,6 +584,92 @@ To know what the best Physics solution is for a project a list has been created
\item[License:] MIT License
\end{description}
+\subsubsection{Simple Physics features}
+
+There are some features that could be beneficial for this project.a list has been created to show these features. More complex features will be worked out furter.
+
+\begin{itemize}
+ \item Gravity
+ \item Collision (detection + standard handeling)
+ \item Rigidbody body
+ \begin{itemize}
+ \item mass
+ \item gravity scale
+ \item velocity
+ \item body type
+ \begin{itemize}
+ \item Static
+ \item Dynamic
+ \item Kinematic (User script)
+ \item Kinematic (standard)
+ \end{itemize}
+ \end{itemize}
+ \item collsion detection mode
+ \item movement
+ \begin{itemize}
+ \item player movement
+ \item bounce
+ \item rotation
+ \item directional force
+ \end{itemize}
+ \item particels
+\end{itemize}
+
+\subsubsection{Physics system (engine specific physics engine)}
+A physics engine that is independent can be used across multiple game engines or applications. But when the physics engine is built directly into the game engine and can not be reused independently, it is often considered a physics system or physics module within that specific engine. It is optimized and designed to work within the constraints and features of that particular engine.
+
+For simple features as listed above (besides collision and particels) a Physics system is sufficient to provide these features to the game engine.
+
+These features can be implented using EC and ECS. Both have each own benefits and downsites.
+
+\subsubsection(Physics with EC)
+with EC the component (e.g. Rigidbody) would have some functionality to change its own physics. Besides storing data it would hold function as well for applying gravity, forces, or handle other physics-related logic.
+
+Preview of Rigidbody
+\begin{itemize}
+ \item Mass (data)
+ \item gravityscale (data)
+ \item velocity (data)
+ \item applygravity (function)
+ \item update position (function)
+\end{itemize}
+
+With this logic inside of each component the gameloop would look like this:
+
+step 1: Have a list of components.
+step 2: call for each component the rigidbody with the update function (changing its velocity)
+step 3: call for each component the update position function (change x and y of each entity)
+step 4: check for collsion handeling (would be the collsion component)
+
+because it is not known with EC if the list contains all object with a rigidbody some overhead is created if the entity does not have a component of the type rigidbody.
+
+\subsubsection(Physics with ECS)
+With ECS the component (e.g. Rigidbody) would only be used to store data. all functionality would be moved to the Physics system
+
+Preview of Rigidbody
+\begin{itemize}
+ \item Mass (data)
+ \item gravityscale (data)
+ \item velocity (data)
+\end{itemize}
+
+Preview of physics system
+\begin{itemize}
+ \item applygravity (function)
+ \item update position (function)
+\end{itemize}
+
+A seperate sytem would be made that would do all the calculations for the physics.
+
+With this logic inside of each component the gameloop would look like this:
+Step(1): ECS provides a list of rigidbodies (with the enitties)
+Step(2): physics system updates all components
+
+The benefit of ECS is that all physics and collsions are handled by one system. The Physics functionalities would be gathered in one place instead of multiple components. The Physics system could seperate the Physics function creating a correct Physics flow with only one loop. For EC to do this each function would need to have its own loop in the gameloop creating more overhead.
+
+What EC can not provide compared to ECS is a physics world. A physics world would be the physics that apply to all dynamic physics components. If you want to create gravity you can add the force to the world. The physics system would read all the Physics forces in the world and apply them to all dynamic entities. This would create an easier to use interface for the user and improve the efficiency of the physics because the total forces can be calcualted ones and then applied to all dynamic entities.
+
+
\subsection{Findings}