[2.x] Come up against a Compositor limitation, :(

[al2950]

This may be thought of an edge case, but its got me a bit stumped. I have a custom pass that renders my ocean, and I want to render a reflection plane for the ocean, which needs to know what camera is being used for the rendering, which is only known when rendering that pass... I could try and describe the problem and the various walls I have come up against... but.....

Ideally I would like to define a 'reflection' compositor node which is referenced from my custom ocean pass, just like how ShadowNodes are used. Could we expand the concept of shadow nodes to be used more generally, so custom passes like mine (or even future Ogre passes) can add there own compositor nodes that are not necessarily part the compositor graph??

[dark_sylinc]

Could you explain the nature of your algorithm with some pseudo code?

I'm having trouble understanding this:

which needs to know what camera is being used for the rendering, which is only known when rendering that pass..

[al2950]

Yes, sorry, was trying to be brief, but I guess too brief!

I have 1..n cameras, each assigned to a different compositor instance. During rendering of each camera I have compositor node that looks like this

Code: Select all

compositor_node SimpleRenderNode
{
	texture sceneRender target_width target_height PF_FLOAT16_RGBA depth_format PF_D32_FLOAT depth_texture depth_pool 5 explicit_resolve
	target sceneRender
	{
		
		pass custom SKY
		{}	

		pass render_scene
		{
			shadows	ShadowNode
		}
		
		pass custom CLOUDS
		{}
		
		pass custom OCEAN
		{}
	}
	out 0 sceneRender	
}

Now, 'pass custom OCEAN' needs a reflection texture before it renders, this could be done in a number of ways;

• define another texture in SimpleRenderNode, and render and perform render_scene and CLOUD passes on it. eg

  Code: Select all

  compositor_node SimpleRenderNode
  {
  	texture sceneRender target_width target_height PF_FLOAT16_RGBA depth_format PF_D32_FLOAT depth_texture depth_pool 5 explicit_resolve
  	texture reflectionTex 1024 1024 PF_FLOAT16_RGBA 
  	
  	target reflectionTex 
  	{
  		pass custom CLOUDS
  		{}
  		pass render_scene
  		{
  			shadows	ShadowNode
  		}		
  	}
  	
  	target sceneRender
  	{
  		...
  		
  		pass custom OCEAN
  		{
  			relfections reflectionTex 
  		}
  	}
  	out 0 sceneRender	
  }
  

  I dont like this version because I have quite a few different 'scene render' nodes, and I dont want have to duplicate the reflection updates in all of them
• Create another compositor node for reflections, and add it to the workspace graph and consume it in the SimpleRenderNode OCEAN pass.
  This ones works fine, but when doing things like VR, I want to use the shared culling camera and only update the reflections once for the 2 eyes.
  Now I could define a special relfection node for VR, and this is currently where I am heading.
• When a OCEAN pass is instantiated it instantiates its own workspace with a specific camera, and makes sure its updated before the current workspace.
  This feels a bit dirty and may cause issues inside Ogre (initializing a workspace while another is half way through being initialized), also camear settings will have to be copied and updated every frame, instead of just saying 'currentCamera->enableRelfection'

What I really want to be able to do is somehting like this

Code: Select all

compositor_node SimpleRenderNode
{
	texture sceneRender target_width target_height PF_FLOAT16_RGBA depth_format PF_D32_FLOAT depth_texture depth_pool 5 explicit_resolve
	target sceneRender
	{
		
		....

		pass render_scene
		{
			camera 		left_eye
			cull_camera	shared_cull_camera
			shadows		ShadowNode
		}
		
		pass render_scene
		{
			camera 		right_eye
			cull_camera	shared_cull_camera
			shadows		ShadowNode reuse
		}		
		
		
		pass custom OCEAN
		{
			camera 		left_eye
			cull_camera	shared_cull_camera
			reflections 	reflectionNode
		}
		
		pass custom OCEAN
		{
			camera 		left_eye
			cull_camera	shared_cull_camera
			reflections 	reflectionNode reuse
		}		
	}
	out 0 sceneRender	
}

The problem is I have quite a few custom passes, so I dont get the benefit of some of the built in functionality of Ogre. You could say I am just an edge case, but I do think the concept of shadow nodes would be useful as generic functionality inside the compositor.

[al2950]

ok, this officially driving me nuts!

The only solution I can use is to generate a new compositor when I instantiate a OCEAN pass, which just sucks for many reasons

The reason I can not use any other idea is that I need to change the settings of the main rendering cam before rendering scene, which is not possible when doing something like pass scene_render.

I also thought that allowing pass to update a specific compositor node if they want would also be useful for GUI's in particular MyGUI. You probably only want to specify a single MYGUI pass in your compositor, but MyGUI (during render) decides there and then if it needs to update some RTTs. These RTTs would fit nicely as compositor Nodes, which can be updated from the MYGUI custom pass.

[dark_sylinc]

[*] When a OCEAN pass is instantiated it instantiates its own workspace with a specific camera, and makes sure its updated before the current workspace.
This feels a bit dirty and may cause issues inside Ogre (initializing a workspace while another is half way through being initialized), also camear settings will have to be copied and updated every frame, instead of just saying 'currentCamera->enableRelfection'
[/list]

This is what feels the right way given the flexibility you're seeking. When creating workspace N, insert a workspace N-1 (or N-2) to update the reflection itself.
Workspace N can receive inputs from workspace N-1. It has been quite a lot of months since "connect_output" was changed to "connect_external N" to allow more than one input/output; since having just one was not enough.

Terrain's shadows work in a similar way: they get their own workspace to work on and update the shadows via a compute shader, and these results are later used in regular workspaces inside pass scene passes.

Having a node inside a node (like shadows) is not a good idea. It already felt dirty when I did it, and there were a lot of safeguards I had to place (because a node is literally interrupting its execution to start another sequence of nodes; it also breaks any potential assumption that a pass = one render target).
Shadow nodes happen to work fine; but it wasn't the best decision ever done.

[al2950]

Having a node inside a node (like shadows) is not a good idea. It already felt dirty when I did it, and there were a lot of safeguards I had to place (because a node is literally interrupting its execution to start another sequence of nodes;

I was worried you might say something like that

Thanks for info/opinion