petiaccja / inline-engine

Game engine written in C++ with ease of use and next-gen parallel computing in focus.

Inline Engine

Introduction

Inline-Engine is a modern game engine that emphasizes the latest technologies and innovation in order to bring the most to the table regardless of weather you are a gamer, a developer or a game designer. It got its name from the overuse of inline methods to speed up the software, however, it only aims to live up to the performance expectations not the poor coding style.

• C++17 brings elegant coding solutions
• Built for parallelism from the ground up
• Build for DirectX 12 and Vulkan
• Modular, hackable design
• Highly configurable even without hacking

Platforms

1. Windows (supported)
2. Linux (planned)
3. XBoxOne (planned)
4. PS4 (planned)

How To Build

Visual Studio solution files:

1. Download Visual Studio 2017 or 2019 preview with the latest updates
2. Download the latest CMake (3.10 or newer)
3. Generate Visual Studio 2017/2019 Win64 solution files via CMake for Inline-Engine/CMakeLists.txt
4. Open solution files and build

CMake via IDE:

1. Install latest MSVC 19 toolchain
2. Download a CMake compatible IDE (e.g. Visual Studio or CLion)
3. Open Inline-Engine/CMakeLists.txt
4. Configure CMake within IDE to use the MSVC toolset
5. Build

CMake via Ninja or makefiles:

1. Install latest MSVC 19 toolchain
2. Download the latest CMake (3.10 or newer)
3. Generate Ninja or Makefile for Inline-Engine/CMakeLists.txt
4. Build

Note: you can not compile it with the GNU toolchain because the Direct3D libraries won't compile, and Vulkan is not supported yet.

Note: you don't need any additional dependencies, all libraries are packed with the project.

Note: 32-bit build are not supported

Rendering core ideas

High-level interface

The engine exposes geometries, material, and textures to work with. These are used as properties to describe an entity. Entities are grouped into multiple scenes that act like a virtual world. One might put terrain entities, lights, geometries or other types of objects into a scene. The purpose of having multiple scenes is to achieve the separation of 3D world, GUI and debug draw objects. With this, one might define completely different ways of rendering each scene, and can quickly toggle whether to display a scene at all. The results of each scene can be freely combined with desired final output.

Visual render pipeline scripting

Inspired by CryEngine's flow graph and Unreal's BluePrint, users can leverage the power of task graphs to visually assemble the render pipeline. The task graph's tasks have access to the scenes and the objects inside them, so they can render it. The data flow from one task to the other allows the transport of opacity or depth maps which make combining scenes in an arbitrary fashion a breeze.

Adding your own rendering algorithms

The above-mentioned rendering task graph provides an interface to implement custom task nodes. The nodes inputs and outputs are defined, and the programmer can code the data transform performed on the inputs. The node can access the underlying Direct3D 12 API through a simplified interface. The framework that executes the task graph takes the responsibility of distributing work across multiple CPU cores and the scheduling of generated GPU command lists.

inline-engine's Issues

2D rendering support

text and rectangle entities at minimum

Add GBuffers in some cultured form

Plan A - the automatized real deal
Throw together a bunch of material shaders with multiple outputs, and the system figures out the ideal layout for the materials' outputs. The forward renderer then creates a gbuffer of such layout, and generates code to write into and read from the gbuffer.

Plan B - the flexible manual way
The gbuffers layout is specified by hand, and an HLSL API is given to materials to #include. Through the API, material shaders can manually access and write the gbuffer.

Color<T> arithmetic operators return references

BaseLibrary/Color.hpp

are you Looking For Next Gen 3D Game Engine Volunteer C++ Programmer ?

Volatile and non-volatile pipeline resources

Let nodes create resources that lose or retain their data for the next frame. These will be backed by the PIPELINE and CRITICAL memory heaps.

Note:
Upload and download resources dropped because of synchronization issues.

Infinite loop/race condition in coro Fence

I don't know why, but the putback loop gets into an infinite loop due to a circular list.

