Hi,
> 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.
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.
Thanks,
Michael
Gesendet: Mittwoch, 14. Mai 2014 um 11:52 Uhr
Von: "Michael Raab" <michael-r...@gmx.de>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] OpenSG2: Open questions
Von: "Michael Raab" <michael-r...@gmx.de>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] OpenSG2: Open questions
Hello Carsten,
> 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?
> 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?
Good catch. Works now as expected. Thanks.
> 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 :)
> pretty similar on the other hand having a more complete set of
> ShadowEngines would be great :)
For now I have implemented the use of ShadowEngines. I'll look into the details of the ShadowsStages in the next days..
> 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...
> 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.
Regards,
Michael
Gesendet: Dienstag, 13. Mai 2014 um 20:13 Uhr
Von: "Carsten Neumann" <carsten_neum...@gmx.net>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] OpenSG2: Open questions
Von: "Carsten Neumann" <carsten_neum...@gmx.net>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] OpenSG2: Open questions
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.
------------------------------------------------------------------------------
"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."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
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.
------------------------------------------------------------------------------
"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."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
------------------------------------------------------------------------------ "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." http://p.sf.net/sfu/SauceLabs
_______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
