A deferred physically based 3D renderer into a simple to use header-only library.
#gl3d #gamedev #renderer #pbr #3d #opengl #single-file-library #c #graphics #library
|
|
1 年間 前 | |
|---|---|---|
| devUtils | 2 年 前 | |
| headerOnly | 2 年 前 | |
| resources | 2 年 前 | |
| simpleDemo | 2 年 前 | |
| src | 2 年 前 | |
| thirdparty | 2 年 前 | |
| .gitignore | 2 年 前 | |
| CMakeLists.txt | 2 年 前 | |
| README.md | 1 年間 前 | |
| atenuationFunc.png | 5 年 前 | |
| atenuationFunc2.png | 5 年 前 | |
| atenuationFunc3.png | 5 年 前 |
Retained mode, deferred BPR 3D renderer.
How to compile the repo (Visual studio 2019, Windows)
Features and todos:
Whenever the render function is called, this steps are taken:
1) Adaptive resolution size is calculated based on the average milliseconds per frame, and used for the current frame
2) The skybox is rendered.
3) The skinning matrix for the animations are calculated
4) The shadow maps are rendered (The static geometry is cached into a texture (one texture per light) and the dynamic geometry is rendered on top of the cached texture)
5) Bindless textures are setup (setting the texture id of the material, this step could also be used if I would want to controll what textures are loaded to the gpu (for now all textures are resident to the gpu memory))
6) Z pre pass if enabeled (I still have it as an option but the new deferred pipeline doesn't seem to benefit) + Frustum culling is calculated
7) The geometry buffer is rendered, this is the first step of a deferred rendering engine. I only render the geometry to a big buffer. I have the frustum culling calculated so now I know what to render and what not to render. The gBuffer looks like this in my implementaion:
my deferred material implementation doesn't render to the g buffer lighting information but rather the material index that is later used to get the texture information. This Significatly speeds the geometry pass.
The materials are all stored into a global buffer (and I also use lazyness on copy materials). The textures are sampled using bindless textures so we can draw the entire lighting pass with one draw call no matter how many materials.
This implementation would also allow for a possible future implementation of a global geometry buffer.
8) The lighting pass: the geometry information is in a buffer and now a shader will calculate the lighting information
9) Steps 7 and 8 are repeated fot the transparent geometry. No transparency tehnique is used so far but with this setup I'll probably implement a simple depth peel.
10) SSAO is calculated (ssao is calculated at half resolution for performance reasons (and if adaptive resolution is on the viewport will be even smaller than half the window size))
11) Bloom data is extracted and then blured (again half resolution). The blur works by bluring and scalind down the immage, untill it is very small, and finally adding all the mips to get the final rezult.
12) Last post proces step: (fxaa, traw to the screen the final exposed HDR rezult and chromatic aberation)
Materials are handeled by the engine using an internal id. When creating a material it will also create the associated PBR texture
Cpu entities will hold a weak refference to graphic models, and will also create gpu data (for skinning matrix)