Issues with MSAA - why set the render window to have MSAA!??

Problems building or running the engine, queries about how to use features etc.
Post Reply
al2950
OGRE Expert User
OGRE Expert User
Posts: 1104
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 45

Issues with MSAA - why set the render window to have MSAA!??

Post by al2950 » Sat Jan 20, 2018 3:13 pm

I am actually digging around an issue with using open VR which spits out the following 'hidden' error, which actually gets caught by Ogre at a different point;

Code: Select all

ERROR: ID3D11DeviceContext::CopySubresourceRegion: If CopySubresourceRegion is used with Multisampled or D3D11_BIND_DEPTH_STENCIL Resources, then the source and destination Subresource must have the same dimensions.
Anyway this got me thinking about how I set up my MSAA render targets. In short I always resolve my MSAA render targets early, before any post processing, however in Ogre MSAA settings are always based on the final render target settings. This seems, well wrong. Am I missing something?? I appreciated this may be a hang over from old school FFP.

Am i wrong in saying that in my setup the final render target should NOT be MSAA, but i should be able to setup scene render targets to have MSAA which I explicitly resolve later before the final render target?

PS. I am using Ogre 2.1, not sure if Ogre 2.2 may help with this issue...
Last edited by al2950 on Sat Jan 20, 2018 9:19 pm, edited 1 time in total.
0 x

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

Re: Issues with MSAA - why set the render window to have MSAA!??

Post by dark_sylinc » Sat Jan 20, 2018 8:46 pm

From the December 2017 report:
Another change for example that in Ogre 2.1 all render textures in the compositor default to using MSAA if the main target is using MSAA. In Ogre 2.2; we default to not using MSAA unless told otherwise. We found out most textures do not need MSAA because they’re postprocessing FXs or similar; thus the MSAA is only a waste of memory and performance by doing useless resolves. Therefore only a few render textures actually need MSAA. This saves a lot of GPU RAM and some performance.
So in short, you're right. You're also right that 2.1's handling of MSAA is very old school (FFP era) and treats it like an esoteric magic black box.
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1104
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 45

Re: Issues with MSAA - why set the render window to have MSAA!??

Post by al2950 » Sat Jan 20, 2018 9:21 pm

Thanks for the confirmation.... I guess its about time I get 2.2!

Quick question re 2.2, I shall assume cubemap arrays are supported, but does this mean that we have per pixel reflection probes, or is it still per object?
0 x

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

Re: Issues with MSAA - why set the render window to have MSAA!??

Post by dark_sylinc » Sat Jan 20, 2018 9:25 pm

al2950 wrote:
Sat Jan 20, 2018 9:21 pm
Quick question re 2.2, I shall assume cubemap arrays are supported, but does this mean that we have per pixel reflection probes, or is it still per object?
That's one of the things I want to tackle next, in the short term (for the moment it's still per object, like 2.1)
0 x

xrgo
OGRE Expert User
OGRE Expert User
Posts: 892
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 49

Re: Issues with MSAA - why set the render window to have MSAA!??

Post by xrgo » Sun Jan 21, 2018 1:14 am

dark_sylinc wrote:
Sat Jan 20, 2018 9:25 pm
al2950 wrote:
Sat Jan 20, 2018 9:21 pm
Quick question re 2.2, I shall assume cubemap arrays are supported, but does this mean that we have per pixel reflection probes, or is it still per object?
That's one of the things I want to tackle next, in the short term (for the moment it's still per object, like 2.1)
I will extremely love that, please please
0 x

Post Reply