Layered rendering with compositor(s) Topic is solved

[bishopnator]

Hi, I would like to render set of objects in a single window layered on top of each other. E.g. in our current software, the selected objects are rendered on top of actual scene so even the selected objects behind (hidden) other objects are visible. Something like this:

1. clear the color and depth buffer
2. render objects
3. clear depth buffer
4. render objects
5. clear depth buffer
6. etc..

I am thinking between 2 possible solutions:

1. using a CompositorWorkspace per layer so the window will have multiple active compositors
2. using a single CompositorWorkspace with all nodes packed inside

Is there any difference in the performance or the functionality between those 2 solutions?

[bishopnator]

I am checking the implementation while waiting for some reasonable answer from anybody. I found just one important difference.

If multiple workspaces are used, it is up to the user to sort them (or add them) in correct order as Ogre doesn't check the inputs/outputs of the compositor workspaces between the instances inside the CompositorManager. However if it is done through nodes, the sorting is done properly inside the CompositorWorkspace according to the node connections defined by CompositorWorkspaceDef and its CompositorNodeDef.

The performance difference between multiple workspaces and using equivalent single workspace with all nodes packed inside should be insignificant.

If I think about the dynamic updates of the compositors, maybe it is easier for the Ogre to have multiple workspaces - e.g. if one layer of objects is not needed a workspace is disabled (or removed). For the single workspace, it is necessary to destroy it (with all the render textures), update the definition and then recreate the workspace. Reallocating all the textures sounds like overkill if they will be needed after recreation/reinitialization. I am aware of disabling just nodes, but it doesn't fit logically in my implementation as I call "remove layer" and from the internal implementation, the layer (with its nodes or workspaces) must be remove because it will be deleted.

[dark_sylinc]

Without knowing more specifics, it's hard to recommend "one true way" to do that.

Clearing the depth buffer like that already requires tons of load and save color actions, thus that could be slow on some GPUs.

It could be resolved with:

Multiples passes: Just define a node with N passes. The problem is that this is very inflexible.
Multiple workspaces: Just N workspaces. This is super flexible in that you can turn them on/off at a whim.
A workspace def with multiple nodes: if the number of passes changes infrequently, setup a WorkspaceNodeDef with N passes, then use 1 workspace. When the number of passes needs to change, disable the workspace, modify WorkspaceNodeDef, reenable the workspace (i.e. see Compositor sample).

[bishopnator]

I chose multiple workspaces. At the current phase of the development, it works great. Later I will try to test it is hue amount of geometry (items) and check the performance. For now, it seems like very reasonable approach - especially due to updating the definitions of the workspaces without a necessity of recreating whole rendering pipeline. Using multiple workspaces allows me to update only a single workspace and rest is unchanged.