Re: [osg-users] request for small change in StandardShadowMap.cpp
Okay ... if you find in any case 5 minutes, attached are the proposed mods.
Thanks as always!
Nick
On Fri, May 1, 2015 at 8:16 PM, Robert Osfield
wrote:
> Hi NIck,
>
> On 1 May 2015 at 19:11, Trajce Nikolov NICK
> wrote:
> > 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?
>
> I am not in position to do a code review of osgShadow right now, so
> can't provide any guidance right away.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
--
trajce nikolov nick
StandardShadowMap
Description: Binary data
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*
* ViewDependentShadow codes Copyright (C) 2008 Wojciech Lewandowski
* Thanks to to my company http://www.ai.com.pl for allowing me free this work.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
using namespace osgShadow;
#define DISPLAY_SHADOW_TEXEL_TO_PIXEL_ERROR 0
#define FRAGMENT_SHADERS_ONLY 1
StandardShadowMap::StandardShadowMap():
BaseClass(),
_polygonOffsetFactor( 1.1f ),
_polygonOffsetUnits( 4.0f ),
_textureSize( 1024, 1024 ),
_baseTextureUnit( 0 ),
_shadowTextureUnit( 1 ),
_baseTextureCoordIndex( 0 ),
_shadowTextureCoordIndex( 1 )
{
#if FRAGMENT_SHADERS_ONLY
_mainFragmentShader = new osg::Shader( osg::Shader::FRAGMENT,
" // following expressions are auto modified - do not change them: \n"
" // gl_TexCoord[0] 0 - can be subsituted with other index \n"
"\n"
"float DynamicShadow( ); \n"
"\n"
"uniform sampler2D baseTexture; \n"
"\n"
"void main(void) \n"
"{ \n"
" vec4 colorAmbientEmissive = gl_FrontLightModelProduct.sceneColor; \n"
//" // Add ambient from Light of index = 0\n"
//" colorAmbientEmissive += gl_FrontLightProduct[0].ambient; \n"
" vec4 color = texture2D( baseTexture, gl_TexCoord[0].xy ); \n"
" color *= mix( colorAmbientEmissive, gl_Color, DynamicShadow() ); \n"
#if DISPLAY_SHADOW_TEXEL_TO_PIXEL_ERROR
" color.xy = abs( dFdy( gl_TexCoord[1].xy / gl_TexCoord[1].w ) )* 1024.0; \n"
" color.z = color.y; \n"
" color.x = color.z; \n"
" color.y = color.z; \n"
" color.a = 1.0; \n"
#endif
// " float fog = clamp((gl_Fog.end - gl_FogFragCoord)*gl_Fog.scale, 0.,1.);\n"
// " color.rgb = mix( gl_Fog.color.rgb, color.rgb, fog ); \n"
" gl_FragColor = color; \n"
"} \n" );
_shadowFragmentShader = new osg::Shader( osg::Shader::FRAGMENT,
" // following expressions are auto modified - do not change them: \n"
" // gl_TexCoord[1] 1 - can be subsituted with other index \n"
" \n"
"uniform sampler2DShadow shadowTexture; \n"
" \n"
"float DynamicShadow( ) \n"
"{ \n"
"return shadow2DProj( shadowTexture, gl_TexCoord[1] ).r;\n"
"} \n" );
_shadowVertexShader = NULL;
_mainVertexShader = NULL;
#else
_mainFragmentShader = new osg::Shader( osg::Shader::FRAGMENT,
" // following
Re: [osg-users] request for small change in StandardShadowMap.cpp
Hi NIck, On 1 May 2015 at 19:11, Trajce Nikolov NICK wrote: > 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? I am not in position to do a code review of osgShadow right now, so can't provide any guidance right away. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] request for small change in StandardShadowMap.cpp
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.n...@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
> 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
>> 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@lists.openscenegraph.org
>> >
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
>
> --
> trajce nikolov nick
>
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] request for small change in StandardShadowMap.cpp
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
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
> 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@lists.openscenegraph.org
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
--
trajce nikolov nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] request for small change in StandardShadowMap.cpp
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
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@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] request for small change in StandardShadowMap.cpp
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@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
