Shared textures in Compositor

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


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

Shared textures in Compositor

Post by bishopnator »

Hi, I am trying to implement a rendering where the output is cached and rendered in the main window as quad. Consider following "simple" setup:
The app has 2 windows - left window renders Nodes in RQ 50 and right window renders Nodes in RQ 51. On top of that there is another scene pass which renders a mouse cursor. Normally the rendering should be just with 2 quads in both windows using a cached output of the rendering and only mouse cursor is rendered there (as it moves frequently). Until there is no change in nodes in RQ 50 and 51, the cached texture is not needed to be updated. When I trigger a redraw in Ogre, then it should check whether there is a change in nodes of RQ 50 - if yes, re-render the scene, update the cached texture, do the same with RQ 51.

I would like to reuse the same texture for the rendering of the cached content. My problem is, that e.g. according to this post the compositors are immutable. This means that I need to hard-code the RQs and cannot change the definition afterwards.

I would like to have a system of compositors like this:

  1. compositor A to update the cached output - reused by all the windows in the app (internal textures are resized to the biggest window in the app)
  2. compositor B for left window with 1 local texture (cache)
  3. compositor C for right window with 1 local texture (cache)
  • When left window is about to be updated through compositor B, I have to check whether the cache texture is valid - if not, setup compositor A for rendering (resize textures, setup RQ ids, etc.), render it, copy result to the B's cache and then continue with rendering compositor B
  • Do the same for right window

How can I achieve this? I am struggling with all the options - whether I should create a single huuuuge CompositorWorkspaceDef and then in the instance CompositorWorkspace enable/disable the nodes, or should I separate it to multiple instances of CompositorWorkspaceDef? What about the dynamic part of the setup when I need to update the definitions?

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

Re: Shared textures in Compositor

Post by bishopnator »

I think I realized a way how to do this. I will have a single CompositorWorkspace per window, but it accepts multiple external RTs (not just a window's RT) - the window's RT is unique for each instance of CompositorWorkspace and rest are the same for all windows (shared RTs between the windows). The route of update would be to through the connected nodes - in the described example like (very brief scheme - not the actual script!):

Code: Select all

compositor_node UpdateCacheRT
{
	in 0 rt_Shared
	target rt_Shared
	{
		pass clear { .. }
		pass render_scene { .. }
	}
	
target global_MyCachedContent
{
	expose rt_Shared // pixel shader needs access to the texture
	pass render_scene
	{
		// copy in pixel shader content of rt_Shared to rt_Cache
	}
}
}
compositor_node UpdateWindowRT
{
	in 0 rt_Window
	
target rt_Window
{
	pass clear { .. }
	pass quad { .. } // display the global_MyCachedContent
	pass render_scene { .. } // display e.g. mouse cursor
}
}

compositor_workspace MyWorkspace
{
	texture global_MyCachedContent target_width target_height
	connect_external 0 UpdateCacheRT 0 // global shared RT created outside the workspace
	connect_external 1 UpdateWindowRT 0
}

In the instance of MyWorkspace I can by default have the UpdateCacheRT node disabled and through the workspace listener enables it just before rendering if it is necessary to update the content of global_MyCachedContent.

I think it could work ..