haeri / photonbox Goto Github PK

Rendering API should allow for to render multiple instances of the same mesh at once,

This should be a lot faster than the random sampling in 3d space.
http://frederikaalund.com/a-comparative-study-of-screen-space-ambient-occlusion-methods/

The current shader system needs a rework. It should not be necessary to create a class for every shader type. A shader instance should parse all the necessary information from a unified shader file (with a .pbs extension) containing vertex and fragment source code. Additional defines should specify how the shader is configured.

shader.pbs

# type: surface
# vertex
/* glsl code */

# fragment
/* glsl code */

If the game code compiles to a shared library, it can be hot-reloaded without having to shut down the running engine-process.

Redistributing dependencies as binaries is not best practice, as it bloats the repo and may not work for all platforms.

• Vcpkg would solve this problem as it is a rather large c++ "package" manager.
• But this change would required to setup CMake form the current project, which is a royal pain in the butt!
• Also the project setup would reqire Cmake and vcpkg to be installed, instead of no requirements (since Premake is currently redistributed)

The OpenGL API is strongly coupled with the engine. There needs to be an abstraction layer over the graphics api.

The math classes, especially the vectors and matrices would greatly profit from SIMD as it would boost the performance by paralleling operations.
https://software.intel.com/en-us/articles/simd-made-easy-with-intel-ispc

The current SSR solution is not optimal. The stochastic approach should yield better looking results.
https://www.ea.com/frostbite/news/stochastic-screen-space-reflections

I left out the precomputed BRDF for the specular term. This should also be considered
https://learnopengl.com/PBR/IBL/Specular-IBL

A benchmarking system, that will measure every sub-system will help detect problem areas.

Something like this https://www.youtube.com/watch?v=xlAH4dbMVnU

Although Deferred Rendering performes better than Forward rendering, since shading is deferred to the end of the pipeline, when all valid fragments are determined, it still can be expensive to shade all final fragments with a large number of lights.
This can be optimized by dividing the depth buffer into tiles represented by the frustum formed by the near, far and the frustum sides defined by the tile position. Through a compute shader the min and max depth in said tile can be computed and the frustum near and far planes should be adusted accordingly. This gives us a tight frustum representation of a tile, which we then can test against light bounds to check if a light would affect this tile.

https://www.ea.com/frostbite/news/directx-11-rendering-in-battlefield-3

In 99% of the cases the index buffer consists of liear incrementing values. If we instead change it to a deltas, the sequence will mostly consist of 1s, which will greatly increase the compressability.

GDC Talk

An easy logging API that will eliminate direct std::cout calls. Should allow for options:

• default
• info
• warn
• error

Timestamps should also be included. Logging should be completely deactivated with macros or redirected to a log file.

The shadow camera needs to be updated according to the view frustum

The current ECS implementation stores the different components inside the Entity. This can be improved by storing the components according to their type into a vector inside their respective system. This would result in an uniform memory layout and cache friendly fetching when iterating over components from the same family such is the case for Physics objects, Mesh Components etc.

Frustum culling will improve rendering performance by discarding geometry that lies outside of the frustum.
http://www.lighthouse3d.com/tutorials/view-frustum-culling/