Main Core
SubSystems
-
Explanation
The engine uses a structure of GameObjects. What does this mean? All the things you can add to the engine scene are GameObjects (geometry, frustum…). To this GameObjects you can add different components such as Transformation, Mesh or Material.
All the GameObject start with a transformation in the 3D world. This component has two float3 that are the position and the scale, the other one is a float4 that express the rotation in quaternion. You can modify this value on the inspector window or using the Guizmos.
You can also add a Mesh component that allows you to choose a FBX that you have in assets.
Finally, you can add a Texture component that allows you to choose a texture that you have in assets. In this case you can also choose a Shader Program you have in assets.
Structure of GameObject and Components
Thanks to this implementation now the mesh and texture component the only variable they will receive is a UUID (a number that is random and will probably never repeat), it’s an id that refers to a resource. So, the component now will use a resource, this means that if two GameObjects wants to use the same resource this will be stored in memory once. Is an optimization, is good to don’t store in memory things that are already stored and to control the resources when are updated to reimport.
This manager makes a file meta that stores the original file path and the own format file path and the last time modification.
With this manager every 3 seconds look in assets if any file has been updated by looking if the last time modification has changed, then it’s reimported.
Resource Manager
The fist approach of having geometry in the 3D engine was using the direct draw of OpenGL to start with the typical triangle. Then we made a structure that made possible to store the information of Assimp FBX importer. This pipeline was not optimum because if you had the same FBX and you drag it twice to the engine this FBX was imported two times and Assimp importation has a lot of cost, the ideal is to make like “prefabs” that only import once and create “instances” of those.
Now the geometry importer pipeline uses the mesh resource, so the geometry is only imported once and if you try to import the mesh another time, the game object will use the resource already stored in memory.
After import the FBX with Assimp we have created an own file format storing the essential data for reimporting again the geometry but this time in a more optimized way because we will read the data stored in our own format that is faster than Assimp importation because has a lot of data that we don’t use.
Assimp and Own File Format
After working with a scene, you can go to Menu>Save then you can choose the directory where you will save the scene. We store the hierarchy of the GameObjects, the component transform, mesh and texture (with the shader). If there is a camera/frustum is saved to. All this information is stored in a JSON. Then if you want to continue working with the scene you had saved you just have to load going to Menu>Load>Choose the directory where the scene is and finally the file.
Scene serialization
Mouse Picking
When you click on a geometry a segment is created from the near plane of the camera to the far plane and first we store on a map all the AABB that had intersected with this segment in order of distance to camera. Next, we iterate all the geometry intersected and test the segment in local space with all the triangle of the mesh and if it intersects we continue iterating since we find the geometry intersected for the segment and closer to the camera.
Frustum Culling
The Octree puts every gameobject in the scene in a list and iterates itself by dividing into nodes with a certain amount of gameobjects inside. This is used for optimization options like searching gameobjects etc...
Octree
This optimizations works so as any static gameobject that is outside the bounds of the Frustum of the camera is deactivated. The Camera Culling uses Octree so it is more optimized and in consumes less power.
