Layered rendering with compositor(s)

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


User avatar
bishopnator
Gnome
Posts: 350
Joined: Thu Apr 26, 2007 11:43 am
Location: Slovakia / Switzerland
x 16

Layered rendering with compositor(s)

Post by 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?

User avatar
bishopnator
Gnome
Posts: 350
Joined: Thu Apr 26, 2007 11:43 am
Location: Slovakia / Switzerland
x 16

Re: Layered rendering with compositor(s)

Post by 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.