BansheeEngine/Renderer.txt

To get it to compile:
 - Add dummy material that will be used when material is not loaded
 - Actually implement core render methods in Renderer
 - Go through all changes on commit and see if anything else needs doing

Next stage:
 - Track material changes
   - Figure out how to update material data buffers only when material actually changes (shader or parameters)
   - Should each object have their own set of buffers instead of just updating material ones per frame? Probably.
     - Although I should still have an option to use a shared block that isn't per object.
 - Add sort type, priority and separable pass options to Shader (and its RTTI)
 - Implement RenderQueue sorting with support for sort type, priority and separable pass
 - Document elements marked with TODO UNDOCUMENTED
 - Add Renderer <-> Material interface matching
   - Allow parameter blocks to be specified as one-time, per-frame, per-object, etc.
 - Actually add frustum culling

Finally
 - Refactor/rename everything so it makes more sense. Possibly lay out a design diagram.
 - Get rid of Camera::getIgnoreSceneRenderables it can be doing using layers
 - Delete RenderOperation as I don't think I use it anymore


-----------------------------------------

While I am  on this also consider working on how will parameter matching between Renderer and Material work (e.g. when rendering with 
shadows or lighting the renderer will expect materials to have certain parameters used for those effects)
 - Make it a separate GPU param buffer? RendererOneTime, RendererPerFrame, RendererPerObject


Each renderer can specify which Renderable types it supports.
 - Renderable can have various options like shadow, no shadow, animation, etc.
 - Together those options result in an Enum describing the type of Renderable

Each renderer can specify a set of parameters it needs from a material, per Renderable type
 - e.g. "Matrix4 viewProjTfrm" for BasicRenderable type

When a Material is hooked up to a Renderable is will check if the Material has the required parameters.
 - If not that object will be drawn using a dummy (most basic) shader.
 - Optionally the parameters are grouped into parameter blocks e.g. RendererOneTime, RendererPerFrame, RendererPerObject.
 - If a parameter block is detected by the renderer it will only update those parameters once when they are needed, and reuse
   them in all materials. If no parameter block is detected the parameters will be updated on all objects whenever it is changed.
 - I will potentially need to add parameter block semantic to Shader in order to make the user able to specify which blocks
   are for the renderer. (And so that Material knows not to create those buffers manually)


   ---------------------------

Just notes for later potentially:
 - I can only update entire Mesh at once. 
 - I keep bounds for the entire mesh and not per-submesh
 - I don't serialize bounds and they are recalculated whenever a mesh is loaded






















OLD:



Since DrawHelper needs to queue render commands together with scene objects (in order for transparency to work okay), I will need to implement the RenderOperation approach I thought about earlier.
 Rename current RenderOperation to SubMeshData
 Real render operations contains SubMeshData + layer (can be filtered per-camera) + queue (each mesh has a queue and another queue by camera) + Pass
 (Remove Camera->rendersSceneObjects and replace it with layer)
 (Make sure to set up preset queues, like opaque, transparent, etc)

 Then I can hook up GUIManager, OverlayManager and DrawHelper with a callback that is used by Renderer to retrieve their operations
 Attempt to move all sorting (including by render target) out of forward renderer and into an overridable sorter class
  - Create a hash list with key(containing type, queue, layer, etc.) used for sorting

  Add "materialGroup" to material. It can be used for sorting similar materials together, instead of using some automatic way of determining it.

  Issues with my render operation system:
 Sorting by depth is impossible because I don't provide any position info with my RenderOperation

 For each frame I will need to calculate world bounds and world position. I cannot do it each time I retrieve a RenderOperation so it should be cached somewhere and reused throughout the frame.
 - Unity keeps it with Renderable
   - What happens when the Mesh resource is updated?
 - How do I do it for non-renerables though?

 ---------------------

 RenderOpSorter:
 - (Before we send RenderOps to the sorter we first filter them by camera)
 - Accepts parameters whether to sort back-to-front, front-to-back or ignore depth (depth ignored with skybox and overlay)
 - Another parameter is whether to sort by pass (transparent ops can't be sorted by pass)
 - Then we sort:
  - If back to front
    - We sort by depth and that's it. We could also sort by material by that only makes sense if two elements have exact same depth which will almost never happen
  - If front to back
    - Sort by material first. We call materialSimilarity() method which returns lesser value depending how similar two materials are. We do a pass over all unsorted materials and if similarity is below some threshold we add it to the current bucket. If there are no more similar materials we create a new bucket.
    - Within bucket we sort by similarity as well (as the elements are added)
    - Then finally we sort the buckets by depth front to back
  - No depth
   - Same as front to back, without the depth sort

 - Sorter should operate directly on provided render op array