Compositor System and MRTs

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
Post Reply
chaos creator
Gnoblar
Posts: 22
Joined: Tue May 08, 2012 5:56 pm

Compositor System and MRTs

Post by chaos creator » Mon Dec 29, 2014 11:45 pm

I'm trying to implement a simple deferred renderer with the new compositor system of ogre 2.0
It seems it should be perfeclty suited for such a task, but one central point of a deferred renderer is the need of MRTs.
And thats what I cant get to work.
Since I'm planning to render all surfaces diffuse - only not much data is needed. In fact, I only have Color RGB, Normals XY and Emission.
That should fit into two PF_R8G8B8. So I create a mrt

Code: Select all

texture mrt target_width target_height PF_R8G8B8 PF_R8G8B8
and render to it with a pixel shader which writes to SV_Target0 and SV_Target1

Code: Select all

struct PS_IN
{
	float2 UV : TEXCOORD0;
	float3 Normal: TEXCOORD1;
};

struct PS_OUT
{
	float3 rt0 : SV_Target0;
	float3 rt1 : SV_Target1;
};

Texture2D Tex;
SamplerState linSample
{
    Filter = MIN_MAG_MIP_LINEAR;
    AddressU = Wrap;
    AddressV = Wrap;
};


float2 encode (float3 n)	//Crytec's Spheremap Transform Normal Compression
{
    float p = sqrt(n.z*8 + 8);
    return float2(n.xy/p + 0.5);
}


PS_OUT test_ps( PS_IN In )
{
	PS_OUT MRT;

	float4 rawTexture = Tex.Sample(linSample, In.UV);
	
	float3 color = rawTexture.rgb;
	float l = rawTexture.a;
	float2 n = encode(In.Normal);
	
	MRT.rt0 = color;
	MRT.rt1 = float3(n, l);
	
	return MRT;
}
than again, to test the rendering process, a compositor_node is being created, which passes this MRT to a material / shader which should use it correctly (two texture units and the shader uses two Texture2Ds...)

But somehow i can't get it to work, it always crashes when rendering the first image, outputting the following error to the log:

Code: Select all

23:37:34: OGRE EXCEPTION(3:RenderingAPIException): D3D11 device cannot draw indexed
Error Description:ID3D11DeviceContext::DrawIndexed: The Pixel Shader expects a Render Target View bound to slot 0, but none is bound. This is OK, as writes of an unbound Render Target View are discarded. It is also possible the developer knows the data will not be used anyway. This is only a problem if the developer actually intended to bind a Render Target View here.
ID3D11DeviceContext::DrawIndexed: The Pixel Shader expects a Render Target View bound to slot 1, but none is bound. This is OK, as writes of an unbound Render Target View are discarded. It is also possible the developer knows the data will not be used anyway. This is only a problem if the developer actually intended to bind a Render Target View here.
Active OGRE vertex shader name: test_vs
Active OGRE fragment shader name: test_ps in D3D11RenderSystem::_render at ..\..\..\RenderSystems\Direct3D11\src\OgreD3D11RenderSystem.cpp (line 2925)

After all, if I'm not wrong the error is either me not using the compositor system correctly or Ogre not binding the MRT correctly to the shader.
Which wouldn't surprise me since especially that was basically written from scratch and propably isn't complete yet.
But that's at least in my opinion an important functionality that I really need right now - so if my suspicions are true it would be nice to add it to the already great new compositor system ;)

By the way - I tried to do the same by rendering in two passes the data to two render targets - which requires using material schemes controlled by the compositor - which i didn't got working, too.
But I only looked briefly into it :D
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4063
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 228
Contact:

Re: Compositor System and MRTs

Post by dark_sylinc » Tue Dec 30, 2014 7:24 pm

mmm... could you post the compositor script? (or the code used to generate the workspace if done from C++)
0 x

chaos creator
Gnoblar
Posts: 22
Joined: Tue May 08, 2012 5:56 pm

Re: Compositor System and MRTs

Post by chaos creator » Wed Dec 31, 2014 3:35 pm

Ooops, of course I can:

Compositor Script: http://pastebin.com/9eXkkpcH

Material used for all objects to render to the GBuffer: http://pastebin.com/YiWHzLSG
Shader: http://pastebin.com/GBD6J5WS

Material used by the Compositor to render the final image (with a temporary direct light): http://pastebin.com/6Uc50ZK1
Shader: http://pastebin.com/8WxHCXTK


