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 list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
