[osg-users] Mutli-Thread OSG produce problems with RTT cameras

[Adrian Egli OpenSceneGraph (3D)]

Hi Robert, Hi others,

as you may get from the latest mailing list topics on Parallel Split Shadow Maps implementation and fixes, we get some flickering effect in the shadow if we are working in multi-threaded osgShadow.exe example. By add the --SingleThread parameters, it works fine, no more flickering effect. (some one reported that they have to add also --screen 0, but this not the same problem, i guess) so back to the multi-threading issue we have in osg or at least in pssm.

i guess the problem comes from a bad synchronisation or  may we  don't have yet  a  the  camera  synchronised or describted in a dependencie graph. because in pssm we render (a-c) shadow maps into RTT and then we render the whole scene as
default viewing camera master m. the a-c should be finish before we start to render the visible / master camera. because the shadow maps are view depended to the m.

what are we doing:

cull , update all pssm shadow map cameras, render/draw the shadow map cameras, render the scene with GLSL based on the shadow map texture.

how can we synchronise this step, it seams not to be enought to work with render order prerender nestedrender or postrender.

thanks for short describtion how it works in osg, and how we should fix the problem we have.
well for the moment we have a robust working PSSM for singlethread, and this isn't so bad, but it should also work for other settings.

regards
adrian

--
********************************************
Adrian Egli

[Robert Osfield]

Hi Adrian,

I've got my head down dealing with some other complex areas of the OSG
right now - it's even a multi-threaded part... so I'm not in a good
place to dive into discussion about other complex areas. Give me a
week and I'll be a in better position.

Robert.

> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Adrian Egli OpenSceneGraph (3D)]

Thanks Robert,

no problem take your time for other new features. in the mean time i
will progress in PSSM as well...

regards adrian

2008/5/21, Robert Osfield <robert....@gmail.com>:

[Wojciech Lewandowski]

Adrian,

Do you remember my suggestion that changing DataVariance might help ?

In certain threading modes osgUtil::Renderer uses 2 SceneViews to cull and
render 2 consecutive frames concurently. Robert used to call it
doublebuffering, first of these SceneViews culls and renders odd frames and
second culls and renders even frames. Technically its possible to have them
working concurently. For example first SceneView may be culling the graph
while second SceneView is outputing(drawing) RenderStage.

This shouldn't be done when some resources of the scene graph are shared and
they change with each frame. If some of these resources are used by both
SceneViews there might be race conditions - it will be possible that some of
them will be changed by first SceneView traversals while also being accessed
by second SceneViews traversals.

What it means for PSSM ? I bet that PSSM:cull changes some shared resources
(like Texgen or some Uniforms for example) in the same time as Draw in
Second View uses them. Classic race condition - sometimes cull wins
sometimes draw wins. Hence some flicker.

DataVariance set to DYNAMIC could be used to serialize SceneViews traversals
and may potentially solve your issue. The question is where in scene graph
this variance should be set. PSSM would be good place for this but I am not
sure if this is possible. Maybe Robert can suggest right place.

Cheers,
Wojtek