In C++ I basically only set the compositor by "mCompositorMgr->addWorkspace(mSceneMgr, mWindow, mCamera, "CompositorSampleWorkspace", true);"
and when calling "mRoot->renderOneFrame();" it crashes, writing the error to the log file.


I hope that's all the needed information, if not just ask for it ;)
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4063
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 228
Contact:

Re: Compositor System and MRTs

Post by dark_sylinc » Wed Dec 31, 2014 5:24 pm

Thank you for all those resources! Reproducing your problem was a no brainer!

It was a bug in Ogre's D3D11 render system. It's fixed in the latest commit now.
I would advise that you stick to D3D9 if you can for stability purposes. The default branch (aka 1.10) has received a lot of bugfixes to the D3D11 render system that haven't been yet merged with 2.0 (this bug was present in 1.10, but has been fixed there already.

If someone is willing to merged D3D11 changes from 1.10 back to 2.0 and submit a PR I'll be happy to accept though. Otherwise once we release the AZDO with a wholy-updated GL3+ branch I'll be probably focusing on D3D11 support.
0 x

chaos creator
Gnoblar
Posts: 22
Joined: Tue May 08, 2012 5:56 pm

Re: Compositor System and MRTs

Post by chaos creator » Wed Dec 31, 2014 6:42 pm

I have to thank you for your quick help!

I'll switch back to d3d9, that's no problem.
One of the reasons I used d3d11 was the theoretical posibillity to read the depth buffer, but Form what I've read that's not yet supported by ogre... Any plans to change that in the future (eg. when d3d9 is dropped)? I'm also curious if the performance boost is significant :D

Anyway, thanks again for your effords, keep up the great work and a happy new year! :)
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4063
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 228
Contact:

Re: Compositor System and MRTs

Post by dark_sylinc » Wed Dec 31, 2014 11:11 pm

Indeed. It's in my TODO list.

In theory D3D9 can support it too using the widely available INTZ hack.

