date:20150501

Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

2015-05-01 Thread Curtis Rubel

Hi Everyone,

Attached to this post is an example that causes the segv to occur that I am 
referring to in my first post on the subject.  This example is the combination 
of portions the osgviewerQT and osgText examples as provided with this same 
release of OpenSceneGraph. 

Hopefully with this example failing it can be determined what is happening.

... 

Thank you!

Cheers,
Curtis

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63591#63591



#include QTimer
#include QApplication
#include QGridLayout

#include osgViewer/CompositeViewer
#include osgViewer/ViewerEventHandlers

#include osgGA/MultiTouchTrackballManipulator

#include osgDB/ReadFile

#include osgQt/GraphicsWindowQt


#include osgUtil/Optimizer
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgDB/Registry
#include osgGA/StateSetManipulator
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osg/Geode
#include osg/Camera
#include osg/ShapeDrawable
#include osg/Sequence
#include osg/PolygonMode
#include osg/io_utils
#include osgText/Font
#include osgText/Text


#include iostream

#include osgcamera.h


osg::Group* createHUDText()
{

osg::Group* rootNode = new osg::Group;

osgText::Font* font = osgText::readFontFile(fonts/arial.ttf);

//osg::setNotifyLevel(osg::INFO);

osg::Geode* geode  = new osg::Geode;
rootNode-addChild(geode);

bool useVBOs = false;
#if defined(OSG_GL3_AVAILABLE)  !defined(OSG_GL2_AVAILABLE)  !defined(OSG_GL1_AVAILABLE)
useVBOs = true;
osg::Program* program = new osg::Program;
program-addShader(new osg::Shader(osg::Shader::VERTEX, gl3TextVertexShader));
program-addShader(new osg::Shader(osg::Shader::FRAGMENT, gl3TextFragmentShader));
geode-getOrCreateStateSet()-setAttributeAndModes(program, osg::StateAttribute::ON);
#endif

float windowHeight = 1024.0f;
float windowWidth = 1280.0f;
float margin = 50.0f;



//
// Examples of how to set up different text layout
//

osg::Vec4 layoutColor(1.0f,1.0f,0.0f,1.0f);
float layoutCharacterSize = 20.0f;

{
osgText::Text* text = new osgText::Text;
text-setUseVertexBufferObjects(useVBOs);
text-setFont(font);
text-setColor(layoutColor);
text-setCharacterSize(layoutCharacterSize);
text-setPosition(osg::Vec3(margin,windowHeight-margin,0.0f));

// the default layout is left to right, typically used in languages
// originating from europe such as English, French, German, Spanish etc..
text-setLayout(osgText::Text::LEFT_TO_RIGHT);

text-setText(text-setLayout(osgText::Text::LEFT_TO_RIGHT););
geode-addDrawable(text);
}

{
osgText::Text* text = new osgText::Text;
text-setUseVertexBufferObjects(useVBOs);
text-setFont(font);
text-setColor(layoutColor);
text-setCharacterSize(layoutCharacterSize);
text-setPosition(osg::Vec3(windowWidth-margin,windowHeight-margin,0.0f));

// right to left layouts would be used for hebrew or arabic fonts.
text-setLayout(osgText::Text::RIGHT_TO_LEFT);
text-setAlignment(osgText::Text::RIGHT_BASE_LINE);

text-setText(text-setLayout(osgText::Text::RIGHT_TO_LEFT););
geode-addDrawable(text);
}

{
osgText::Text* text = new osgText::Text;
text-setUseVertexBufferObjects(useVBOs);
text-setFont(font);
text-setColor(layoutColor);
text-setPosition(osg::Vec3(margin,windowHeight-margin,0.0f));
text-setCharacterSize(layoutCharacterSize);

// vertical font layout would be used for asian fonts.
text-setLayout(osgText::Text::VERTICAL);

text-setText(text-setLayout(osgText::Text::VERTICAL););
geode-addDrawable(text);
}



//
// Examples of how to set up different font resolution
//

osg::Vec4 fontSizeColor(0.0f,1.0f,1.0f,1.0f);
float fontSizeCharacterSize = 30;

osg::Vec3 cursor = osg::Vec3(margin*2,windowHeight-margin*2,0.0f);

{
osgText::Text* text = new osgText::Text;
text-setUseVertexBufferObjects(useVBOs);
text-setFont(font);
text-setColor(fontSizeColor);
text-setCharacterSize(fontSizeCharacterSize);
text-setPosition(cursor);

// use text that uses 10 by 10 texels as a target resolution for fonts.
text-setFontResolution(10,10); // blocky but small texture memory usage

text-setText(text-setFontResolution(10,10); // blocky but small texture memory usage);
geode-addDrawable(text);
}

cursor.y() -= fontSizeCharacterSize;
{
osgText::Text* text = new osgText::Text;
text-setUseVertexBufferObjects(useVBOs);
text-setFont(font);

Re: [osg-users] osgText::Text::GlyphQuads change in the recent versions

2015-05-01 Thread Curtis Rubel

Hi Nick,

That is an interesting note for me as this is in the exact area
of the Text.cpp that the segv that I am having with the issue 
I posted on the forum...  The segv does not occur on 3.3.1, 
but does now on the trunk version I am running currently.  
I did not test on any releases prior to 337, but would be 
curious to see if it runs on 3.3.3, if it does it might help with 
finding the cause of the problem now

So I will download and test against 3.3.3, just for my issue.
... 

Thank you!

Cheers,
Curtis

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63592#63592





___
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

2015-05-01 Thread Robert Osfield

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.n...@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@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

Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

2015-05-01 Thread Curtis Rubel

Hi,

Just updated the attachment, had an extra include file that was not
present listed in the source that was not needed.  My apologies if this caused 
anyone any issues before I caught the problem.
... 

Thank you!

Cheers,
Curtis

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63595#63595





___
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

2015-05-01 Thread Trajce Nikolov NICK

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.osfi...@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.n...@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@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

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

2015-05-01 Thread Trajce Nikolov NICK

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

Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

2015-05-01 Thread Curtis Rubel

Hi Robert,

Thank you for looking in to this for us...

I did a quick test against the 3.3.3 release and it appears to be working OK.
So seems this has something to do with changes that occurred after that 
release. 

... 

Best Regards!,

Cheers,
Curtis

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63598#63598





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

2015-05-01 Thread Robert Osfield

Hi Curtis,

I'm currently looking at other bugs right now, coincidently in
osgText, but once these are addressed I'll try to have a look at the
crash you have.  This should be early next week.

Robet

On 1 May 2015 at 15:14, Curtis Rubel cru...@compro.net wrote:
 Hi Everyone,

 Attached to this post is an example that causes the segv to occur that I am 
 referring to in my first post on the subject.  This example is the 
 combination of portions the osgviewerQT and osgText examples as provided with 
 this same release of OpenSceneGraph.

 Hopefully with this example failing it can be determined what is happening.

 ...

 Thank you!

 Cheers,
 Curtis

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=63591#63591




 ___
 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

Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

2015-05-01 Thread Curtis Rubel

Hi Robert,

After getting the small example to fail today, I was looking some more and came 
up with a few changes here that allows me to run.

I am relatively sure that this will not be the final fix, but I am hoping that 
it will at least get you closer to what is causing the problem.  Here is an svn 
diff listing from my modified Text.cpp


Code:

Index: src/osgText/Text.cpp
===
--- src/osgText/Text.cpp(revision 14858)
+++ src/osgText/Text.cpp(working copy)
@@ -726,6 +726,12 @@
 GlyphQuads::Coords2 coords2 = glyphquad._coords;
 GlyphQuads::Coords3 transformedCoords = 
glyphquad._transformedCoords[contextID];
 
+if(transformedCoords == NULL)
+{
+   glyphquad._transformedCoords[contextID] = new osg::Vec3Array;   

 
+   transformedCoords = glyphquad._transformedCoords[contextID];

 
+}  

 
+   

 
 unsigned int numCoords = coords2-size();  

 
 if (numCoords != transformedCoords-size())

 
 {  

 
@@ -804,6 +810,12 @@

 
 for( ; backdrop_index  max_backdrop_index; backdrop_index++)  

 
 {  

 
 GlyphQuads::Coords3 transformedCoords = 
glyphquad._transformedBackdropCoords[backdrop_index][contextID];
   
+if(transformedCoords == NULL)  

 
+{  

 
+   glyphquad._transformedCoords[contextID] = new osg::Vec3Array;   

 
+   transformedCoords = glyphquad._transformedCoords[contextID];

 
+}  

 
+   

 
 unsigned int numCoords = coords2-size();
 if (numCoords!=transformedCoords-size())
 {
@@ -1288,7 +1300,7 @@
 if ( !_textureGlyphQuadMap.empty() )
 {
 const GlyphQuads glyphquad = (_textureGlyphQuadMap.begin())-second;
-if ( :q)
+if ( glyphquad._transformedCoords[contextID] == NULL )
 {
 computePositions(contextID);
 }





The diff at line 1303 in my source file:
-if ( glyphquad._transformedCoords[contextID]-empty() )
+if ( glyphquad._transformedCoords[contextID] == NULL )

The glyphquad._transformedCoords[contextID] call creates an
empty buffered object entry since the contextID coming in is not present, yet 
and the buffered_object API automatically resizes the array if it does not 
contain the value in the [] operator.  So now I check for NULL instead of 
empty() and thereby now calling computePositions(contextID).

The change in the

Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

2015-05-01 Thread Robert Osfield

Hi Curtis,

I haven't had a chance to look at the code yet but from your
description of the fix you've applied it suggests to me that the
normal scene graph mechanism used to inform the scene graph that the
number of contexts and hence range of ContextID's has changed is not
happening as it should be.

When a new context is created what should a happen is that the viewer
should call scenegraph-resizeGLObjectBuffers(maxContextID);  For some
reason in your application this doesn't seem to be happening.

Robert.

On 1 May 2015 at 20:49, Curtis Rubel cru...@compro.net wrote:
 Hi Robert,

 After getting the small example to fail today, I was looking some more and 
 came up with a few changes here that allows me to run.

 I am relatively sure that this will not be the final fix, but I am hoping 
 that it will at least get you closer to what is causing the problem.  Here is 
 an svn diff listing from my modified Text.cpp


 Code:

 Index: src/osgText/Text.cpp
 ===
 --- src/osgText/Text.cpp(revision 14858)
 +++ src/osgText/Text.cpp(working copy)
 @@ -726,6 +726,12 @@
  GlyphQuads::Coords2 coords2 = glyphquad._coords;
  GlyphQuads::Coords3 transformedCoords = 
 glyphquad._transformedCoords[contextID];

 +if(transformedCoords == NULL)
 +{
 +   glyphquad._transformedCoords[contextID] = new osg::Vec3Array;
 +   transformedCoords = glyphquad._transformedCoords[contextID];
 +}
 +
  unsigned int numCoords = coords2-size();
  if (numCoords != transformedCoords-size())
  {
 @@ -804,6 +810,12 @@
  for( ; backdrop_index  max_backdrop_index; backdrop_index++)
  {
  GlyphQuads::Coords3 transformedCoords = 
 glyphquad._transformedBackdropCoords[backdrop_index][contextID];
 +if(transformedCoords == NULL)
 +{
 +   glyphquad._transformedCoords[contextID] = new osg::Vec3Array;
 +   transformedCoords = glyphquad._transformedCoords[contextID];
 +}
 +
  unsigned int numCoords = coords2-size();
  if (numCoords!=transformedCoords-size())
  {
 @@ -1288,7 +1300,7 @@
  if ( !_textureGlyphQuadMap.empty() )
  {
  const GlyphQuads glyphquad = (_textureGlyphQuadMap.begin())-second;
 -if ( :q)
 +if ( glyphquad._transformedCoords[contextID] == NULL )
  {
  computePositions(contextID);
  }





 The diff at line 1303 in my source file:
 -if ( glyphquad._transformedCoords[contextID]-empty() )
 +if ( glyphquad._transformedCoords[contextID] == NULL )

 The glyphquad._transformedCoords[contextID] call creates an
 empty buffered object entry since the contextID coming in is not present, yet 
 and the buffered_object API automatically resizes the array if it does not 
 contain the value in the [] operator.  So now I check for NULL instead of 
 empty() and thereby now calling computePositions(contextID).

 The change in the computePositions function down around line 727
 checks to see if the GlyphQuads::Coords3 transformedCoords is NULL,
 if it is we add a new osg::Vec3Array in there  that then gets filled with
 what I hope is the correct data...

 Anyhow a brief explanation of what I did here to try and get some sort of 
 workaround as I was curious as to what was going on and had some spare time 
 this afternoon to look at it...

 Since you are already in the osgText code working maybe with this it will 
 allow you to get an idea of this issue and possibly incorporate both fixes at 
 the same time...well at least I hope so as by no means do I claim to know 
 much about this...hopefully me just trying to help did not confuse you more 
 instead.

 I am also attaching the patched version of the file to this post for you as 
 well..


 ...

 Thank you!

 Cheers,
 Curtis

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=63602#63602




 ___
 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

Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

2015-05-01 Thread Curtis Rubel

Robert,

One other thing to mention, I have another application that is pure OSG that is 
to say it is NOT using an QT widgets and it is doing basically the same thing 
as the QT app that I have and it runs OK as far as I can tell.  The example 
code I sent you that is failing is also based on the osgviewerQT example.

I am running QT 5.4.1 right now on my OpenSuSE 64bit linux system
in case you need that level of information to isolate the issue.

Another co-worker is running on MacOS and has told me that he is getting the 
same segv on his system so does not seem to be Linux specific.

... 

Thank you!

Cheers,
Curtis

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63604#63604





___
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

2015-05-01 Thread Robert Osfield

Hi NIck,

On 1 May 2015 at 19:11, Trajce Nikolov NICK
trajce.nikolov.n...@gmail.com 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

2015-05-01 Thread Trajce Nikolov NICK

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 robert.osfi...@gmail.com
wrote:

 Hi NIck,

 On 1 May 2015 at 19:11, Trajce Nikolov NICK
 trajce.nikolov.n...@gmail.com 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 osgShadow/StandardShadowMap
#include osg/PolygonOffset
#include osg/ComputeBoundsVisitor
#include osgShadow/ShadowedScene
#include osg/Geode
#include osg/Geometry
#include osg/CullFace
#include osg/AlphaFunc
#include osg/Point

#include stdio.h

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;

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

2015-05-01 Thread Trajce Nikolov NICK

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 robert.osfi...@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.n...@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@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] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

Re: [osg-users] osgText::Text::GlyphQuads change in the recent versions

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

Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

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

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

Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

Re: [osg-users] Segfault occuring in -- void Text::drawImplementation(osg::State state, const osg::Vec4 colorMultiplier) const -- after updating from osg 3.3.1 to the current trunk

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

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

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

14 matches

Site Navigation

Mail list logo

Footer information