al2950 wrote:@dark_sylinc - Is there a plan for the includeOverlays variable in _renderPhase02
Well... the plan actually is to eventually get rid of the "includeOverlays" variable.
The plan is to refactor the RenderQueue so that IDs start at 0 until an arbitrary number (max limit is 255 though). Their meaning is set by the user. Pretty much like in Unity. But the CTP version didn't refactor the RQ; so we still have those crazy "10", "50", "96" magic numbers in the render queue.
Ideally, the user will tell the GUI plugin on which RenderQueue ID it wants the plugin to render to (which the plugin should honour) and the user prepares the compositor with the right RQ ID (another way is the plugin accepting a workspace definition and adding the passes itself).
This is very flexible because the user can control when the UI gets rendered: At the beginning, in the middle, or after other passes (from regular scene passes to compositor effects).
The reason "includeOverlays" exists is simply because it was the fastest way to get Overlays working again without breaking too many things, and the RQ refactor didn't happen yet.
N0vember wrote:Except that didn't work out of the box because I discovered there are actually already two Viewports on this RenderTarget and the correct one is the second (so at index 1). Which is strange because I surely didn't create the first one, at least not explicitly. And if the Workspace would create one, then there should be one right.
So, why would there be 2 Viewports on that RenderWindow already ?
Is that a feature or a bug ? :p
The compositor added the first Viewport. It may even add more than one.
For example in split-screen multiplayer (2 players), one pass would draw to the top half (1st player), the second pass would draw to the bottom half (2nd player). The workspace's node would have two nodes, and the compositor system will create one viewport, one for each half.
The compositor will share/reuse viewports when it can.
N0vember wrote:Could we have a bit of information on when exactly are Viewports added to the RenderTarget by Ogre ? I know it's supposed to be internal, but it's still exposed in the interface soo....
It may be worth remembering that public functions starting with _underscore mean they're for internal usage. They may be exposed either for advanced users or because of interface design limitations. That doesn't mean you shouldn't use it.
But like I said, the best method to identify passes is using compositor pass identifiers.
As for the question (when do viewports get created), inside
CompositorPass::CompositorPass, the code checks whether an existing Viewport can be used by that pass, otherwise creates a new one that can.