[Opensg-users] OpenSG2: Open questions

Discussion:

Michael Raab

2014-05-13 15:16:18 UTC

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi all,</div>

<div> </div>

<div>I have still the following open issues:</div>

<div> </div>

<div>1.) SkyBackground:</div>

<div>In OpenSG1.8 we were using the SkyBackground beacon to rotate it to our native coordinates. With OpenSG2 all our skybackground seem to miss that transformation. Playing around with the transformation value seems to have no effect at all. Maybe there's something missing?!</div>

<div> </div>

<div> </div>

<div>2.) Shadows:</div>

<div>I can see 2 possibilities to use shadows in OpenSG2: ShadowEngines and ShadowStages. What is the recommended way to create shadows? I'm asking as the supported modes differ (Standard/Trapezoidal vs. Perspective/PCF/PCSS/Dither/..).</div>

<div> </div>

<div> </div>

<div>3.) Shaders</div>

<div>We have the problem that in some cases uniform values are not initialized. Here's an example:</div>

<div>
<div> </div>

<div>shlChunk->setVertexProgram(vertexProgram.str());<br/>
 shlChunk->setFragmentProgram(fragmentProgram.str());</div>

<div> </div>

<div>//add chunks to chunk material<br/>
    chunkMaterial->addChunk(shlChunk);</div>

<div>    commitChanges();</div>

<div> </div>

<div>    //add shader parameters<br/>
    shlChunk->addUniformVariable("gDiffuseFactor", 0.5f);</div>

<div>    commitChanges();</div>

<div> </div>

<div>After that the shader code seems to be transferred and compiled correctly but the uniform value isn't. If I call updateUniformVariable a frame later, the value gets transmitted and shader results look as expected.</div>

<div> </div>

<div>Ideas on that?</div>

<div> </div>

<div>Regards,</div>

<div>Michael </div>
</div>

<div> </div></div></body></html>

Carsten Neumann

2014-05-13 18:13:33 UTC

Permalink

Hello Michael,

On 05/13/2014 05:16 PM, Michael Raab wrote:
> I have still the following open issues:
> 1.) SkyBackground:
> In OpenSG1.8 we were using the SkyBackground beacon to rotate it to our
> native coordinates. With OpenSG2 all our skybackground seem to miss that
> transformation. Playing around with the transformation value seems to
> have no effect at all. Maybe there's something missing?!

hmm, from a quick look into the code the beacon is used to calculate the
modelview matrix for rendering the SkyBackground. However, in 2.0
beacons are only held through weak pointers [1], meaning if nothing else
refers to the beacon node (perhaps it is not in the tree?) it will not
be kept alive.
Could that be the case here?

> 2.) Shadows:
> I can see 2 possibilities to use shadows in OpenSG2: ShadowEngines and
> ShadowStages. What is the recommended way to create shadows? I'm asking
> as the supported modes differ (Standard/Trapezoidal vs.
> Perspective/PCF/PCSS/Dither/..).

IMHO the ShadowEngines are the technically superior solution since they
allow much greater flexibility for the shadow algorithms. However, as
you've discovered only limited modes have been implemented for those.
The ShadowStage is ported from 1.x ShadowViewport (?) and behaves quite
similar to that.
So, I'd say if you are porting existing code ShadowStage should work
pretty similar on the other hand having a more complete set of
ShadowEngines would be great :)

> 3.) Shaders
> We have the problem that in some cases uniform values are not
> initialized. Here's an example:
> shlChunk->setVertexProgram(vertexProgram.str());
> shlChunk->setFragmentProgram(fragmentProgram.str());
> //add chunks to chunk material
> chunkMaterial->addChunk(shlChunk);
> commitChanges();
> //add shader parameters
> shlChunk->addUniformVariable("gDiffuseFactor", 0.5f);
> commitChanges();
> After that the shader code seems to be transferred and compiled
> correctly but the uniform value isn't. If I call updateUniformVariable a
> frame later, the value gets transmitted and shader results look as expected.
> Ideas on that?

