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
