@egparedes @bilgili FYI

from livre.

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)

from livre.

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

from livre.

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

from livre.

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.

from livre.