Does the above sequence reliably reproduce the problem or does it
sometimes work/sometimes not? Is the commitChanges() placement after
addChunk() relevant?
Sorry, not really a good idea what could be the cause, other than some
kind of caching on the status of the uniform...

Cheers,
Carsten

[1] The motivation is that a beacon can be a parent of the node
referring to it - which leads to circles in the chain of references and
thus objects that are never cleaned up.

Michael Raab

2014-05-14 09:52:50 UTC

Permalink

Gerrit Voß

2014-05-14 10:24:23 UTC

Permalink

Hi,

On Wed, 2014-05-14 at 11:52 +0200, Michael Raab wrote:
> Hello Carsten,
>
>
> > Does the above sequence reliably reproduce the problem or does it
> > sometimes work/sometimes not? Is the commitChanges() placement after
> > addChunk() relevant?
> > Sorry, not really a good idea what could be the cause, other than
> some
> > kind of caching on the status of the uniform...
>
> The problem seems to be that before rendering the shader in our main
> application window, we create a material preview icon using a fbo in
> combination with a passive window.
> For that icon rendering everything works as expected. The main
> rendering then creates in SimpleSHLChunk::handleGL() the shader,
> programs but does not update the uniform variables as they are not
> marked as changed.
> I wrote a fix that eliminates the problem on our side. Patch is
> attached.

hmm, there seem to be a deeper issue than, just for my understanding,
your passive preview window and your application window are different
windows. If so that looks like it needs more general fix, somehow bind
the uniform state to the window. I'll have a closer look at that.

kind regards
gerrit

Michael Raab

2014-05-14 11:11:27 UTC

Permalink

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hello Gerrit,</div>

<div> </div>

<div>> hmm, there seem to be a deeper issue than, just for my understanding,<br/>
> your passive preview window and your application window are different<br/>
> windows. If so that looks like it needs more general fix, somehow bind<br/>
> the uniform state to the window. I'll have a closer look at that.</div>

<div>
<div> </div>

<div>Yes those 2 windows are different.</div>

<div> </div>

<div>Thanks,</div>

<div>Michael</div>

<div> </div>

<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Mittwoch, 14. Mai 2014 um 12:24 Uhr<br/>
<b>Von:</b> "Gerrit Voß" <***@vossg.org><br/>
<b>An:</b> opensg-***@lists.sourceforge.net<br/>
<b>Betreff:</b> Re: [Opensg-users] OpenSG2: Open questions</div>

<div name="quoted-content"><br/>
Hi,<br/>
<br/>
On Wed, 2014-05-14 at 11:52 +0200, Michael Raab wrote:<br/>
> Hello Carsten,<br/>
><br/>
><br/>
> > Does the above sequence reliably reproduce the problem or does it<br/>
> > sometimes work/sometimes not? Is the commitChanges() placement after<br/>
> > addChunk() relevant?<br/>
> > Sorry, not really a good idea what could be the cause, other than<br/>
> some<br/>
> > kind of caching on the status of the uniform...<br/>
><br/>
> The problem seems to be that before rendering the shader in our main<br/>
> application window, we create a material preview icon using a fbo in<br/>
> combination with a passive window.<br/>
> For that icon rendering everything works as expected. The main<br/>
> rendering then creates in SimpleSHLChunk::handleGL() the shader,<br/>
> programs but does not update the uniform variables as they are not<br/>
> marked as changed.<br/>
> I wrote a fix that eliminates the problem on our side. Patch is<br/>
> attached.<br/>
<br/>
hmm, there seem to be a deeper issue than, just for my understanding,<br/>
your passive preview window and your application window are different<br/>
windows. If so that looks like it needs more general fix, somehow bind<br/>
the uniform state to the window. I'll have a closer look at that.<br/>
<br/>
kind regards<br/>
gerrit<br/>
<br/>
<br/>
<br/>
<br/>
------------------------------------------------------------------------------<br/>
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE<br/>
Instantly run your Selenium tests across 300+ browser/OS combos.<br/>
Get unparalleled scalability from the best Selenium testing platform available<br/>
Simple to use. Nothing to install. Get started now for free."<br/>
<a href="http://p.sf.net/sfu/SauceLabs" target="_blank">http://p.sf.net/sfu/SauceLabs</a><br/>
_______________________________________________<br/>
Opensg-users mailing list<br/>
Opensg-***@lists.sourceforge.net<br/>
<a href="https://lists.sourceforge.net/lists/listinfo/opensg-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/opensg-users</a></div>
</div>
</div>
</div></div></body></html>

