12.11.2015 Meet Summary

#12.11.2015 NFEngine Meet Summary

##Low-level renderer

###Textures and samplers binding (OGL vs D3D)

There are two issues regarding binding in OGL vs in D3D:

1. HLSL separates Texture and Sampler, which allows for various combinations, ex. binding only one Sampler and using it with multiple Textures (GLSL requires rebinding same Sampler Object to multiple Textures). GLSL joins the two into one "sampler" uniform - this comes from old OpenGL times where sampling parameters were connected to texture and set by glTexParameter functions. Binding an OGL3 Sampler Object overrides glTexParameter settings, however in GLSL there were no such changes introduced. For OpenGL sake, in D3D we must "emulate" Texture and Sampler being the same HLSL elements.
2. Even though OpenGL contains per-shader limits for bound objects (ex. Textures), there is no way to bind an object per shader, only per shader program. To resolve this situation and match D3D behavior, OGL Renderer will have to calculate offsets between these limits and bind objects accordingly. Unfortunately, D3D12 complicates the situtation even further with the use of Root Signatures, Description Tables and Descriptor Heaps. This will require further investigation in order to resolve the problem for D3D12.

WB photo related to above issues:

###Writing to buffers (other than Uniform Buffer) in OGL4

Will be implemented in OGL4 Renderer soon.

###Shader mix-and-match support

Mix-and-match (aka. SSO on OpenGL4) will be removed, along with SetShader Renderer API. Additionally, this will allow us to match with D3D12 behavior (which has no shader mix-and-match at all).

###LOG_ERROR() in TranslateXXX()

LOG_ERROR will be removed from TranslateXXX() functions in OGL4 Renderer.

##Window event filtering (ImGui issue).

Current implementation assumes following event progress in main loop:

Window::ProcessMessages -> Engine::Advance

This needs to be split, because ProcessMessages gathers and applies events before ImGUI has any chance to react. New workflow should go as follows:

1. Window::ProcessMessages should only gather what happened inside Window.
2. ImGUI should be updated according to these events.
3. nfEngineDemo should process input only if ImGUI is not in the way (there is a flag inside ImGUI which can tell us about this).
4. Engine::Advance, which will draw everything that is needed.

So, in pseudocode (names are subject to change):

Window::ProcessMessages -> View::DrawGUI -> Demo::ApplyInput -> Engine::Advance

##Engine config:

###Global config (search paths, renderer settings, etc.)

Global config will be kept with JSON-like language. A parser and data translator will be needed to easily access the settings.

###Per-view config (postprocess, etc.)

Requires serialization to text. Probably the best solution will be to add a Serialize method to View, which will dump all the data to OutputStream object. See below to check which components/systems/resources are to be serialized.

###Per-system settings (physics options, rendering settings, etc.)

As above, requires serialization to text/binary. A collection of all components, systems and resources (implemented and not) was gathered and is attached below.

##Asserts

Asserts will be used only in internal functions of the Engine, where there is 99% chance that function arguments are correct. Functions that return "void" type should assume that passed arguments are correct - that's a good place to use assert. If an assertion fails it means a bug in the engine's code - it should never fail due to user's fault.

##Components, systems and resources

As a bonus during Config brainstorm, we built a list of components, systems and resources, which are implemented and those to be implemented.

WB photo: