I am also in the process of porting to 2.2, and have run into some issues regarding MSAA resolves using the GL3Plus rendersystem. I am not quite sure how the implicit resolves should work, so I might very well be doing something wrong.
A scene is rendered to a MSAA "RenderToTexture" texture using a compositor workspace. This works fine. The problem appears when this texture is then mapped to another mesh and rendered into the backbuffer. Similar artifacts to what xrgo showed in the beginning of this thread appears when the texture is used.
What seems to happen is that the texture is never resolved from the "/MsaaImplicit" texture to the non-MSAA texture. My understanding of non-explicit resolves is explained in the documentation of TextureFlags::MsaaExplicitResolve:
Without explicit resolves, Ogre will automatically resolve the MSAA
surface into the texture whenever it detects you will be sampling
from this texture.
That seemed to happen in 2.1, but doesn't work for me using 2.2.
I have read about store actions and StoreAction::MultisampleResolve, which have been mentioned in this thread. However, having to set this manually on the last pass to touch the texture sort of goes against the purpose of implicit resolves, as I quite explicitly have to point out where the resolve should take place. This makes it hard to make general compositor workspaces that work both for MSAA and non-MSAA targets, without having to know up front which texture will be used in the compositor channel of the workspace.
There also seem to be some complications with using StoreAction::MultisampleResolve and/or StoreAction::StoreAndMultisampleResolve when the target is a render window. I would expect that the compositor setup shouldn't have to know which sort of output channel will be used, and how the output texture will be used after rendering is done.
Still, I tried using StoreAction::MultisampleResolve on the last pass touching the texture, in order to get things working. This led to a few issues:
1. If the output channel is a render window, the following exception is thrown:
https://github.com/OGRECave/ogre-next/b ... s.cpp#L369
This can be solved by only setting the MultisampleResolve-action on non-renderwindows, but I would like the compositor setup to be ignorant of this difference. This can be solved by adding another condition to the if-statement two steps above the exception, checking whether or not the texture is a renderwindow.
2. Now, if the actual target is NOT a multisample texture, the following exception is hit: https://github.com/OGRECave/ogre-next/b ... r.cpp#L191
I solved this for now by removing that check. This can also be worked around by not using a resolving store action, but again, I would prefer if the compositor didn't know this fact.
3. With the fixes above, the store action will resolve the texture when it is a MSAA texture and not a render window. However, after the resolve, the texture is immediately invalidated. The following line seems to invalidate the resolved non-MSAA target, while I think it is supposed to invalidate the MSAA texture itself: https://github.com/OGRECave/ogre-next/b ... r.cpp#L706
This can be fixed by changing GL_FRAMEBUFFER to GL_READ_FRAMEBUFFER on the same line (or worked around by using StoreAndMultisampleResolve as store action, which skips the invalidation step).
Is there some easier way that I have missed? I can't quite see where the texture is supposed to be resolved implicitly "whenever it [Ogre] detects you will be sampling from this texture".