petiaccja / inline-engine Goto Github PK

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.

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:

BaseLibrary/Color.hpp

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

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);

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.

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 :)

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

/cc @petiaccja @Yours3lf

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

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.

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

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

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.

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.

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

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

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.

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

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.

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

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

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

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

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?

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

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.

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

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

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

voxels appear as black because lower mip levels are empty

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.

Establish naming conventions.

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

text and rectangle entities at minimum

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?

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

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

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

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.