"JobSystem - Mutex", "[JobSystem]"
Line 175: syncBack.WaitExplicit(1);

Logo Proposal

Hello! I'd like to contribute to your project by designing a logo for it. If you'd want that too, please let me know if there are any specific things you'd want this logo to represent, and if you don't have any I'll just implement my own ideas. Looking forward to hearing from you :)

Make forward render parameters optional

The nogi pipeline crashes because the forward render tries to access empty input ports (screen space shadow). SS shadow should be an optional input.

About the invitation email...

Today I got an email from [email protected], asking me to join developing this engine, I am curious about the engine roadmap and structures , afaik it seems like you are targeting dx11 capable gpus? (with tessellation) which immediately breaks compatibility on mobile devices and macos is that right? If not I am sad to tell you I can't join because "indie & beginner not AAA titles" mobile gaming is way bigger than pc or even console and the revenue is much larger especially to startup promising engines like this.

Also why did you select me? Or did you just send an email to many other by bot?

Make sure nodes work without a directional light in scene

Scene might not have a directional light. Nodes have to work without it. Can't crash or assert.
Nodes affected:
forward render
draw sky
csm
screen space shadow
voxelization

FAIL check missing from GraphicsApi::CreateCommittedResource.

Normal mapping support

support for additional per-vertex attributes (loaded from file): normal, tangent, bitangent

DepthReductionFinal crashes

If no directional lights are added to the scene the above-mentioned node crashes instead of writing an empty output.
Crash, exception and assertion are not acceptable. A scene may not contain directional lights.

Hooks/Phases/Stepsfor Simulation

Why not allow Simulation to have an array of Hooks alongside the usual array of Systems. The Hooks could call PreRun and PostRun passes in Systems which support them, so the things like the ActionHeap could be implemented in a nicer fashion as a Hook instead of hacking into every system that cares. Generally speaking, Hooks can relay information between and within Systems just like Systems relay information between and within entities.

Implement pipeline resource upload/download

User can upload resources properly, the pipeline can not.
Allow pipeline to create resource for rendering, static, upload and download.

Track root signatures and PSOs along with resources

Command lists already keep a reference to resources so that when the user deletes them, pending pipeline operations will have them available. Root signatures and PSOs are not tracked, so nodes can't simply delete them on the fly.

Dangerous use of statics

ScreenSpaceAmbientOcclusion:28
static int temporalIndex = 0;

You do NOT ever ever ever ever ever ever ever ever ever use statics to store persistent class-scope read-write data, because it is ugly. Furthermore, it will crash as soon as two instances of the class exist, especially in a multithreaded environment. And no, thread_local is just as bad.

Make gxeng Scheduler pull-based

Would be nicer to Setup/Execute nodes on a pull-based fashion, starting a coro for each sink that co_awaits for all the incoming nodes.

Add user cubemaps

Naming style

Establish naming conventions.

Integrate with Code Quality Services

I suggest after handling #21 and #22 and afterward:

Try to integrate with a few Code Quality free services:

• https://codecov.io
• https://www.codacy.com
• https://codebeat.co

That way you'll have an overall perspective (though not a complete one) of the codebase health/quality status at all times.

Also, add the badges of those services to the README. It always adds to the credibility of the project.

/cc @petiaccja @Yours3lf @hsdxpro

support for cube map shadow maps

support for rendering to cube map shadow maps
support for sampling cube map shadow maps

Pipeline refactor

Refactors

DepthReduction + DepthReductionFinal + CSM: nobody else uses intermediate results of these nodes, merge them into a single node.

ForwardRender: waaaay too big and too many inputs, consolidate into fewer, more descriptive inputs. I.e. forward render could get shadow multiplier texture instead of all CSM bullshit. Consolidate CSM bullshit into one struct or one texture input, whichever easier. Make inputs optional: forward render should work without CSM & SS shadows. Pass through depth map, and make input depth prepass optional.

Voxelization: waaaaay to big, bloated, and breaks single responsibility. Break apart into Voxelization (produces voxels from scene, input: scene, camera; output: volume texture), VoxelGI (inputs: voxels, maybe scene, output: illumination voxel field or screen space texture), CombineLighting (inputs: gi texture, ssr texture, ssao texture, fw render out, etc.; output: proper lighting).

DofPrepare, DofTileMax, DofNeighborMax, DofMain: nobody else uses intermediate results (and ever will), merge them into a single node.

HDR:

• BloomDownsample: replace with generic downsample filter bank (input: texture, factor, repeatCount; output: vector of downsampled textures)
• LuminanceReduction & LuminanceReductionFinal: merge into one node (SceneLuminance)
• BloomBlur & BloomAdd filter bank: merge into one node (Bloom)
• LensFlare & BloomBlur & BloomBlur: merge into one node (LensFlare)
• HDRCombine: delete this node
• ToneMapper: inputs: hdr texture, parameters (i.e. luminance key); output: tone mapped image
• ToneMapper gets its hdr input texture by adding (bloom + lensFlare + normalImage) into one single texture

GetEnvVariable: nodes should NOT use GetEnvVariable to receive images and lookup tables from outside which can in no meaningful way be altered by the user. I.e. SMAA lookup tables can never be altered, they are part of the algorithm.

• SMAA
• HDRCombine (suspected)
• LensFlare (not an issue): lens flare texture is a valid use case, but should be optional
  Load textures from header files directly inside the node.

Debug draw

Debug draw must be implemented properly. I.e. graphics engine makes a scene available to all nodes, where they can put debug objects, and draws it automatically at the end of the frame. Current thing is a huge mess.

Methods

Code shared between different nodes
Factor such code out into its own class, and use that class inside multiple nodes.

DepthReductionFinal

Components

Missing port names
Use Binder instead of optional
Don't store input port values as member variables (m_camera, m_suns), query in Execute()
Shader: Don't rewrite all utility function such as creating matrices

Header

Bunch of commented code snippets

Implementation

Factor out binder creation to its own function.
Factor out CSO creation.

Code style

Naming conventions violated:

• cpp/Uniforms
• cpp/InitRenderTarget textures
• cpp/Execute vectors
• shader/Uniforms
• shader/all function names
• shader/local variables
• shader/literally everything is wrong
• shader/one letter variables, like loads, especially in loops
• cpp/vp is not a name, viewProj is

Not compiling

C:\Users\dark\Desktop\Inline-Engine-master>cmake .
-- Building for: Visual Studio 15 2017
-- Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299.
-- The C compiler identification is MSVC 19.14.26429.4
-- The CXX compiler identification is MSVC 19.14.26429.4
-- Check for working C compiler: E:/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x86/cl.exe
-- Check for working C compiler: E:/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x86/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: E:/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x86/cl.exe
-- Check for working CXX compiler: E:/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.14.26428/bin/Hostx86/x86/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning at Paths.cmake:18 (message):
  Unhandled architecture.
Call Stack (most recent call first):
  CMakeLists.txt:22 (include)


External libraries not found at C:/Users/dark/Desktop/Inline-Engine-master/Externals/lib_unknown_Debug!
CMake Error at Paths.cmake:28 (message):
  Please compile external libraries for MSVC on x86.
Call Stack (most recent call first):
  CMakeLists.txt:22 (include)


-- Configuring incomplete, errors occurred!

External folder:

Add stack trace to exceptions

kinda straightforward, ehh? baselib already has instant stack trace getter

Default namers for mtl shader nodes

Name clashes and shader compilation errors arise when, i.e., two MapColor2D's are placed in a MaterialShaderGraph. This is because both nodes' input port is called "__map" in HLSL.

Add default namers to fix the problem, or throw a meaningful exception when name clashing occurs.

fix full mip chain allocated and used for voxels

voxels appear as black because lower mip levels are empty

Error handling guidlines

How should we handle errors? Exceptions, error codes, when to assert etc.

Clean up entity resources

Use shared_ptrs instead of raw ptrs to store Mesh and Material etc in entities.

