athanggupte / apexgameengine Goto Github PK

Implement the game runtime which can "Play" the game:

• camera
• scripts
• physics
• AI
• sounds
• animations

Also need an editor "play" button which can start the game runtime inside the editor itself.

Implement custom macros with RTTR to automatically -

• serialize/deserialize
• export to Lua
• display members in editor

Post feedback here

Problem: Since resources can be added to the ResourceManager via scripts, stopping and playing the scene results in a failing assertion as the scripts attempt to add the same resource to the registry again.

Proposed mechanism:

1. OnScenePlay: Create a snapshot of the current state of the ResourceManager and save it for later use and then continue with scene->OnPlay().
2. OnSceneStop: Load the snapshot created during OnScenePlay to get delete all resources added via user scripts from the registry and their references from the pools. The reference counting in the shared_ptrs should delete the data from memory and thus automate garbage collection.

Possible enhancement to consider:
(Memory vs load time)
For scripts which add a lot of resources during creeation, the delay due to load time may be noticeable for several consecutive runs. Thus, instead of deleting the resources from the RM inside OnSceneStop, another snapshot can be created and cached for the next run. Then the references from this cached snapshot can be copied to the pools during LoadAllResources rather than creating or loading the resources from disk again.

Pros:

• Expect faster load times as memory allocations and disk accesses will be reduced.

Cons:

• More memory usage as resources will not be cleared from memory.

The current implementation of the OpenGL Buffer creation mechanism involves a diamond inherence from the OpenGL{XYZ}Buffer classes to the Buffer base class through the {XYZ}Buffer abstract class and the OpenGLBuffer abstract class.
This is not only a bad design strategy but can also slow down the code in the long run when a lot of buffers are built and managed.

Redesigning the entire Buffer class hierarchy and the creation pipeline is highly advisable.
Methods to consider:

• Create a OpenGLBufferFactory which can create the different OpenGL{XYZ}Buffer classes which can avoid the diamond hierarchy and also reduce code repetition.

FBX has a few problems -

1. Complex to load at runtime
2. Not fully compliant license especially for distribution of games
3. Requires installation of FBX SDK for game runtime
4. Not compatible with ARM or webgl

glTF 2.0 was designed to overcome all these problems and is also quite performant and easier to load at runtimes.

We'll allow designers to load assets in FBX format in the editor but then store them as gltf binaries in a build sub-directory which will be used by the engine and also shipped with the finished game. Using a checksum/hash we can reload the glTF from the FBX whenever there is a change in the FBX file.

Currently, the ImGui library is directly linked to the engine code and is thus a hard dependency of the engine. That means even in the runtime we will be forced to include the binaries of ImGui.
We should move the ImGui backend and the ImGui begin and end functions to a separate module called DebugUI or to the Editor directly.
The engine must be able to build without the ImGui binaries.

Expose high-level C++ functions to Lua for scripting

• ECS components
• Resources - Shaders, Textures, Meshes, Audio
• Draw calls
• Input handling - Character controller, UI
• Physics - changing physics states and properties
• Networking

Test different APIs for Audio playback -

• OpenAL - link
• FMOD - link
• irrKlang - link
• Google Pindrop - link

Meshes can have multiple materials associated with different sub-meshes.
Required:

• Splitting the mesh into sub-meshes in the FBXImporter based on materials
• Linking sub-meshes with Materials
• Grouping sub-meshes based on Shader and then Textures for batch rendering

Preprocess resources used in scene.

• Load meshes
• Generate LODs
• Load textures
• Generate mipmaps
• Load and compile shaders
• Load materials (shader-texture bindings)

Preprocess components in scene.
MeshRenderer:

• batch static geometry
• set up instance buffers
• opaque/transparent queues

Features for ECS:

• RTTI for components
• Pools of components for memory management
• Sorting components according to views

Change state based access and modification to DSA functions for:

• Framebuffer
• Texture
• Buffer
• Vertex Array
• Renderbuffer

File explorer for game assets like textures, models, scripts, audio files, etc.

• Root directory based on Project root #14
• Drag & drop
  • Scenes into game viewport
  • Resources into suitable targets (images into textures, sounds into audio, etc)
• Auto-reload
• Previews

Since all source includes of the shader are concatenated before passing to the shader compiler an error in any of the include files is still marked to be from the file 0 with cumulative line numbers.
To ease up debugging, we can use the #line _line_ _file_no_ preprocessor directive to set the correct line and file numbers.

Proposal:
Inside the SolveIncludes function in OpenGLShader.cpp, append before the include string:

#line 0 {file_counter}

where file_counter is a C side variable that counts the number of files included.
And after the include string, append:

#line {prev_line_number} {prev_file_counter}

A DFS algorithm or stack can be used to maintain the previous line and file numbers.

Graphic API calls can be grouped/scoped, and objects (textures, shaders, buffers, ...) can be labelled/named so that debuggers like Renderdoc can display them for better info during debugging

OpenGL: glPushDebugGroup, glPopDebugGroup, glObjectLabel

Whenever a new raw image/mesh/model is imported into the project (for the first time), display an importer dialog box for setting the metadata and import options for the asset. This data will then be saved in an asset descriptor file or in the project file and can be displayed in the explorer as an imported asset instead of a raw file.

Assimp supports many formats but it does have some issues with certain formats including FBX. FBX has become like the industry standard along with gltf 2.0, thus it makes sense to support these formats only.
These formats also support PBR materials built in and we can reduce certain client side checks for existence of UVs, normals etc.

TODO:

• Restrict workflow to fbx and/or gltf 2.0
• Use FBX SDK for .fbx import/export
• Use assimp/tinygltf for gltf 2.0 import/export

Required features for Android development

