Offscreen multisampling

Troubleshooting graphics
1

I’m rendering my scene to an offscreen multisampled FrameBuffer. I then want to resolve the multisampled buffer by copyFrameBuffer from the multisampled fbo to a single sampled fbo (so that I can then readFrameBuffer or render to a texture).



This doesn’t seem to work - after copying, the single sampled fbo always contains garbage. I can reproduce this with a simple change to jme3test/post/TestRenderToMemory.java - see https://gist.github.com/3151867



Anyone idea what I’m doing wrong?

2

Can’t see the problem at first glance but look into the FilterPostProcessor, this very operation is done to resolve MS for ogl version less than 3.1

3
@nehon said:
Can't see the problem at first glance but look into the FilterPostProcessor, this very operation is done to resolve MS for ogl version less than 3.1


Interesting, FilterPostProcessor is basically doing what I'm doing - and it has the same issue. I tweaked the jme3test.post.TestPosterization sample to setNumSamples(4) on the FilterPostProcessor, and now it renders garbage.

I'm testing on MacOS (Nvidia GeForce GT 330M), these are the capabilities logged:
INFO: Caps: [FrameBuffer, FrameBufferMRT, FrameBufferMultisample, OpenGL20, OpenGL21, ARBprogram, GLSL100, GLSL110, GLSL120, VertexTextureFetch, TextureArray, FloatTexture, FloatColorBuffer, FloatDepthBuffer, PackedFloatTexture, SharedExponentTexture, PackedFloatColorBuffer, NonPowerOfTwoTextures, MeshInstancing]
4

I tried your test case and it fails also on my win7.

So the good new is that it’s not a macOs issue only.



I gonna test things and keep you informed.

5

I tested on a Win7 box with the same problem - TestPosterization renders garbage if I setNumSamples(4) on the FilterPostProcessor.



This box has an Nvidia GeForce GT 120

INFO: Caps: [FrameBuffer, FrameBufferMRT, FrameBufferMultisample, TextureMultisample, OpenGL20, OpenGL21, OpenGL30, OpenGL31, OpenGL32, ARBprogram, GLSL100, GLSL110, GLSL120, GLSL130, GLSL140, GLSL150, VertexTextureFetch, TextureArray, TextureBuffer, FloatTexture, FloatColorBuffer, FloatDepthBuffer, PackedFloatTexture, SharedExponentTexture, PackedFloatColorBuffer, TextureCompressionLATC, NonPowerOfTwoTextures, MeshInstancing, VertexBufferArray, PackedDepthStencilBuffer]
6

yeah i have the problem too…



That’s strange other filters tests works fine with multisampling…

7

mhh ok…actually it works as long as i have at least 2 filters in the stack…

could you test on your side?

8
@nehon said:
mhh ok...actually it works as long as i have at least 2 filters in the stack....
could you test on your side?


I added a second filter - CrossHatchFilter, but it still doesn't render properly on mac or win. This is my patch to TestPosterization https://gist.github.com/3153015
9

actually it it works for me with some filters before the PosterizationFilter…like water, coloroverlay, fog and so on…

I’m still digging…

10

OK, fog before Posterization works for me on win7, but still not on mac. CrossHatch before Posterization doesn’t work on win7 or mac.

11

@nehon While tracking down another bug, I found that Renderer.copyFrameBuffer is buggy, and that bug is what is breaking offscreen multisampling.



copyFrameBuffer is using incorrect rectangle sizes, and so the src and dst rectangles differ by one pixel in width and height. According to the spec the blit from multisampled to single sampled FBO will fail if the rectangles are different sizes:

if SAMPLE_BUFFERS for either the read framebuffer or draw framebuffer is greater than zero, no copy is performed and an INVALID_OPERATION error is generated if the dimensions of the source and destination rectangles provided to BlitFramebuffer are not identical

http://www.opengl.org/registry/specs/EXT/framebuffer_multisample.txt

I submitted a patch in the contribution forum and after applying that, my offscreen multisampled testcases all work.
http://hub.jmonkeyengine.org/groups/contribution-depot-jme3/forum/topic/lwjgl-copyframebuffer-off-by-one-error-patch/
2 Likes
12

wicked!

Thanks a lot , i’ll test that asap and integrate it.

13

Has this issue been fixed yet?

14
@Momoko_Fan said:
Has this issue been fixed yet?


Yes, my patch from the other thread has been committed and fixed this issue.
1 Like