Michael Raab

2014-05-21 08:22:26 UTC

Permalink

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hi,</div>

<div> </div>

<div>> For now I have implemented the use of ShadowEngines. I'll look into the details of the ShadowsStages in the next days..</div>

<div> </div>

<div>After some testing the results of the ShadowEngine's seems to be not as good as the shadow technique's in OpenSG1.8 were. Therefore I switched to the ShadowStage approach.</div>

<div>Works as expected in principle, but with shadows enabled we loose anti-aliasing. I guess multisampling needs to be enabled for the Framebuffer object that renders to main view. I already looked at the code but I have no idea how integrate that in a clean way.</div>

<div> </div>

<div>Thanks,</div>

<div>Michael</div>

<div> 
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Mittwoch, 14. Mai 2014 um 11:52 Uhr<br/>
<b>Von:</b> "Michael Raab" <michael-***@gmx.de><br/>
<b>An:</b> opensg-***@lists.sourceforge.net<br/>
<b>Betreff:</b> Re: [Opensg-users] OpenSG2: Open questions</div>

<div name="quoted-content">
<div style="font-family: Verdana;font-size: 12.0px;">
<div>
<div>Hello Carsten,</div>

<div> </div>

<div>> hmm, from a quick look into the code the beacon is used to calculate the<br/>
> modelview matrix for rendering the SkyBackground. However, in 2.0<br/>
> beacons are only held through weak pointers [1], meaning if nothing else<br/>
> refers to the beacon node (perhaps it is not in the tree?) it will not<br/>
> be kept alive.<br/>
> Could that be the case here?</div>

<div>
<div> </div>

<div>Good catch. Works now as expected. Thanks.</div>

<div> </div>

<div>> So, I'd say if you are porting existing code ShadowStage should work<br/>
> pretty similar on the other hand having a more complete set of<br/>
> ShadowEngines would be great :)</div>

<div> </div>

<div>For now I have implemented the use of ShadowEngines. I'll look into the details of the ShadowsStages in the next days..</div>

<div> </div>

<div>> Does the above sequence reliably reproduce the problem or does it<br/>
> sometimes work/sometimes not? Is the commitChanges() placement after<br/>
> addChunk() relevant?<br/>
> Sorry, not really a good idea what could be the cause, other than some<br/>
> kind of caching on the status of the uniform...</div>

<div> </div>

<div>The problem seems to be that before rendering the shader in our main application window, we create a material preview icon using a fbo in combination with a passive window.</div>

<div>For that icon rendering everything works as expected. The main rendering then creates in SimpleSHLChunk::handleGL() the shader, programs but does not update the uniform variables as they are not marked as changed.</div>

<div>I wrote a fix that eliminates the problem on our side. Patch is attached.</div>

<div> </div>

<div>Regards,</div>

<div>Michael</div>

<div> </div>

<div style="margin: 10.0px 5.0px 5.0px 10.0px;padding: 10.0px 0 10.0px 10.0px;border-left: 2.0px solid rgb(195,217,229);">
<div style="margin: 0 0 10.0px 0;"><b>Gesendet:</b> Dienstag, 13. Mai 2014 um 20:13 Uhr<br/>
<b>Von:</b> "Carsten Neumann" <***@gmx.net><br/>
<b>An:</b> opensg-***@lists.sourceforge.net<br/>
<b>Betreff:</b> Re: [Opensg-users] OpenSG2: Open questions</div>

