Its in osgUtil/RenderStage.cpp. Just search for glBlitFramebuffer. Cheers, Wojtek
2013/11/12 Sebastian Messerschmidt <[email protected]> > Hi Wojciech, > > > Thank you for the very extensive explanation and tests. > It seems it is either a driver problem or I solved the problem > accidentally. Tests on my office PC worked with setting up multisampled > textures bound to a non-multisampled FBO. I'm able to "resolve" them > manually in the shader via texelFetch. > So if I get it correctly there is no implict blit if FBO is 0/0 > multisamples and bound texture is multisampled. > Btw: Can you point me to the line where the implicit blitting is done, so > I can debug it? > > cheers > Sebastian > > Hi, > > Ok. I used verb copy to avoid verb resolve, not being sure how advanced > you are... But yes that 'copy' is a resolve operation using > glBlitFramebuffer internally. > > I have not tried multisampled textures as multirender targets so I guess > your case is bit more complex and I guess its the reason why your results > vary. My observations described earlier, come from experiment with single > color and single depth multisampled textures attached as COLOR and DEPTH > attachments. Attaching them with samples / color samples = 0 was creating > single FBO and rendered directly to these textures. Attaching with samples > / color samples = 8 was internally creating render and resolve FBOs. First > render FBO was rendering to Renderbuffer with 8 samples. And attachment > multisample textures were bound to second resolve FBO. So final > glBlitFarmebuffer was 'copying' contents from Renderbuffer to my > multisampled textures. With first case (samples/color samples = 0) I was > still able to use the textures as input to some other shaders by declaring > them as sampler2DMS uniforms. Below is my shader I used to 'resolve' the > textures myself in input phase. > > #version 150 > #extension GL_ARB_texture_multisample : enable > uniform sampler2DMS colorTex; > uniform sampler2DMS depthTex; > > const int NUM_SAMPLES = 8; > const float NUM_SAMPLES_INV = 1. / float( NUM_SAMPLES ); > > void main( void ) > { > ivec2 itc = ivec2( gl_FragCoord.xy ); > float depth = 0.; > vec4 color = vec4(0.); > for ( int i=0; i<NUM_SAMPLES; i++ ) { > depth += texelFetch( depthTex, itc, i ).x; > color += texelFetch( colorTex, itc, i ); > } > gl_FragDepth = depth * NUM_SAMPLES_INV; > gl_FragColor = color * NUM_SAMPLES_INV; > } > > Cheers, > Wojtek > > > > > 2013/11/12 Sebastian Messerschmidt <[email protected]> > >> Am 11.11.2013 22:44, schrieb Wojciech Lewandowski: >> >> Hi, >> >> I guess answer to main question would be go ahead and add this. >> >> Okay, I just wanted to make sure they are not left out intentionally. >> >> But I just want to write about something else here. If you attach >> Texture2DMultisample to Camera you would want to leave the number of >> samples and color samples at 0. Thats because these params are used to set >> up rendering to multisampled Renderbuffer objects and in post step that >> Renderbuffer is copied to attached texture. If you set Texture2DMultisample >> and additionaly set numbers of samples in attach it will do rendering to >> Renderbuffer and then will copy the result to your Texture2DMultisample >> attachment. I guess its not what you are after. >> >> That is strange. In this case I need some explanation. I want to render >> several multisampled color attachments and resolve them in later passes. In >> this case I create a multisampled color texture and attach it to the >> camera. In consecutive passes I rebind those textures as input and resolve >> them there. If I leave the colorsamples and sample count at the FBO I get a >> FRAMEBUFFER_ATTACHMENT_INCOMPLETE error for the first pass. Setting them >> solved the problem and I got a correct rendering. >> So what is the correct thing to do here? >> >> You mentioned a copy. I always thought binding a texture to a FBO and >> reusing it later in another FBO will not copy it, so I'm quite puzzled. Am >> I'm doing something fundamentally wrong here? >> >> cheers >> Sebastian >> >> >> Cheers, >> Wojtek Lewandowski. >> >> >> 2013/11/11 Sebastian Messerschmidt <[email protected]> >> >>> Hi, >>> >>> maybe this seems like s stupid question but why does >>> osg::Texture2DMultisample does not have a getNumSamples() function? >>> This might come in handy if, like in my case, a texture is passed around >>> for MRT binding (camera->attach), to determine the number of samples for >>> the attach function. >>> Would it be okay to add the get function? >>> >>> cheers >>> Sebastian >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >> >> >> >> _______________________________________________ >> osg-users mailing >> [email protected]http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > > > _______________________________________________ > osg-users mailing > [email protected]http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
