BansheeEngine/TODOExperimentation.txt

------------------------- STUDY --------------------------------
Study shadow rendering implementations
Study how is transparency handled (is it order independant?)
Figure out what is skylight
Determine how is light bleeding handled (if at all)

---------------------- IMPLEMENTATION ---------------------------

Assign ViewOrigin, PreViewTranslation, TransViewProj
 - Dont use pre-view translation for ortographic
 - Modify view and view projecion matrices so othey use translated 
 - Apply PreViewTranslation when generating world position in shader (multiply 3x3 rotation col by col, then add translation to last col and add that to rotated position)
 - Perhaps do all these modifcations outside of shader (i.e. have the world matrix be pre-transformed)
 - Do this after I have basic rendering working, to avoid additional issues when I'm initially trying to get it to work
 
Later:
 - Output skylight color in base pass (hook up color buffer as well as gbuffer as render target so I can output scene color)
  - For now just use a constant color, later add a SH environment map lookup
 - Lights already existing in scene on load don't seem to render (seems they get converted to point lights for some reason)
 - I changed how unsupported texture formats work, I should test if I didn't break OpenGL
 - When rendering lights right now I need to bind Gbuffer and light parameters to material, and then bind the material parameters to the pipeline
  - Either unify these two processes by finding a better way, or hide the binding in light material class
 - Too many depth buffers. Main render surface has one, game viewport has one and gbuffer has one
  - Disable main depth buffer by default, disable depth buffer in SceneWindow and GameWindow RT's
  - When rendering to scene target use the gbuffers depth buffer (what if their sizes don't match due to quantization?)
  - Although having an extra depth buffer won't be the worst thing as even at full HD it's only 8MB
 - Finish up DefferedPointLightPass by generating cone geometry in shader
 - Modify Light so it generated adequate number of vertices required for cone geometry, without actually creating the cone
 - Think about how to handle post-processing shaders (HDR tone mapping)
 - Add cube and 3D support for render texture pool
 - Lights aren't being culled
 - Load up and set up a test-bed with Ribek's scene

Notes:
 - When doing viewport clear in DX11 it will only clear the first render target
 - Quantize buffer sizes so they're divideable by 8 when requesting them from RenderTexturePool
 - R11G11B10 and R10G10B10A2 formats haven't been tested
 - Will need to ensure the code works in OpenGL (means porting shaders or building the cross compiler). I cannot delay 
   this as later it will be hard to debug when the pipeline is more complex.
 - Consider having a debug toggle that makes the gbuffer use floating point storage, to compare quality quickly
 - I'll need to add sky-lighting and perhaps other form of pre-computed lighting. Base pass should output colors resulting
   from those operations during its base pass.

Generate different RenderableController for each set of elements
 - Will likely want to rename current LitTexRenderableController to OpaqueSomething
 - Each controller would be connected to its own render queue (generated in above step)
 - Renderable controller should probably be notified when rendering starts/ends so it may bind gbuffer and/or other resoures.

Light queues:
 - Will likely need to generate a set of visible lights per camera similar to renderables (separate them by type most likely)
 - Will also need a set of renderables per light when rendering shadows

(Optionally) Optimize visibility determination
 - Instead of doing frustum culling + layer culling every frame do it only when renderable or camera is updated
 - I'll need to add _notifyCameraUpdated method
 - I'll need to store various queue IDs in Renderable's in order to avoid scanning the queues when adding/removing/updating
 - Since removing/adding elements would unsort the queue, sorting should be delayed and done once per-frame
 - It might just be possible its more efficient to test all elements every frame

GUI rendering can be more efficient - I re-apply all materials for every frame, while I should check if it
differs from previous material and avoid re-applying, or just re-apply the few different states

--------------------------- DESIGN ---------------------------

How will cameras interact with the renderer? The cameras currently available shouldn't have depth buffers
 - Need to modify RenderWindow so it doesn't create depth buffers
  - Find all places where I create windows and modify this
  - Modify render target creation in SceneWindow
 - What happens when a user creates a camera with a depth buffer?
   - Print out a warning and ignore it?
   - Or resolve the gbuffer into it? Probably this, as I want to be able to read the depth buffer from script code if needed
     - This still isn't perfect as I'd have duplicate buffers when using non-MSAA buffer that require no resolve
 - Similar issue when a multisampled buffer is used for the camera

Separate GUI rendering into a separate part to be rendered after gbuffer is resolved?

Will likely need an easy way to determine supported feature set (likely just depending on shader model)

Consider encapsulating shaders together with methods for setting their parameters (and possibly retrieving output)
 - So that external code doesn't need to know about its internal and do less work
 - This would contain a reference to the shader and its parameters
 - It would then have a SetParameters method (custom per each shader) which updates its params in a simple manner
 - (Later) Possibly allow them to return a feature level and/or platform they're to be used on
 - (Later) It might be important to be easily able to use different versions of the shader (e.g. different defines)
   - This might require handling compilation on this class, instead on resource load (But then again I could potentially
     have the shader in an include file and then specific shader files for each define version)

--------------------------- LONG TERM ------------------------

Deferred:
 - Create a tile deferred renderer
 - Support for point, directional and spot lights
 - Basic lambert shading initially
  - Create brand new default shaders
 - HDR, tone mapping and gamma correct (toggle-able)
   - Will likely need a simple framework for rendering full-screen effects
     (e.g. I will need to downsample scene to determine brightness here, but will
      also need that framework for all post-processing)

Implement shadows
 - Start with hard shadows
 - Move to PCF soft shadows (see if there's anything better)
 - Then cascaded maps

Later: 
 - Reflection probes
 - Proper PBR materials with reflection
 - Post-processing system - FXAA, SSAO, Color correction, Depth of field (Bokeh)
 - Forward rendering for transparent objects
 - Occlusion culling
 - GI
 - Volumetric lighting
 - SSR
 - Depth pre-pass - Make sure this can be toggled on and off as needed
 - HDR skybox, skylight stuff
 - Skin & vegetation shaders
 - Tesselation/displacement/parallax
 - Water
 - Fog
 - Motion blur
 - Per object shadows
 - Extend camera with shutter speed (motion blur), aperture size and focal distance (depth of field), exposure (HDR)
--------------------------- TEST -----------------------------

Test all APIs with new changes regarding depth buffer creation on windows