Add resource copy watcher to the pipeline

API and design improvements for gxeng node system

So... the node system wanted to be everything but got a little twisted.

Issues while creating a render node:

1. getting inputs/outputs is ugly: GetInput<0>().Get() uhh
2. passing data from Setup to Execute via member variables
3. buffers cached internally until input size changes (checks are ugly)
4. Reset is cumbersome, often forgotten -> unwanted swapchain refs
5. member variables are:
   • PSOs
   • Binders
   • RTVs/DSVs/SRVs
   • non-transient resources: vbs, ibs, textures

Solutions:

1. Either rename methods or change system.
   • Use GetInputPort<0>() and GetInputParam<0>().
   • InputPortConfig<Args...> should have Update(Args...), and make framework do the ugly work
2. Setup return std::any -> which is passed to Execute, contains all per-frame state
   • creating buffers is cheap (cached or placed resources)
   • creating views is (is it?) cheap: only a few in numbers
3. Caching not needed with 2., or simply done externally in scheduler
4. • views and textures no longer need to reset (passed via 2.)
   • PSOs, Binders are reset situationally, no refernce to swapchain
   • inputs which are connected can be automatically cleared
5. member variables would be:
   • PSOs
   • Binders
   • non-transient resources: vbs, ibs, textures

Create an markdown file of the pipeline document

I'd suggest creating a markdown file of the pipeline written in English.

Plus update the document's content to the current status.

/cc @petiaccja @Yours3lf @hsdxpro

Add port names to nodes

Node and node editor now support port names. Add them to all nodes by overriding appropriate methods.

support for GPU skinning

support for loading animations from file, computing matrices on the cpu and calculating animated vertices on the GPU (or CPU)

support for loading 3D textures from disk for color grading

DepthReduction

Componenets

std::optional -> use Binder simply
Port names missing

Implementation

SetWorkgroupSize

Non-descriptive parameter names (w,h,gw,gh etc)
Fullretard O(n) algorithm, use blockCount = (totalCount + blockSize - 1)/blockSize;
Use Vec2u instead of {w,h} pairs

Setup

Factor out Binder creation to its own function
Factor out CSO creation into its own function

InitRenderTarget

Changing depth buffer format may disable node (not verified)

Shader

Don't use define, use const/constexpr
Naming convention not respected (linearize_depth, init, etc.)
Clean old commented code snippets

Parallelize scheduler

Email address disabled

Not sure how else to contact you but, when I tried to respond to your email...

Address not found
Your message wasn't delivered to [email protected] because the address couldn't be found or is unable to receive email.

The response was:
550 5.2.1 The email account that you tried to reach is disabled. Learn more at https://support.google.com/mail/?p=DisabledUser j13sor990516wrh.51 - gsmtp

Add "how-to-build" info on README

Add "how-to-build" info on README so any newcomer/contributor can easily clone/fork the project and build locally.

/cc @petiaccja @Yours3lf

Clean up entity transform

Make entities have a Transform() property instead of deriving them from that ugly polymorphic transform class.

Graph Systems for GameLogic

Systems like the tranform linkage could be implemented in a more cultured fashion with generic graph systems. perhaps

Rewrite vertex helper class

It should use a similar approach to Pixel, that is, provide an external (static member) interface to access type-erased vertices. This way, vertices would not rely on polimorphism, saving a whole lot of space by dismissing vtable pointers.

License

There is no licence yet, so the code is 'const' or 'readonly', unavailable for redistribution in any form. We are too lazy to figure out which licence to add, and will not be doing so unless it becomes necessary.

You are literally saying that you don't want to be an open source project. So I have a simple question. Why?

Setup Continuous Integration

I recommend automating build process as early as possible.

Once #21 is done, try to make the build process automated on each new commit/pull-request.

There are multiple options, free for Open-source software: Appveyor (for Windows programs), Travis CI, CircleCI, etc.

Also add the respective build badge of the CI you choose, usually found on the CI project's settings.

/cc @petiaccja @Yours3lf

Implement streaming memory heap