I have a problem of Ogre behavior between commit 5b64b02861840e3990d3fb258c40b74680c91ced (2018/04/20) and 28b2f67da67a4f54625298bc38e653e7dc8ae976 (2019/07/14) of the v2.1 branch.
My software is rendering different camera (say 4) at different position/orientation of my scene by RenderTexture
Then, I download the content by using Ogre::RenderTexture::copyContentsToMemory
When I ran the commit 5b64b02861840e3990d3fb258c40b74680c91ced (the oldest) everything work fine: my images represent the good point of view
But when I use the newest commit (28b2f67da67a4f54625298bc38e653e7dc8ae976), downloading the content of all RTT gives me a copy of the last camera's RenderTexture rendered in the main render loop.
Strange things :
- When I use RenderWindows instead of RTT it works good
- When I use different resolution for my RenderTextures it work goods too
- When my RTT runs at different frequencies (ie unsynchronized, say [10, 20, 40, 50] Hz), the RTT are sometime binded to the good POV (if they are "alone" in the render loop) and sometime not (same problem: a copy of the last RTT rendered)
I have analyzed the differences between those commits but I haven't found any hint
I use Ogre 2.1 under linux with an NVIDIA GPU / OpenGL3+
(Problems also occur at commit e4f8245a654e9cf6ea599cf0e358ae5212a46522 (intermediate) but I don't know from where/when exactly it appeared)
RTT are not binded correctly (regression)
-
- Kobold
- Posts: 26
- Joined: Tue Sep 05, 2017 10:19 am
- x 7
-
- Kobold
- Posts: 26
- Joined: Tue Sep 05, 2017 10:19 am
- x 7
Re: RTT are not binded correctly (regression)
Ok, I managed to find that regression it seems that a change in RenderSystems/GL3Plus/src/OgreGL3PlusFBORenderTexture.cpp provoke my problem :
Coming from commit 85da27ac987915eeee924a43a9319aab4c5ab1eb (by dark_sylinc
to answer a problem cited here viewtopic.php?f=25&t=92915&p=541565#p541565 )
When I put back the code my RTT are binded correctly again...
Sorry to dig out this issue again but it prevent my society to update to the last Ogre 2.1 version and further...
Thanks to anybody that can help me...
Edit : Of course I can patch this in my own version of Ogre, but I don't want to diverge so much from Ogre 2.1 official branch if possible, and maybe other may have the same issues
Code: Select all
RBFormat key(format, width, height, fsaa);
RenderBufferMap::iterator it = mRenderBufferMap.find(key);
- if(it != mRenderBufferMap.end() && (it->second.refcount == 0))
+ if(it != mRenderBufferMap.end())
{
retval.buffer = it->second.buffer;
retval.zoffset = 0;

When I put back the code
Code: Select all
&& (it->second.refcount == 0)
Sorry to dig out this issue again but it prevent my society to update to the last Ogre 2.1 version and further...
Thanks to anybody that can help me...
Edit : Of course I can patch this in my own version of Ogre, but I don't want to diverge so much from Ogre 2.1 official branch if possible, and maybe other may have the same issues

-
- OGRE Team Member
- Posts: 5505
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1372
Re: RTT are not binded correctly (regression)
Hi!
I'm afraid the bug is "by design".
Unfortunately MSAA + copyContentsToMemory combo never worked too well. It's all a combination of issues that caused your problem; and the fix just hides it away.
Normally in Ogre 2.1 MSAA surfaces are shared between textures, since that data is thrown away after resolve.
It looks like copyContentsToMemory is either resolving again (using the last data from MSAA, which is now bad, over that 'good' resolve) or it is reading directly from the MSAA surface. This is tricky to solve. I can't remember how well explicit resolve worked in Ogre 2.1, which would force textures to not share MSAA surfaces.
You've stumbled in one of the darker paths of Ogre 2.1 (texture + msaa + copies to CPU) which was one of the main reasons Ogre 2.2
The best solution I can offer is that short term go with your custom solution (undo the line code change), and longer term solution move to Ogre 2.2 (it is very stable now; and it is not as much work as moving from 1.x -> 2.1). MSAA and reading to CPU are both a first class citizen in 2.2
I'm afraid the bug is "by design".
Unfortunately MSAA + copyContentsToMemory combo never worked too well. It's all a combination of issues that caused your problem; and the fix just hides it away.
Normally in Ogre 2.1 MSAA surfaces are shared between textures, since that data is thrown away after resolve.
It looks like copyContentsToMemory is either resolving again (using the last data from MSAA, which is now bad, over that 'good' resolve) or it is reading directly from the MSAA surface. This is tricky to solve. I can't remember how well explicit resolve worked in Ogre 2.1, which would force textures to not share MSAA surfaces.
You've stumbled in one of the darker paths of Ogre 2.1 (texture + msaa + copies to CPU) which was one of the main reasons Ogre 2.2
The best solution I can offer is that short term go with your custom solution (undo the line code change), and longer term solution move to Ogre 2.2 (it is very stable now; and it is not as much work as moving from 1.x -> 2.1). MSAA and reading to CPU are both a first class citizen in 2.2