Sort-last support

[eile]

Generic feature issue to track support of the sort-last implementation in Livre.

• [x] sort-last partitioning based on the visible rendering set: #201(2ec720f)
• [x] sort-last partitioning based on the tree layout: #201 (d0fff9b)
• [ ] compositing
• [ ] sub-decomposition of non-convex rendering subsets
  • not needed if using tree-based compositing along one axis only.
• [ ] Spatial sorting of the rendering set

[eile]

@egparedes @bilgili FYI

[eile]

Decomposition strategy

Based on visible rendering set

Select all visible nodes, and then split them according to range.

Pros:

• Good rendering load balance

Cons:

• Artefacts in async mode until all is loaded (e.g. overlapping blocks between channels)
• More IO, since blocks shift from node to node

Based on tree layout

Statically partition the octtree according to the position and size of the brick in its level

Pros:

• Less IO, each node has a well-defined region of responsibility
• No rendering artefacts in async mode

Cons:

• Imbalance in rendering (Nodes away from the POV render less data and lower LOD)

[eile]

@egparedes: orderFrames in a219d44 has to be implemented correctly with the convex rendering sets.

[eile]

Sub-decomposition of non-convex rendering subsets

Equalizer API

New:

Channel::framePass( const RenderContext& ctx ) [name TBD] Add tasks to RenderContext Default impl: call clear, draw, readback as given by ctx.tasks and getOutputFrames() Livre impl: call Super::framePass( ctx.subRange( )) for each convex set

Changed:

Channel::_frameTiles refactor into tile fetch logic and new framePass( ctx ) method

[egparedes]

A first draft of the multipass implementation in Equalizer can be reviewed here: https://github.com/egparedes/Equalizer/tree/multipass

Right now, it is only working in the trivial case with only one local process, but the refactoring itself should be more or less finished.