• EGL abstraction
• OpenGL -- GLESv2 and GLESv3 abstraction
• Android development framework -- Gradle and adb
  • Starting Gradle builds from runtime
  • Piping Gradle output to ImGui
  • Piping adb output to ImGui

Currently there exist 2 classes SceneCamera (Apex/Core/ECS/Components/SceneCamera.h) and Camera (Apex/Core/Camera.h) which provide the same base functionality and are thus redundant.

Proposal: Remove Camera class and make CameraController take a non-owning pointer to a SceneCamera (which can be renamed to Camera). The CameraController will be responsible for applying the transformations to the Editor/Debug Camera and thus can be a wrapper/modifier for the actual SceneCamera object.

1. Viewport controls
   • Mouse based camera movement
     • Right click - Free look rotation
     • Right click + WASDQE - Camera translation
   • Toolbar for selecting Viewport options
     • Ortho views - +X, -X, +Y, -Y, +Z, -Z axis aligned
     • Turn on/off Debug Gizmos (Bounding boxes, light volumes, etc)
     • Turn on/off Grid
2. Entity UI
   • Add pre-configured/template entities
     • Empty Entity
     • Light
       • Directional Light
       • Point Light
       • Spot Light
     • Mesh
       • Plane
       • Cube
       • Sphere
       • Icosphere
       • Import New Mesh... (Open FBXImporter window)
     • Camera
   • Interaction options
     • Delete entity
     • Duplicate Entity
     • Drag entity in hierarchy

Features required:

• Directory structure
• Packages as virtual directories
• Single root directory (project root or game install dir)
• Virtual mount points inside root dir
• Metadata
• Callbacks/Events - file changes, directory changes

Show the properties and components of the selected object

Currently, text rendering can only be done in the ImGui context and not in the actual 3D scene. By stealing a few functions from the ImGui library we can directly incorporate font rendering into the Renderer2D.

Proposed architecture:

1. Wrapper class Apex::FontAtlas over ImFontAtlas
2. Wrapper class Apex::FontGlyph over ImGlyph
3. Create OpenGLTexture2D and set data from ImFontAtlas->GetTexDataAsRGBA32. Set this in ImFontAtlas->SetTexID()
4. Functions Renderer2D::DrawGlyph() which should take in an Apex::FontGlyph and sets the quad attributes accordingly { position, color, UVs, texture index }
5. Helper function Renderer2D::DrawText() which takes in a string and adds all the glyphs in it using similar method as in Renderer2D::DrawGlyph()

Reference links:

• https://discourse.dearimgui.org/t/how-to-steal-glyphs-from-a-imfontatlas/265
• https://learnopengl.com/In-Practice/Text-Rendering

Current LogPanel implementation is plain string based, but rather we can create a new MessagePanel which can have all metadata about the logs stored in an array of MsgData struct

• Location
  • File
  • Line
  • Function
• Log Level
• Message/Payload
• Logger name
• Timestamp

This will allow us to select the details to display using Tables and also filter based on the parameter data such as Log level or logger without having to use string filter provided by ImGui. Using this data will also allow us to add our own Regex for detailed description of errors thus providing on-demand brief or verbose error details.

Currently in TransformComponent the final rotation matrix is calculated by multiplying rotation matrices with respect to each axis as seen here.

This is inefficient and also has improper rotation effect as rotation in Z axis us applied after Y axis which is after X axis.

An alternative is to convert the Euler angles to quaternion and to get the Mat4 from that.

P.S. this might not solve the axis precedence issue.

#define GLM_ENABLE_EXPERIMENTAL
#include <glm/gtx/quaternion.hpp>

glm::mat4 rotationMatrix = glm::toMat4(glm::quat(rotation));

Pick and drag-n-drop game objects into the scene using the mouse

Default:

• Tag
• Transform

Rendering:

• SpriteRenderer
• MeshRenderer
• LightSource

Behaviour:

• NativeScript
• Script
• CharacterController
• AnimationRunner

Physics:

• RigidBody2D
• RigidBody3D
• ForceSource

Audio:

• AudioSource
• AudioListener

GUI node-graph based editor for scripting shaders

• Node-Graph editor
  • Infinite canvas
  • Positioned nodes
  • Slots
  • Connections
  • Parse tree
• Node UI
  • Default input boxes
  • Display intermediate texture
  • Collapse texture box
• Shader code generation
  • Intermediate representation (using compute shaders)
  • Final fragment shader code framework
  • Node-level code design
• Shader nodes
  • In-built GLSL functions
  • Special general use functions
• Default inputs
• Pre-built pipelines
  • PBR pipeline
  • Flat 2D pipeline

Resources such as shaders and textures currently take filepath as parameter for their Create functions and load the files themselves. Instead they should use a File which is passed to the constructor so that the resource does not own file loading responsibility.

On-screen gizmos for interacting with the scene objects

• Translate, Rotate, Scale - ImGuizmo
• Bounding boxes, spheres, capsules
• Lights
  • Directional lights: Rays showing direction
  • Point lights: Sphere (3 axis aligned circles ) to show volume of effect
  • Spot lights: Cone (Circle at max Radius and rays from position to the circle) to show volume of effect
• Game camera
  • Position - camera icon
  • View frustum

The current implementation of the FBX Importer in backup-changes-290722 branch creates a separate vertex for each triangle thus making the index buffer obsolete as there is no reusing of vertices. This also means that the size of the meshes in memory is larger than required. Fix the algorithm to first extract arrays of all the components - Position, Normal, UV, etc. and then use the metadata in the FBX scene to map them together in a way that uses the memory optimally and also maintains proper hard and soft edges.

A complete encapsulation for all game files and configurations

• VFS mount points
• Resources
• Scenes
• Editor states
• Build configurations
• Auto generate build script