<div dir="ltr">Hi again Robert,<div><br></div><div>I took a closer look into ShadowedScene::traverse and you are right. The reason to force osg::Group::traverse is to allow to call this from the ShadowedTechnique, to avoid recursive calls of the same.</div><div><br></div><div>So I am going to ask if you can expose the local osg::Program through an interface, that is easier .. What you think?</div><div><br></div><div>Nick</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 1, 2015 at 7:24 PM, Trajce Nikolov NICK <span dir="ltr"><<a href="mailto:trajce.nikolov.nick@gmail.com" target="_blank">trajce.nikolov.nick@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Robert,<div><br></div><div>thanks for the reply. Well, I spent quite a good amount of time to understand how it works and it all points to the StandardShadowMap, the call I posted. This shadowmap technique allows you to attach shaders to it through the interface, but the program is set localy again for a local _stateset that is pushed through the CullVisitor in a cull stage. All I need is reference to this local instance of the Program. Perhaps, maybe introduce a method getProgram() which again will not hurt anyone.</div><div><br></div><div>Also, I can not think of any special reason to specialize the traverse call to osg::Group then forbid the extension .... </div><div><br></div><div>Any further thoughts? </div><div><br></div><div>Nick</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Fri, May 1, 2015 at 6:50 PM, Robert Osfield <span dir="ltr"><<a href="mailto:robert.osfield@gmail.com" target="_blank">robert.osfield@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nick,<br>
<br>
I haven't worked with osgShadow for over a year so it's not fresh in<br>
my mind.  There are mechanisms for override the state management in<br>
osgShadow but I don't recall how widely they are implemented amongst<br>
the shadow techniques.<br>
<br>
With the proposed change, with the explicit osg::Group::traverse()<br>
method there must be a reason why this was done but without a code<br>
review and trawl through the svn logs I can't provide the answer.  In<br>
general overriding the management of osg::Program and other<br>
osg::StateSet setting shouldn't require lots of hacks, so if a<br>
particular ShadowTechnique is failing in this respect then perhaps<br>
this needs looking at.<br>
<br>
Robert.<br>
<br>
<br>
Robert.<br>
<br>
On 1 May 2015 at 17:15, Trajce Nikolov NICK<br>
<div><div><<a href="mailto:trajce.nikolov.nick@gmail.com" target="_blank">trajce.nikolov.nick@gmail.com</a>> wrote:<br>
> Hi Robert,<br>
><br>
> I posted a while ago a question how to get the osg::Program associated with<br>
> the shaders from the StandardShadowMap in order to extend. And it is localy<br>
> defined as you can see in the code. However I found a workaround, by<br>
> extending the ShadowingScene and catch the StateSet from the Cull traversal.<br>
> But, this will not work since the line below. Here is my proposed change, it<br>
> will not hurt anyone I think - these ShadowMap* classes are<br>
> over-encapsulated in my opinion.<br>
><br>
> void StandardShadowMap::ViewData::cullShadowReceivingScene( )<br>
><br>
> {<br>
><br>
>     _cv->pushStateSet( _stateset.get() );<br>
><br>
><br>
> #if 0<br>
><br>
>     _st->getShadowedScene()->osg::Group::traverse( *_cv );<br>
><br>
> #else<br>
><br>
>     _st->getShadowedScene()->traverse( *_cv );<br>
><br>
> #endif<br>
><br>
><br>
>     _cv->popStateSet();<br>
><br>
> }<br>
><br>
><br>
> It will be nice if this forcing of osg::Group::traverse is replaced by<br>
> ordinary traverse thus anyone can re-write and extend. What you think?<br>
><br>
><br>
> Please let me know and thanks a bunch as always!<br>
><br>
><br>
> Nick<br>
><br>
><br>
> --<br>
> trajce nikolov nick<br>
><br>
</div></div>> _______________________________________________<br>
> osg-users mailing list<br>
> <a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
> <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
><br>
_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div>trajce nikolov nick<br></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">trajce nikolov nick<br></div>
</div>