<div>Hello Michael,<br/>
<br/>
On 05/13/2014 05:16 PM, Michael Raab wrote:<br/>
> I have still the following open issues:<br/>
> 1.) SkyBackground:<br/>
> In OpenSG1.8 we were using the SkyBackground beacon to rotate it to our<br/>
> native coordinates. With OpenSG2 all our skybackground seem to miss that<br/>
> transformation. Playing around with the transformation value seems to<br/>
> have no effect at all. Maybe there's something missing?!<br/>
<br/>
hmm, from a quick look into the code the beacon is used to calculate the<br/>
modelview matrix for rendering the SkyBackground. However, in 2.0<br/>
beacons are only held through weak pointers [1], meaning if nothing else<br/>
refers to the beacon node (perhaps it is not in the tree?) it will not<br/>
be kept alive.<br/>
Could that be the case here?<br/>
<br/>
> 2.) Shadows:<br/>
> I can see 2 possibilities to use shadows in OpenSG2: ShadowEngines and<br/>
> ShadowStages. What is the recommended way to create shadows? I'm asking<br/>
> as the supported modes differ (Standard/Trapezoidal vs.<br/>
> Perspective/PCF/PCSS/Dither/..).<br/>
<br/>
IMHO the ShadowEngines are the technically superior solution since they<br/>
allow much greater flexibility for the shadow algorithms. However, as<br/>
you've discovered only limited modes have been implemented for those.<br/>
The ShadowStage is ported from 1.x ShadowViewport (?) and behaves quite<br/>
similar to that.<br/>
So, I'd say if you are porting existing code ShadowStage should work<br/>
pretty similar on the other hand having a more complete set of<br/>
ShadowEngines would be great :)<br/>
<br/>
> 3.) Shaders<br/>
> We have the problem that in some cases uniform values are not<br/>
> initialized. Here's an example:<br/>
> shlChunk->setVertexProgram(vertexProgram.str());<br/>
> shlChunk->setFragmentProgram(fragmentProgram.str());<br/>
> //add chunks to chunk material<br/>
> chunkMaterial->addChunk(shlChunk);<br/>
> commitChanges();<br/>
> //add shader parameters<br/>
> shlChunk->addUniformVariable("gDiffuseFactor", 0.5f);<br/>
> commitChanges();<br/>
> After that the shader code seems to be transferred and compiled<br/>
> correctly but the uniform value isn't. If I call updateUniformVariable a<br/>
> frame later, the value gets transmitted and shader results look as expected.<br/>
> Ideas on that?<br/>
<br/>
Does the above sequence reliably reproduce the problem or does it<br/>
sometimes work/sometimes not? Is the commitChanges() placement after<br/>
addChunk() relevant?<br/>
Sorry, not really a good idea what could be the cause, other than some<br/>
kind of caching on the status of the uniform...<br/>
<br/>
Cheers,<br/>
Carsten<br/>
<br/>
[1] The motivation is that a beacon can be a parent of the node<br/>
referring to it - which leads to circles in the chain of references and<br/>
thus objects that are never cleaned up.<br/>
<br/>
------------------------------------------------------------------------------<br/>
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE<br/>
Instantly run your Selenium tests across 300+ browser/OS combos.<br/>
Get unparalleled scalability from the best Selenium testing platform available<br/>
Simple to use. Nothing to install. Get started now for free."<br/>
<a href="http://p.sf.net/sfu/SauceLabs" target="_blank">http://p.sf.net/sfu/SauceLabs</a><br/>
_______________________________________________<br/>
Opensg-users mailing list<br/>
Opensg-***@lists.sourceforge.net<br/>
<a href="https://lists.sourceforge.net/lists/listinfo/opensg-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/opensg-users</a></div>
</div>
</div>
</div>
</div>
------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." <a href="http://p.sf.net/sfu/SauceLabs_______________________________________________" target="_blank">http://p.sf.net/sfu/SauceLabs_______________________________________________</a> Opensg-users mailing list Opensg-***@lists.sourceforge.net <a href="https://lists.sourceforge.net/lists/listinfo/opensg-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/opensg-users</a></div>
</div>
</div>
</div></div></body></html>

