Scene freezes when combining the VDSM in osgShadow and (pe)ssao implementation in effectcompositor

[wqxhouse]

Hi Rui,

I tried to make the effectcompositor work by running those examples (colorgrading.xml, ssao.xml, etc.) However, when I enabled both --shadowed argument and (pe)ssao.xml, the scene just freezed in the first frame, without producing useful debugging information.

I just used the default file osgeffectcompositor.cpp to run the examples without changing any other settings. I tried on both GTX580 and intel HD4400 (with both windows 8.1 and mac os 10 on HD4400) with osg 3.2.1 and 3.2.2 release build. Both of them exposed the same issue.

Linking osg::Program "SSAO_Combining" id=7 contextID=0
    Uniform "sceneTex" loc=0 size=1 type=sampler2D
    Uniform "viewportHeight" loc=1 size=1 type=float
    Uniform "aoTex" loc=2 size=1 type=sampler2D
    Uniform "viewportWidth" loc=3 size=1 type=float
    Attrib "gl_Vertex" loc=0 size=1
    Attrib "gl_MultiTexCoord0" loc=1 size=1

Setting up osg::Camera::FRAME_BUFFER
Created new 0x1022c4dd0 TextureObject, _numOfTextureObjects 1
glGetString(GL_RENDERER)==Intel HD Graphics 4400 OpenGL Engine
end draw() 0x102217280
draw() 0x102217280

The debugging info just stops here. The osgviewer is freezed but not crashed. But it is not responding to any events, like ESC.
Note that if I run the program without --shadowed, the ssao works fine.

Thank you for your time.

Robin

[xarray]

Hi Robin,

Thanks for the response. I have submitted a new VDSM implementation to the osg-submissions but it is still in pending because of too many vital changes, which should work fine with the effect compositor... I haven't had time to check if current implementation in trunk can work but thinking to get rid of osgShadow library to render shadows directly in the compositor pipeline. I have already done some initial work to make a single shadow map work. Maybe it can be released soon after I finish a simple multi-shadow-map support. :-)

Wang Rui

[wqxhouse]

Thanks for replying, Rui.

I have another problem with effectcompositor. I posted the details on the osg forum. Here is the link: http://forum.openscenegraph.org/viewtopic.php?t=14797

Basically, in the ssao.xml demo, if you turn on the analysis mode, you'll see that in the linearDepth buffer view, the depth is unstable (flickering) when you zoom in and out quickly. This artifact is more pronounced under lower framerate, around 20fps. (You may need to set OSG_RUN_MAX_FRAME_RATE to 20 to reproduce this issue)

This makes me suspect that the nearPlaneValue and farPlaneValue form the built-in projection matrix's uniforms are somehow not synced with the corresponding ones defined in gl_ProjectionMatrix ( from ftransfrom() ); Below is the shader code from ssao.xml.

void main(void) 
{ 
 vec4 vecInEye = gl_ModelViewMatrix * gl_Vertex; 
 depthValue = (-vecInEye.z - nearPlaneValue) / (farPlaneValue - nearPlaneValue); 
 gl_Position = ftransform(); 
} 

I did an experiment in my second post in the forum to show a similar issue in the plain osg. I draw two cylinders with each one attaching a shader. The first cylinder is directly using ftransform() to calculate the gl_Position. The second cylinder grabs the view and proj matrices from the main camera to calculate the gl_Position. When you rotate the scene, it seems that the first cylinder draws approx. one frame faster than the second.

The effectcompositor's default in-built uniforms may not correctly grab the near_plane and far_plane from the current default gl_ProjectionMatrix, making the depthValue render one frame slower, thus creating the flickering artifact.

Could you have a look at this problem?

Thank you.

Robin

Sorry for the necroposting, but I'm pretty sure I know what is causing this 'one frame delay'.

I did an experiment in my second post in the forum to show a similar issue in the plain osg. I draw two cylinders with each one attaching a shader. The first cylinder is directly using ftransform() to calculate the gl_Position. The second cylinder grabs the view and proj matrices from the main camera to calculate the gl_Position. When you rotate the scene, it seems that the first cylinder draws approx. one frame faster than the second.
The effectcompositor's default in-built uniforms may not correctly grab the near_plane and far_plane from the current default gl_ProjectionMatrix, making the depthValue render one frame slower, thus creating the flickering artifact.

I'm pretty sure the problem you describe above is the result of a threading conflict, and should go away if you run with the environment variable OSG_THREADING=SingleThreaded instead of the default 'DrawThreadByContext'.

Whenever you modify Drawables, StateAttributes or Uniforms, you need to be aware that these objects could still be in use by the drawing thread of the last frame, since 'DrawThreadByContext' threading model allows the next frame to commence before the last frame has finished drawing. There are a couple solutions to deal with this, and it doesn't look like effectcompositor employs any at the moment. The easiest one is to set dataVariance to DYNAMIC so the draw thread gets synchronized, but that will totally wreck performance in most cases. There are more explanations on OpenMW wiki: https://wiki.openmw.org/index.php?title=Rendering_Architecture#Threading_considerations

@xarray , I'm very curious about your proposed VDSM changes because the one upstream did not work very well for me (shadows are totally glitched under some angles). I read a few of your submission posts but I'm unsure which is the latest version, where to get them or what the gist of the changes is. Can you fill us in?