Understanding new compositor system.

[Crashy]

Hi,
I think many people have the same questions regarding the new compositor system, so here is a topic to ask about it.

First, I'm having troubles with some details in the fresnel nodes:

Code: Select all

compositor_node FresnelLastPass
{
	//Make the reflection & refraction textures available so they can be used by materials
	in 0 reflection
	in 1 refraction
	in 2 rt_renderwindow

	target rt_renderwindow
	{
		pass clear { colour_value 0 1 1 1 }
		pass render_scene { lod_update_list off }
	}
}

Why is there a render_scene ? The "SampleBrowserWorkspace" workspace already do the render scene pass, what's the point here?
From what I understand, the "connect FresnelRef FresnelLastPass" line connects the 0 and 1 outputs of the "FresnelRef" node to the 0 and 1 inputs of the "FresnelLastPass", I'm ok with that, but why is there a render scene?
Does this actually render the scene or is this just a "trick" to have the reflection and refraction textures ready before the scene is rendered ? Does this overwrite the previously declared render_scene node of the "SampleBrowserWorkspace"?

Let's say I would want to make it the old way: using compositor workspaces as I used render to textures before, I think I would have made 2 workspaces, one for the reflection and one for the refraction, doing something like this:

Code: Select all

compositor_node reflectionNode
{
       in 0 reflection
       target reflection
	{
		pass clear { colour_value 0 1 1 1 }

		pass render_scene
		{
			//Filter underwater objects (optimization) and other stuff that shouldn't be reflected (vampires?)
			visibility_mask		0x00000004
			
			identifier			59645

			overlays			off
			rq_last				94

			lod_update_list		on
			//lod_bias			2.0
		}
	}
}

workspace FresnelSampleWorkspace
{
	connect_output reflectionNode 0 
}

And in C++:

Code: Select all

reflectionTexture = TextureManager::getSingleton().createManual(getUniqueID("reflectionTexture "), "ResourceGroup",
				TEX_TYPE_2D, 512,512, 0, PF_A8R8G8B8, TU_RENDERTARGET);
renderTarget = reflectionTexture ->getBuffer()->getRenderTarget();


//Set up compositor, with the quick and dirty way
Ogre::CompositorManager2 *compositorManager = Ogre::Root::getSingleton().getCompositorManager2();

const Ogre::IdString workspaceName( "ReflectionRenderingWorkspace" );
compositorManager->createBasicWorkspaceDef(workspaceName,Ogre::ColourValue::BLACK);
Ogre::CompositorWorkspace* workSpace = compositorManager->addWorkspace(sceneManager, renderTarget, camera, workspaceName, true);

And of course the same for the refratction. Is this ok ?


Another question with the cubemaping sample:

Code: Select all

CompositorChannel channel;
        channel.target = tex->getBuffer(0)->getRenderTarget(); //Any of the render targets will do
        channel.textures.push_back( tex );

Reading the doc, I understand that the .target is to tell the compositor workspace in what target he will render, and the .textures what textures are used as inputs for the workspace. Is this correct?
Why is the channel.textures specified? The various compositor nodes never take an input texture,

Thank you for any answer, I'm very enthusiastic regarding Ogre 2.0 but this whole compositor stuff is totally changing my understanding of Ogre.

[dark_sylinc]

Hi! Thanks for posting your doubts.

I see your main source of confusion. The sample browser disables (or destroys? can't remember) the workspace "SampleBrowserWorkspace", and the sample being loaded has to create a new workspace; otherwise nothing will be rendered (the screen will suddenly halt and show whatever was last rendered)

The Fresnel sample loads its own workspace (defined in a script*) called "FresnelSampleWorkspace".
The Fresnel sample has a total of 3 passes:

• The refraction pass to an RTT (defined in FresnelRef).
• The reflection pass to an RTT (defined in FresnelRef).
• The last pass that renders to the RenderWindow and uses the two previous RTT for effects (defined in FresnelLastPass)

Now, if SampleBrowserWorkspace were to be also working at the same time as FresnelSampleWorkspace, then it will depend in the order in which the workspaces have been created (unless you filled in the 'position' parameter of CompositorManager2::addWorkspace):

• If SampleBrowserWorkspace comes first, the scene will be rendered "normally" to the render window, then FresnelSampleWorkspace will clear the contents of the render window (because of its clear pass) and then overwrite with pass scene. In other words, SampleBrowserWorkspace will be wasting cpu & gpu cycles. If there were no clear pass, Ogre would try to render on top of what's already on the render window.
• If FresnelSampleWorkspace comes first, exactly the opposite will happen: the window will be rendered with fresnel and other fancy effects, and then its contents will be cleared and rendered normally, again wasting cycles and probably it won't look as you would expect.

There's also the possibility that you could get an exception when rendering with SampleBrowserWorkspace because IIRC the water material are using compositor_type textures, and because these compositor textures are visible within a node scope (within Workspace scope if they're global), these textures won't be available and Ogre will complain.

(*) I can see the comments in the script saying the workspace is recreated from C++; but I don't see the code doing so, mm... an oversight.

Let's say I would want to make it the old way: using compositor workspaces as I used render to textures before, I think I would have made 2 workspaces, one for the reflection and one for the refraction, doing something like this:

Your code seems correct. Note that as I said above, IIRC the materials are using compositor_type textures, so you would have to take care yourself of feeding the texture units with the right RTTs in the last pass (which is what you would do in Ogre 1.x).

Reading the doc, I understand that the .target is to tell the compositor workspace in what target he will render, and the .textures what textures are used as inputs for the workspace. Is this correct?
Why is the channel.textures specified? The various compositor nodes never take an input texture

You're correct that in this sample no node is using it as input, so it isn't strictly required. But this is totally feasible (i.e. you later customize the compositor and you end up using it as input).
If some node tries to use the texture as input, you would get a null pointer crash; hence it's why the sample fills the .textures member.

Edit: I just saw the code again, filling the ".textures" memberg is needed because otherwise the Compositor has no way to know the target is a cubemap and can select the faces (which is needed for the "target cubemap +X" syntax to work).
This is a constraint made by how Textures and RTTs are separated and work in Ogre.
And that's why "//Any of the render targets will do" comment is there. The Compositor needs a valid pointer as RenderTarget, but for cubemaps the final target selection is actually made from the .textures component (unless you don't use the +X; +Y; -Y; etc syntax).

[Crashy]

Thank you very much, this is clearer now !

I had some doubts with this new system but now I've seen more about it, it seems easier to manage all the render to textures as everything is "centralized" in a few compositor scripts.