Carsten Neumann

2014-05-26 12:05:39 UTC

Permalink

Hello Michael,

On 05/21/2014 10:22 AM, Michael Raab wrote:
> > For now I have implemented the use of ShadowEngines. I'll look into
> the details of the ShadowsStages in the next days..
> After some testing the results of the ShadowEngine's seems to be not as
> good as the shadow technique's in OpenSG1.8 were. Therefore I switched
> to the ShadowStage approach.

yes, not all the "filtering" techniques to improve shadow quality are
implemented as engines.

> Works as expected in principle, but with shadows enabled we loose
> anti-aliasing. I guess multisampling needs to be enabled for the
> Framebuffer object that renders to main view. I already looked at the
> code but I have no idea how integrate that in a clean way.

The relevant code should be in ShadowTreeHandler (and derived classes).
The ShadowStage implements an algorithm that is slightly more involved:
1) render scene into FBO (color map fbo, for PCF filtering this is done
in PCFShadowMapHandler::createColorMapFBO, other techniques have similar
functions).
2) render a shadow map for each light source (e.g.
PCFShadowMapHandler::createShadowMapsFBO).
3) Combine all shadow maps into one shadow factor map (e.g.
PCFShadowMapHandler::createShadowFactorMapFBO).
4) Combine the color image from step 1 with the shadow factor map from
step 3 an render to the target buffer (application framebuffer or FBO),
ShadowTreeHandler::setupDrawCombineMap2.

I believe the buffers that should use multisampling are the color map
fbo from 1) and possibly the shadow factor map from 3). These buffers
are generated by the ShadowTreeHandler derived classes [1]. They all get
a pointer to the owning ShadowStage, where a "UseMultisampling" flag
could be added - unfortunately all the ShadowTreeHandlers would need to
be adjusted to evaluate the flag.

Cheers,
Carsten

[1] I haven't checked if a helper function in the base class for setting
up common types of buffers makes sense. That would shrink down the
number of places that require adjustment to evaluate a
"UseMultisampling" flag.

Michael Raab

2014-06-02 14:24:54 UTC

Permalink

Carsten Neumann

2014-06-03 09:28:26 UTC

Permalink

Hello Michael,

On 06/02/2014 04:24 PM, Michael Raab wrote:
> I've started to work on this. I've added the necessary fields to
> ShadowStage class and used that information to setup the FBO accordingly.
> The result is that I've lost the shadows :-(
> Looking with an OpenGL debugger I can see that the color map is rendered
> correctly, but the shadow factor map is empty (black).
> Do you have an idea why this is happening? Maybe some shader code that
> has problems accessing multi-sampler data?!

hmm, possible. I don't remember if it is possible to read from a multi
sample texture without a) using special sample functions in the shader
or b) performing a glBlitFramebuffer (or similar operator) to resolve
the multiple samples.
I'm also pretty sure that you'll not get around touching all
*TreeHandler classes to make them create multi sample textures otherwise
I doubt you'll get multi sample rendering on the intermediate steps.

Cheers,
Carsten

Michael Raab

2014-06-03 09:37:37 UTC

Permalink

Carsten Neumann

2014-06-04 11:29:24 UTC

Permalink

Hello Michael,

On 06/03/2014 11:37 AM, Michael Raab wrote:
> ... got it in the mean time. I added an additional fbo for shadow factor
> map rendering. Now the color map gets rendered with MS if necessary and
> the shadow map without.
> I think I adjusted all Treehandler class as well. In the first tests all
> ShadowStage algorithms seem to produce reasonsable (multisampled ;-))
> results. Patch is attached.

great, thanks for the patch! [1] Committed.

Cheers,
Carsten

[1] trivial style nitpick, we generally use only spaces (no tabs) for
indention ;)