[osg-users] request for small change in StandardShadowMap.cpp

Trajce Nikolov NICK trajce.nikolov.nick at gmail.com
Fri May 1 11:11:30 PDT 2015


Hi again Robert,

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.

So I am going to ask if you can expose the local osg::Program through an
interface, that is easier .. What you think?

Nick

On Fri, May 1, 2015 at 7:24 PM, Trajce Nikolov NICK <
trajce.nikolov.nick at gmail.com> wrote:

> Hi Robert,
>
> 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.
>
> Also, I can not think of any special reason to specialize the traverse
> call to osg::Group then forbid the extension ....
>
> Any further thoughts?
>
> Nick
>
> On Fri, May 1, 2015 at 6:50 PM, Robert Osfield <robert.osfield at gmail.com>
> wrote:
>
>> Hi Nick,
>>
>> I haven't worked with osgShadow for over a year so it's not fresh in
>> my mind.  There are mechanisms for override the state management in
>> osgShadow but I don't recall how widely they are implemented amongst
>> the shadow techniques.
>>
>> With the proposed change, with the explicit osg::Group::traverse()
>> method there must be a reason why this was done but without a code
>> review and trawl through the svn logs I can't provide the answer.  In
>> general overriding the management of osg::Program and other
>> osg::StateSet setting shouldn't require lots of hacks, so if a
>> particular ShadowTechnique is failing in this respect then perhaps
>> this needs looking at.
>>
>> Robert.
>>
>>
>> Robert.
>>
>> On 1 May 2015 at 17:15, Trajce Nikolov NICK
>> <trajce.nikolov.nick at gmail.com> wrote:
>> > Hi Robert,
>> >
>> > I posted a while ago a question how to get the osg::Program associated
>> with
>> > the shaders from the StandardShadowMap in order to extend. And it is
>> localy
>> > defined as you can see in the code. However I found a workaround, by
>> > extending the ShadowingScene and catch the StateSet from the Cull
>> traversal.
>> > But, this will not work since the line below. Here is my proposed
>> change, it
>> > will not hurt anyone I think - these ShadowMap* classes are
>> > over-encapsulated in my opinion.
>> >
>> > void StandardShadowMap::ViewData::cullShadowReceivingScene( )
>> >
>> > {
>> >
>> >     _cv->pushStateSet( _stateset.get() );
>> >
>> >
>> > #if 0
>> >
>> >     _st->getShadowedScene()->osg::Group::traverse( *_cv );
>> >
>> > #else
>> >
>> >     _st->getShadowedScene()->traverse( *_cv );
>> >
>> > #endif
>> >
>> >
>> >     _cv->popStateSet();
>> >
>> > }
>> >
>> >
>> > It will be nice if this forcing of osg::Group::traverse is replaced by
>> > ordinary traverse thus anyone can re-write and extend. What you think?
>> >
>> >
>> > Please let me know and thanks a bunch as always!
>> >
>> >
>> > Nick
>> >
>> >
>> > --
>> > trajce nikolov nick
>> >
>> > _______________________________________________
>> > osg-users mailing list
>> > osg-users at lists.openscenegraph.org
>> >
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
>
> --
> trajce nikolov nick
>



-- 
trajce nikolov nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150501/d47182e1/attachment-0003.htm>


More information about the osg-users mailing list