VEngine

DirectX11 framework, forwards and deferred

VEngine_cover

This framework is a static library and project. Capable of rendering PBR materials in both forwards and deferred models.

It uses Directx11 for the rendering (with effects11), fbxsdk to read meshes and DDStexture loader for simple textures.

You as the user can adjust settings and play around with the scene using the simple but effective ImGUI UI. Which updates everything in realtime.

Framework

A renderer with not much baggage, able to adjust things on the fly. That was what I wanted to make. And well, although the "engine" isn't quite there yet. I did make strides towards what I wanted to achieve. It is light weight and should be able to run (albeit with limited testing) on all DirectX11 capable devices. Without having to install packages or the likes.

My intention is to expand upon what is here already in the future. Adding graphics features as I go along. And providing myself with needed engine functionality when the need for it arises. which has been the modus operandi so far at least, with an attempt to have at least some foresight of what I will need.

Features

The features provided can be split in 2 categories: graphics related and engine related. Hence, I will list them as such.

Graphics Features:

  • Deferred rendering 2 passes

  • Forwards rendering

  • Directional & point lights

  • Meshes

  • Camera

  • PBR shading model, with BRDF

  • Collecting scene data and then a lighting pass

  • Lighting gets rendered alongside the scene

  • With color and intensity

  • Having vertex color, normals, tangents, binormals, uvs

  • With adjustable FOV, near and far plane

  • TrowbridgeReitz, Fresnel, Schlick

gameplay-1 gameplay-2 gameplay-3

A note related to the shaders:

Both forwards and deferred at this point will have the same resulting image. When implementing new graphics techniques, they would both have their own unique implementations. Making it difficult to upkeep the same exact look, volumetric lighting to give an example. Hence why I probably won't try and upkeep both sides, rather implementing new techniques in the pipeline that suits the technique best.

Another small quirk of the implementation is the "limited" number of lights. The shaders have a variable defined that limits the number of lights that can be stored in the shaders. This is a temporary structure though as it is quite limiting. And can be avoided by splitting the lighting functions up, plus having multiple calls for lights.

Engine Features:

  • FBX mesh loader

  • DDS texture loader

  • ImGUI UI

  • Component and object parenting system

  • (Unfinished) Asset system

  • Materials

  • Window features

  • Using the fbxsdk from autodesk

  • Using the DDSTextureLoader

  • To adjust settings in the scene

  • Allows for reusability

  • To improve loading times and make data easer to use

  • Makes it possible to hook up shaders more easily

  • Like: fullscreen/windowed, VSync

gameplay-4 gameplay-6 gameplay-5

A note related to the assets:

The asset system can lead assets, but it would still need to make asset files. Which would have the fully parsed data inside. That way next time an asset needs to get loaded it can reference an ID, reference the number, locate the parsed file, and finally more quickly read the data. Now this does not mean that for smaller files this wouldn't give diminishing returns, but personally I am fine with that. As loading times for those are negligible anyhow. And one would rather speed up the slower files.

Right now the groundwork is laid, asset factories create assets. These factories make it easy for me to handle data before it gets used. And assets as a concept make it easy to assign this data to components, let's say for a mesh renderer. A mesh asset fits perfectly, etc.

Take a look at some of the code here, on my Github.