JackCarterSmith
a079606a1e
5.7 KiB
layout, title, author, categories, thumbnail, highlight
| layout | title | author | categories | thumbnail | highlight |
|---|---|---|---|---|---|
| post | Journey into 3D engine design - P1.Introduction | JackCarterSmith | Programming C++ GameDev | build_an_engine | true |
- Contents {:toc}
For many years now, the performance of computers has been constantly evolving: the number of transistors has increased transistors, reduced size, increased speed, reduced power consumption... All these improvements have enabled computers to carry out more and more complex calculations in large calculations. One of its applications is the display of a virtual 3D environment on a physical 2D screen (your computer screen)! 3D rendering engines are now used everywhere: in entertainment but also in architecture, aeronautics and the automotive industry.
Nowadays, it's very complicated to define what a 3D engine should be able to do. is accompanied by extensions, generally related to the use of the software, but which end up hiding the the "basis" of 3D rendering on a computer.
In this "Journey into 3D engine design" series, I'm going to look at the basics and write a pared-down engine, retaining only the minimum that's useful. This base can later be used to understand how graphics APIs work (Vulkan, Direct3D, Metal, etc.) and to create portions that can be reused in embedded systems that don't have hardware acceleration (GPU).
I haven't planned any particular guidelines for these blog posts. I'll be writing the various topics progress and the various issues I come across!
![SFML exemples]({{ "/static/images/posts/computer_nerd.jpg" | prepend: site.baseurl }} "Trust me, I'm an engineer!")
My problem with Unreal, Unity, Godot, etc.
The WWW is full of "how to make a 3D game" tutorials. In fact, there's no shortage of these videos and blogs... However, there are 2 types of tutorial: those that explain how to use an engine and create a game using it, and those that explain how to create a game using graphics APIs such as OpenGL directly. There's actually a third, less ordinary category (and here we're curious about the unusual!), which really starts from 0, no APIs or very few libraries (apart from stdlib), including 3D maths libraries. This might seem like reinventing the wheel, but you have to ask yourself: is my aim to study the wheel? Then yes, reinventing the wheel is essential.
So yes, in this series, no explanation of "how to make AAA with UE5" but rather details on how and why pixels are displayed on our screen simply from NUMBERS! Do you think I'm making a fuss? It's up to you, but we're going to eat maths, a lot! Guaranteed.
For the start, I'm going to use SFML (Simple and Fast Multimedia Library) for simplified management of the OS window, without messing up the rather OS-management-oriented function code too much. I plan to remove it later in the series, for a possible port to embedded. In addition, in order to have a practical example of my post on [CPU optimisations]({% post_url 2024-03-01-cpu-vectorized-acceleration %}), I'll be adding SIMD instructions equivalents alongside the implementation. This 3D engine will in fact be CPU-only in order to ensure that it is as portable as possible on architectures that don't have a dedicated GPU or compatibility with standard graphics APIs (although this is rare when a GPU is present).
Some engines are in the form of a framework or library and need to be used by a master application to tell it what to do, while others combine the engine directly into the application, sacrificing the engine's modularity but making the code easier to read for our purposes.
In conclusion, there are no good or bad reasons for creating your own engine, whether to achieve something very specific artistically, or to get the best performance for a given gameplay. Obviously, this involves going down the "long path" and often spending several hours on basic notions that are essential to the concept of a graphics engine in general.
No pain, no gain.
![SFML exemples]({{ "/static/images/posts/sfml_games.jpg" | prepend: site.baseurl }} "A lot of indies games have been develop using SFML")
Minimum equipment
SFML offers several function groups for graphics, audio and networking. For the moment, I will only need the graphics part, in order to manage the system window and the rendering display. SDL was also a potential candidate for this use, but for this project I wanted to make up my mind about SFML.
Apart from SFML, the mathematical part will be supported by a slightly modified and reduced implementation of Direct3DMath. The SIMD acceleration it offers is not negligible for CPU-only.
Multi-threading is also envisaged through the use of the pthread lib. More versatile than std::thread from libstdc++ and less obscure than OpenMP in use (we'll come back to this).
Since we're recreating a graphical flow from scratch, we'll need to create our own tools for debugging rendering and performance measurement tools.
I often work with the GNU toolchain (version 14 at the time of writing) and with the Conan package manager.
The project itself is configured with CMake. From time to time I check compatibility with Windows via the MSVC compiler. MinGW can also be used without contraindication.
And we'll try to keep to this strict minimum in order to lighten the code by keeping only what is necessary for on-screen rendering, and also to improve the portability of the programme to more critical platforms in terms of storage and performance.
See you in the next post!
[END_OF_REPORT-250114.1459]