From an interface standpoint, I have to think how it will work. It's not just grabbing the depth buffer and read from it. There are multiple things that users will want to do very often (and automatically):
  • Take the depth buffer and downsize it to a different buffer. Useful for upscaled particle rendering.
  • Take MSAA depth buffers and resolve them into another buffer.
  • Read from the depth buffer, but first copy to a different buffer. Reading from a depth buffer means decompressing it on many GPUs. Continueing to use the decompressed depth buffer for writing (i.e. rendering after you're done with soft particles) can impact performance until it's cleared.
All these tasks can be automated, and should be natural. A naive implementation could kill performance or make things overly complicated.
0 x

scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
x 2

Re: Compositor System and MRTs

Post by scrawl » Thu Jan 01, 2015 7:18 pm

The default branch (aka 1.10) has received a lot of bugfixes to the D3D11 render system that haven't been yet merged with 2.0 (this bug was present in 1.10, but has been fixed there already.
This may be a silly question, but why have the branches diverged this much? https://bitbucket.org/sinbad/ogre/branches shows 492 commits in default that haven't been merged. Are there so many conflicts that the team has given up on merging them?

Something you could look into is merging step-by-step, i.e. dividing the history of default into multiple "stages" which can be merged one after the other. You would check out the history of default at one specific point in time, branch off of it, then merge that branch.

Why did you create a new commit (https://bitbucket.org/sinbad/ogre/commi ... aa?at=v2-0) instead of cherry-picking (hg graft) the commit from default? Cherry-picking preserves the original author which would be useful if there are second thoughts or questions about the commit later.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4063
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 228
Contact:

Re: Compositor System and MRTs

Post by dark_sylinc » Thu Jan 01, 2015 11:17 pm

scrawl wrote:This may be a silly question, but why have the branches diverged this much? https://bitbucket.org/sinbad/ogre/branches shows 492 commits in default that haven't been merged. Are there so many conflicts that the team has given up on merging them?
Merging anything in OgreMain (Core) or the plugins (Overlay, MeshLod) is a minefield. Needs a lot of attention as the code diverged significantly enough.

It's not the same with the render systems though. You could take all of the 1.10's D3D/GL code, then workout the few compiler errors.
scrawl wrote:Something you could look into is merging step-by-step, i.e. dividing the history of default into multiple "stages" which can be merged one after the other. You would check out the history of default at one specific point in time, branch off of it, then merge that branch.
How's so?
scrawl wrote:Why did you create a new commit (https://bitbucket.org/sinbad/ogre/commi ... aa?at=v2-0) instead of cherry-picking (hg graft) the commit from default? Cherry-picking preserves the original author which would be useful if there are second thoughts or questions about the commit later.
Errr--- I wasn't aware of that functionality. :oops:
0 x

scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
x 2

Re: Compositor System and MRTs

Post by scrawl » Fri Jan 02, 2015 4:35 pm

How's so?
As an example, say you want to merge the changes to default up to commit d77f1f8, which was made four months ago.

hg checkout d77f1f8
hg branch default_merge0
hg commit -m "creating temporary branch for merging"
hg checkout v2-0
hg merge default_merge0

(creating the branch may or may not be necessary, I'm not a mercurial wizard)

That means everything up to that specific commit will be merged, at least. You can do as many of these "small" merges as you like so that eventually the branches will be in sync again. Basically, you have a way of catching up without having to merge everything at once. :)

Here's the first couple of (earliest) changes that aren't in v2-0, obtained via

Code: Select all

hg log -r "ancestors(default) and not ancestors('v2-0')" | less

Code: Select all

changeset:   6230:6089fd1f0952
branch:      v1-9
parent:      6228:ad9e031a7998
user:        David Rogers <masterfalcon@ogre3d.org>
date:        Sat Jan 25 10:56:14 2014 -0600
summary:     [OGRE-102] Fix flickering in the Bump Mapping sample with GL.

changeset:   6231:15926b0d8766
branch:      v1-9
user:        David Rogers <masterfalcon@ogre3d.org>
date:        Sun Jan 26 01:45:05 2014 -0600
summary:     [iOS] Using RTT’s with FSAA > 0 would result in a black screen or smaller than expected rendering. The issue is now resolved. Also did a little cleanup along the way.

changeset:   6235:5a6c32a95bb1
branch:      v1-9
parent:      6231:15926b0d8766
user:        David Rogers <masterfalcon@ogre3d.org>
date:        Tue Jan 28 00:29:03 2014 -0600
summary:     [OGRE-388] Fix issue loading shared libraries with names shorter than 3 chars.

changeset:   6237:d973a40741ab
branch:      v1-9
parent:      6235:5a6c32a95bb1
user:        David Rogers <masterfalcon@ogre3d.org>
date:        Wed Jan 29 23:26:12 2014 -0600
summary:     Use the correct function for finding periods in the dynamic lib name.

changeset:   6238:0140c966d5dd
branch:      v1-9
user:        David Rogers <masterfalcon@ogre3d.org>
date:        Wed Jan 29 23:26:59 2014 -0600
summary:     [OGRE-315] Fix crash on exit when using the memory tracker. The tracker shouldn’t attempt to record it’s own deallocation.

changeset:   6239:df96df014038
branch:      v1-9
user:        David Rogers <masterfalcon@ogre3d.org>
date:        Wed Jan 29 23:28:31 2014 -0600
summary:     [OS X] Small external window fix.

changeset:   6240:b30696af7aec
branch:      v1-9
user:        David Rogers <masterfalcon@ogre3d.org>
date:        Wed Jan 29 23:29:57 2014 -0600
summary:     Paging crash fix as suggested by Nodrev

changeset:   6252:67a56f7a7a73
branch:      v1-9
parent:      6240:b30696af7aec
user:        Glenn Ramsey <glenn@componic.co.nz>
date:        Mon Feb 03 15:16:26 2014 +1300
summary:     [OSX] Add macosx to library search path

changeset:   6253:1d6ef559a43b
branch:      v1-9
user:        David Rogers <masterfalcon@ogre3d.org>
date:        Wed Feb 05 18:22:34 2014 -0600
summary:     [OGRE-390] Fix linux build with GL state cache enabled.

changeset:   6254:d4a08fe24e0d
branch:      v1-9
user:        David Rogers <masterfalcon@ogre3d.org>
date:        Wed Feb 05 18:24:27 2014 -0600
summary:     Correct some bad OS X SDK references.

changeset:   6255:f86b95a32c48
branch:      v1-9
parent:      6252:67a56f7a7a73
user:        Jannik Heller <scrawl@baseoftrash.de>
date:        Fri Feb 07 14:03:59 2014 +0100
summary:     Change OGRE_DEFAULT_LOCALE to "C".

They seem to be simple enough to merge for a start. :)

This is also something that (in theory) the community could help out with pull requests, although one problem is that merges are difficult to look at / review. It's probably better if the team handles them.
0 x

Post Reply