[osg-users] Image Based Lighting

2014-05-13 Thread Patrik Andersson
HI,

I'm trying to implement Image Based Lighting in a scene. but I think I miss
something essential.
I have copied the fragment shader and vertex shader from the orange book,
ch 12/Image Based Lighting. Created a sphere which shall be the emissive
surface.

When I run I receive following warning/error msg:
Warning: detected OpenGL error 'invalid operation' at After
Renderer::compile.

The sphere is colored by the base-color, but it is not emissive. What kind
of attributes do I need to set to get it work, or should I make things in a
different order? See code below.

Kind regards
Patrik

This is the main code:
[code]
osgShadow::ShadowedScene* scene(new osgShadow::ShadowedScene());
osgShadow::ShadowMap* sm(new osgShadow::ShadowMap());
sm-setTextureSize(osg::Vec2s(512,512));
scene-setShadowTechnique(sm);
 osg::Group* root = new osg::Group;
osg::Geode* em = new osg::Geode();
em-addDrawable(new osg::ShapeDrawable(new osg::Sphere(osg::Vec3(0,0,0),
10.0) ) );
 osg::Geode* geode = new osg::Geode();
geode-addDrawable(new osg::ShapeDrawable( new
osg::Cylinder(osg::Vec3(0,0,-3.0),10,0.2
) )) ;
geode-setCullingActive(true);
root-addChild(em);
root-addChild(geode);
scene-addChild(root);
osg::TextureCubeMap* tex = readCubeMap();

{
osg::StateSet* ss = em-getOrCreateStateSet();
osg::Program* program = new osg::Program;
program-setName( IBL );
program-addShader( new osg::Shader( osg::Shader::VERTEX, IBLVertSource ) );
program-addShader( new osg::Shader( osg::Shader::FRAGMENT, IBLFragSource )
);

ss-setAttributeAndModes( program, osg::StateAttribute::ON );
osg::Uniform* baseColor = new osg::Uniform( BaseColor, osg::Vec3(0.2,
0.4, 0.6) );
osg::Uniform* specular = new osg::Uniform( SpecularPercent, 0);
osg::Uniform* diffuse = new osg::Uniform( DiffusePercent, 1.0);
osg::Uniform* specEnvMap = new osg::Uniform(SpecularEnvMap, 0);
osg::Uniform* diffEnvMap = new osg::Uniform( DiffuseEnvMap, 0);
 ss-setTextureAttributeAndModes(0, tex, osg::StateAttribute::ON );
ss-addUniform( baseColor );
ss-addUniform( specular );
ss-addUniform( diffuse );
ss-addUniform( specEnvMap );
ss-addUniform( diffEnvMap );
 }

viewer.setSceneData(scene);
viewer.run();
[/code]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Image Based Lighting

2014-05-13 Thread Sebastian Messerschmidt

Hi Patrick,

from a glimpse it seems you are setting up the shader to the geode while 
using osgShadow, which will override your shaders.
I guess you need to set the shaders at the shadowTechnique. Could you 
try it without osgShadow or simply do some shader debugging by setting 
the gl_FragColor to some debug value to see if your shader is used at all?


cheers
Sebastian

HI,

I'm trying to implement Image Based Lighting in a scene. but I think I 
miss something essential.
I have copied the fragment shader and vertex shader from the orange 
book, ch 12/Image Based Lighting. Created a sphere which shall be the 
emissive surface.


When I run I receive following warning/error msg:
Warning: detected OpenGL error 'invalid operation' at After 
Renderer::compile.


The sphere is colored by the base-color, but it is not emissive. What 
kind of attributes do I need to set to get it work, or should I make 
things in a different order? See code below.


Kind regards
Patrik

This is the main code:
[code]
osgShadow::ShadowedScene* scene(new osgShadow::ShadowedScene());
osgShadow::ShadowMap* sm(new osgShadow::ShadowMap());
sm-setTextureSize(osg::Vec2s(512,512));
scene-setShadowTechnique(sm);
osg::Group* root = new osg::Group;
osg::Geode* em = new osg::Geode();
em-addDrawable(new osg::ShapeDrawable(new 
osg::Sphere(osg::Vec3(0,0,0), 10.0) ) );

osg::Geode* geode = new osg::Geode();
geode-addDrawable(new osg::ShapeDrawable( new 
osg::Cylinder(osg::Vec3(0,0,-3.0),10,0.2 ) )) ;

geode-setCullingActive(true);
root-addChild(em);
root-addChild(geode);
scene-addChild(root);
osg::TextureCubeMap* tex = readCubeMap();

{
osg::StateSet* ss = em-getOrCreateStateSet();
osg::Program* program = new osg::Program;
program-setName( IBL );
program-addShader( new osg::Shader( osg::Shader::VERTEX, 
IBLVertSource ) );
program-addShader( new osg::Shader( osg::Shader::FRAGMENT, 
IBLFragSource ) );

ss-setAttributeAndModes( program, osg::StateAttribute::ON );
osg::Uniform* baseColor = new osg::Uniform( BaseColor, 
osg::Vec3(0.2, 0.4, 0.6) );

osg::Uniform* specular = new osg::Uniform( SpecularPercent, 0);
osg::Uniform* diffuse = new osg::Uniform( DiffusePercent, 1.0);
osg::Uniform* specEnvMap = new osg::Uniform(SpecularEnvMap, 0);
osg::Uniform* diffEnvMap = new osg::Uniform( DiffuseEnvMap, 0);
ss-setTextureAttributeAndModes(0, tex, osg::StateAttribute::ON );
ss-addUniform( baseColor );
ss-addUniform( specular );
ss-addUniform( diffuse );
ss-addUniform( specEnvMap );
ss-addUniform( diffEnvMap );
}

viewer.setSceneData(scene);
viewer.run();
[/code]


___
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] Image Based Lighting

2014-05-13 Thread Patrik Andersson
Hi Sebastian,

The baseColor is applied to the sphere, so I can see my shader is in use.
No differences when using osgShadow or not.

Cheers
Patrik


On Tue, May 13, 2014 at 10:03 AM, Sebastian Messerschmidt 
sebastian.messerschm...@gmx.de wrote:

  Hi Patrick,

 from a glimpse it seems you are setting up the shader to the geode while
 using osgShadow, which will override your shaders.
 I guess you need to set the shaders at the shadowTechnique. Could you try
 it without osgShadow or simply do some shader debugging by setting the
 gl_FragColor to some debug value to see if your shader is used at all?

 cheers
 Sebastian

 HI,

  I'm trying to implement Image Based Lighting in a scene. but I think I
 miss something essential.
 I have copied the fragment shader and vertex shader from the orange book,
 ch 12/Image Based Lighting. Created a sphere which shall be the emissive
 surface.

  When I run I receive following warning/error msg:
 Warning: detected OpenGL error 'invalid operation' at After
 Renderer::compile.

  The sphere is colored by the base-color, but it is not emissive. What
 kind of attributes do I need to set to get it work, or should I make things
 in a different order? See code below.

  Kind regards
 Patrik

  This is the main code:
 [code]
  osgShadow::ShadowedScene* scene(new osgShadow::ShadowedScene());
  osgShadow::ShadowMap* sm(new osgShadow::ShadowMap());
  sm-setTextureSize(osg::Vec2s(512,512));
  scene-setShadowTechnique(sm);
osg::Group* root = new osg::Group;
  osg::Geode* em = new osg::Geode();
  em-addDrawable(new osg::ShapeDrawable(new osg::Sphere(osg::Vec3(0,0,0),
 10.0) ) );
   osg::Geode* geode = new osg::Geode();
  geode-addDrawable(new osg::ShapeDrawable( new  
 osg::Cylinder(osg::Vec3(0,0,-3.0),10,0.2
 ) )) ;
  geode-setCullingActive(true);
  root-addChild(em);
  root-addChild(geode);
  scene-addChild(root);
  osg::TextureCubeMap* tex = readCubeMap();

  {
  osg::StateSet* ss = em-getOrCreateStateSet();
 osg::Program* program = new osg::Program;
 program-setName( IBL );
  program-addShader( new osg::Shader( osg::Shader::VERTEX, IBLVertSource
 ) );
  program-addShader( new osg::Shader( osg::Shader::FRAGMENT,
 IBLFragSource ) );

  ss-setAttributeAndModes( program, osg::StateAttribute::ON );
  osg::Uniform* baseColor = new osg::Uniform( BaseColor, osg::Vec3(0.2,
 0.4, 0.6) );
  osg::Uniform* specular = new osg::Uniform( SpecularPercent, 0);
  osg::Uniform* diffuse = new osg::Uniform( DiffusePercent, 1.0);
  osg::Uniform* specEnvMap = new osg::Uniform(SpecularEnvMap, 0);
  osg::Uniform* diffEnvMap = new osg::Uniform( DiffuseEnvMap, 0);
   ss-setTextureAttributeAndModes(0, tex, osg::StateAttribute::ON );
  ss-addUniform( baseColor );
  ss-addUniform( specular );
  ss-addUniform( diffuse );
  ss-addUniform( specEnvMap );
  ss-addUniform( diffEnvMap );
   }

  viewer.setSceneData(scene);
  viewer.run();
  [/code]


 ___
 osg-users mailing 
 listosg-users@lists.openscenegraph.orghttp://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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Image Based Lighting

2014-05-13 Thread Sebastian Messerschmidt

Hi Patrik,


Hi Sebastian,

The baseColor is applied to the sphere, so I can see my shader is in 
use. No differences when using osgShadow or not.
Yes because it is the first texture unit. Fixed function pipeline and 
osgShadow will handle it. Please follwo my advice and change the output 
of the fragment shader to

gl_FragColor = vec4(1,0,0,1) or gl_FragData[0] = vec4(1,0,0,1)
to see if it is _really_ your shader.

cheers
Sebastian



Cheers
Patrik


On Tue, May 13, 2014 at 10:03 AM, Sebastian Messerschmidt 
sebastian.messerschm...@gmx.de 
mailto:sebastian.messerschm...@gmx.de wrote:


Hi Patrick,

from a glimpse it seems you are setting up the shader to the geode
while using osgShadow, which will override your shaders.
I guess you need to set the shaders at the shadowTechnique. Could
you try it without osgShadow or simply do some shader debugging by
setting the gl_FragColor to some debug value to see if your shader
is used at all?

cheers
Sebastian

HI,

I'm trying to implement Image Based Lighting in a scene. but I
think I miss something essential.
I have copied the fragment shader and vertex shader from the
orange book, ch 12/Image Based Lighting. Created a sphere which
shall be the emissive surface.

When I run I receive following warning/error msg:
Warning: detected OpenGL error 'invalid operation' at After
Renderer::compile.

The sphere is colored by the base-color, but it is not emissive.
What kind of attributes do I need to set to get it work, or
should I make things in a different order? See code below.

Kind regards
Patrik

This is the main code:
[code]
osgShadow::ShadowedScene* scene(new osgShadow::ShadowedScene());
osgShadow::ShadowMap* sm(new osgShadow::ShadowMap());
sm-setTextureSize(osg::Vec2s(512,512));
scene-setShadowTechnique(sm);
osg::Group* root = new osg::Group;
osg::Geode* em = new osg::Geode();
em-addDrawable(new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0,0,0), 10.0) ) );
osg::Geode* geode = new osg::Geode();
geode-addDrawable(new osg::ShapeDrawable( new
osg::Cylinder(osg::Vec3(0,0,-3.0),10,0.2 ) )) ;
geode-setCullingActive(true);
root-addChild(em);
root-addChild(geode);
scene-addChild(root);
osg::TextureCubeMap* tex = readCubeMap();

{
osg::StateSet* ss = em-getOrCreateStateSet();
osg::Program* program = new osg::Program;
program-setName( IBL );
program-addShader( new osg::Shader( osg::Shader::VERTEX,
IBLVertSource ) );
program-addShader( new osg::Shader( osg::Shader::FRAGMENT,
IBLFragSource ) );
ss-setAttributeAndModes( program, osg::StateAttribute::ON );
osg::Uniform* baseColor = new osg::Uniform( BaseColor,
osg::Vec3(0.2, 0.4, 0.6) );
osg::Uniform* specular = new osg::Uniform( SpecularPercent, 0);
osg::Uniform* diffuse = new osg::Uniform( DiffusePercent, 1.0);
osg::Uniform* specEnvMap = new osg::Uniform(SpecularEnvMap, 0);
osg::Uniform* diffEnvMap = new osg::Uniform( DiffuseEnvMap, 0);
ss-setTextureAttributeAndModes(0, tex, osg::StateAttribute::ON );
ss-addUniform( baseColor );
ss-addUniform( specular );
ss-addUniform( diffuse );
ss-addUniform( specEnvMap );
ss-addUniform( diffEnvMap );
}

viewer.setSceneData(scene);
viewer.run();
[/code]


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



___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto: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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Image Based Lighting

2014-05-13 Thread Patrik Andersson
Hi Sebastian,

Yes, that works as well, the sphere is red.

cheers
Patrik


On Tue, May 13, 2014 at 10:32 AM, Sebastian Messerschmidt 
sebastian.messerschm...@gmx.de wrote:

  Hi Patrik,

  Hi Sebastian,

  The baseColor is applied to the sphere, so I can see my shader is in
 use. No differences when using osgShadow or not.

 Yes because it is the first texture unit. Fixed function pipeline and
 osgShadow will handle it. Please follwo my advice and change the output of
 the fragment shader to
 gl_FragColor = vec4(1,0,0,1) or gl_FragData[0] = vec4(1,0,0,1)
 to see if it is _really_ your shader.

 cheers
 Sebastian


  Cheers
 Patrik


 On Tue, May 13, 2014 at 10:03 AM, Sebastian Messerschmidt 
 sebastian.messerschm...@gmx.de wrote:

  Hi Patrick,

 from a glimpse it seems you are setting up the shader to the geode while
 using osgShadow, which will override your shaders.
 I guess you need to set the shaders at the shadowTechnique. Could you try
 it without osgShadow or simply do some shader debugging by setting the
 gl_FragColor to some debug value to see if your shader is used at all?

 cheers
 Sebastian

  HI,

  I'm trying to implement Image Based Lighting in a scene. but I think I
 miss something essential.
 I have copied the fragment shader and vertex shader from the orange book,
 ch 12/Image Based Lighting. Created a sphere which shall be the emissive
 surface.

  When I run I receive following warning/error msg:
 Warning: detected OpenGL error 'invalid operation' at After
 Renderer::compile.

  The sphere is colored by the base-color, but it is not emissive. What
 kind of attributes do I need to set to get it work, or should I make things
 in a different order? See code below.

  Kind regards
 Patrik

  This is the main code:
 [code]
  osgShadow::ShadowedScene* scene(new osgShadow::ShadowedScene());
  osgShadow::ShadowMap* sm(new osgShadow::ShadowMap());
  sm-setTextureSize(osg::Vec2s(512,512));
  scene-setShadowTechnique(sm);
osg::Group* root = new osg::Group;
  osg::Geode* em = new osg::Geode();
  em-addDrawable(new osg::ShapeDrawable(new
 osg::Sphere(osg::Vec3(0,0,0), 10.0) ) );
   osg::Geode* geode = new osg::Geode();
  geode-addDrawable(new osg::ShapeDrawable( new  
 osg::Cylinder(osg::Vec3(0,0,-3.0),10,0.2
 ) )) ;
  geode-setCullingActive(true);
  root-addChild(em);
  root-addChild(geode);
  scene-addChild(root);
  osg::TextureCubeMap* tex = readCubeMap();

  {
  osg::StateSet* ss = em-getOrCreateStateSet();
 osg::Program* program = new osg::Program;
 program-setName( IBL );
  program-addShader( new osg::Shader( osg::Shader::VERTEX, IBLVertSource
 ) );
  program-addShader( new osg::Shader( osg::Shader::FRAGMENT,
 IBLFragSource ) );

  ss-setAttributeAndModes( program, osg::StateAttribute::ON );
  osg::Uniform* baseColor = new osg::Uniform( BaseColor, osg::Vec3(0.2,
 0.4, 0.6) );
  osg::Uniform* specular = new osg::Uniform( SpecularPercent, 0);
  osg::Uniform* diffuse = new osg::Uniform( DiffusePercent, 1.0);
  osg::Uniform* specEnvMap = new osg::Uniform(SpecularEnvMap, 0);
  osg::Uniform* diffEnvMap = new osg::Uniform( DiffuseEnvMap, 0);
   ss-setTextureAttributeAndModes(0, tex, osg::StateAttribute::ON );
  ss-addUniform( baseColor );
  ss-addUniform( specular );
  ss-addUniform( diffuse );
  ss-addUniform( specEnvMap );
  ss-addUniform( diffEnvMap );
   }

  viewer.setSceneData(scene);
  viewer.run();
  [/code]


  ___
 osg-users mailing 
 listosg-users@lists.openscenegraph.orghttp://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 mailing 
 listosg-users@lists.openscenegraph.orghttp://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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Android osgPlugins

2014-05-13 Thread Nathan Collins
Hi Martin,
sorry it is not clear in this e-mail thread. This is using the 
osgAndroidExampleGLES2. As far as I can tell, the plugins are correctly 
declared:

//Static plugins Macro
USE_OSGPLUGIN(ive)
USE_OSGPLUGIN(osg)
USE_OSGPLUGIN(osg2)
USE_OSGPLUGIN(terrain)
USE_OSGPLUGIN(rgb)
USE_OSGPLUGIN(OpenFlight)
USE_OSGPLUGIN(dds)
//Static DOTOSG
USE_DOTOSGWRAPPER_LIBRARY(osg)
USE_DOTOSGWRAPPER_LIBRARY(osgFX)
USE_DOTOSGWRAPPER_LIBRARY(osgParticle)
USE_DOTOSGWRAPPER_LIBRARY(osgTerrain)
USE_DOTOSGWRAPPER_LIBRARY(osgText)
USE_DOTOSGWRAPPER_LIBRARY(osgViewer)
USE_DOTOSGWRAPPER_LIBRARY(osgVolume)
//Static serializer
USE_SERIALIZER_WRAPPER_LIBRARY(osg)
USE_SERIALIZER_WRAPPER_LIBRARY(osgAnimation)
USE_SERIALIZER_WRAPPER_LIBRARY(osgFX)
USE_SERIALIZER_WRAPPER_LIBRARY(osgManipulator)
USE_SERIALIZER_WRAPPER_LIBRARY(osgParticle)
USE_SERIALIZER_WRAPPER_LIBRARY(osgTerrain)
USE_SERIALIZER_WRAPPER_LIBRARY(osgText)
USE_SERIALIZER_WRAPPER_LIBRARY(osgVolume)

Cheers,
Nathan

From: osg-users [osg-users-boun...@lists.openscenegraph.org] on behalf of 
Martin Siggel [martinsiggel+...@gmail.com]
Sent: 13 May 2014 06:55
To: OpenSceneGraph Users
Subject: Re: [osg-users] Android osgPlugins


Static libraries can't be loaded on runtime. You have to link them on compile 
time. In order to use the plugins as static libs, you must declare them like in 
the osgandroid examples ( see osgmainapp header file )

Cheers,
Martin

Am 09.05.2014 16:40 schrieb Nathan Collins 
nat...@mve.commailto:nat...@mve.com:
Hi all,

I've got to this point again. I have built OSG and got the examples to run, but 
not load files. I'm getting the same issue from my original post:


Code:

05-09 14:33:04.726: E/Osg Viewer(4848): There are 1 models to load
05-09 14:33:04.726: E/Osg Viewer(4848): Loading: 
/storage/emulated/0/osg/cow.osgt
05-09 14:33:04.731: D/Osg Viewer(4848): itr='/vendor/lib'
05-09 14:33:04.731: D/Osg Viewer(4848): FindFileInPath() : trying 
/vendor/lib/osgPlugins-3.3.1/osgdb_osg.so ...
05-09 14:33:04.731: D/Osg Viewer(4848): itr='/system/lib'
05-09 14:33:04.731: D/Osg Viewer(4848): FindFileInPath() : trying 
/system/lib/osgPlugins-3.3.1/osgdb_osg.so ...
05-09 14:33:04.731: D/Osg Viewer(4848): itr='/usr/lib/'
05-09 14:33:04.731: D/Osg Viewer(4848): FindFileInPath() : trying 
/usr/lib/osgPlugins-3.3.1/osgdb_osg.so ...
05-09 14:33:04.731: D/Osg Viewer(4848): itr='/usr/local/lib/'
05-09 14:33:04.731: D/Osg Viewer(4848): FindFileInPath() : trying 
/usr/local/lib/osgPlugins-3.3.1/osgdb_osg.so ...
05-09 14:33:04.731: D/Osg Viewer(4848): itr='/vendor/lib'
05-09 14:33:04.731: D/Osg Viewer(4848): FindFileInPath() : trying 
/vendor/lib/osgdb_osg.so ...
05-09 14:33:04.731: D/Osg Viewer(4848): itr='/system/lib'
05-09 14:33:04.731: D/Osg Viewer(4848): FindFileInPath() : trying 
/system/lib/osgdb_osg.so ...
05-09 14:33:04.731: D/Osg Viewer(4848): itr='/usr/lib/'
05-09 14:33:04.731: D/Osg Viewer(4848): FindFileInPath() : trying 
/usr/lib/osgdb_osg.so ...
05-09 14:33:04.731: D/Osg Viewer(4848): itr='/usr/local/lib/'
05-09 14:33:04.731: D/Osg Viewer(4848): FindFileInPath() : trying 
/usr/local/lib/osgdb_osg.so ...
05-09 14:33:04.731: I/Osg Viewer(4848): Warning: dynamic library 
'osgPlugins-3.3.1/osgdb_osg.so' does not exist (or isn't readable):
05-09 14:33:04.731: I/Osg Viewer(4848): dlopen failed: library 
osgPlugins-3.3.1/osgdb_osg.so not found
05-09 14:33:04.731: I/Osg Viewer(4848): DynamicLibrary::failed loading 
osgPlugins-3.3.1/osgdb_osg.so
05-09 14:33:04.731: E/Osg Viewer(4848): Model not loaded




I have built OSG with the relevant flags to make it static, however I've built 
it against gnustl_shared. Does anyone know if this is what is causing OSG to 
look for shared versions of osgbd_osg.so rather than a static osgdb_osg.a?

I also noticed that it is not looking for libosgdb_osg.a. It was my 
understanding that the NDK toolchain prepends lib to all library names if it is 
not there.

Thanks,
Nathan.[/b]

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





___
osg-users mailing list
osg-users@lists.openscenegraph.orgmailto: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] Image Based Lighting

2014-05-13 Thread Sebastian Messerschmidt

Hi Patrik,


Okay, I've digged a bit deeper into your code. Somehow your code to add 
the textures seems awkward. You are assigning the cubemap to the first 
texture unit and create 3 uniforms to texture unit 0.
It is hard to tell what is going wrong on your side, given that small 
piece of code, but since you get an OpenGL error you should chase it 
down. It might be related to binding the texture to multiple sampler 
objects on the same texture unit.  Try to step back and bind the cubemap 
to a simple program with exactly one cubemap sampler and do some 
debugging with a simple cubemapping shader.
There is a osgcubemap example which you could extend to use shaders 
(beware that TexGen will not work with shaders, so you will have to 
write your own in the vertex shader, which is not complicated though)


I don't know the specific example you are referring to, so I cannot 
really give your more pointers unless you prepare a small compiling 
example.



Hi Sebastian,

Yes, that works as well, the sphere is red.

cheers
Patrik


On Tue, May 13, 2014 at 10:32 AM, Sebastian Messerschmidt 
sebastian.messerschm...@gmx.de 
mailto:sebastian.messerschm...@gmx.de wrote:


Hi Patrik,


Hi Sebastian,

The baseColor is applied to the sphere, so I can see my shader is
in use. No differences when using osgShadow or not.

Yes because it is the first texture unit. Fixed function pipeline
and osgShadow will handle it. Please follwo my advice and change
the output of the fragment shader to
gl_FragColor = vec4(1,0,0,1) or gl_FragData[0] = vec4(1,0,0,1)
to see if it is _really_ your shader.

cheers
Sebastian



Cheers
Patrik


On Tue, May 13, 2014 at 10:03 AM, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de
mailto:sebastian.messerschm...@gmx.de wrote:

Hi Patrick,

from a glimpse it seems you are setting up the shader to the
geode while using osgShadow, which will override your shaders.
I guess you need to set the shaders at the shadowTechnique.
Could you try it without osgShadow or simply do some shader
debugging by setting the gl_FragColor to some debug value to
see if your shader is used at all?

cheers
Sebastian

HI,

I'm trying to implement Image Based Lighting in a scene. but
I think I miss something essential.
I have copied the fragment shader and vertex shader from the
orange book, ch 12/Image Based Lighting. Created a sphere
which shall be the emissive surface.

When I run I receive following warning/error msg:
Warning: detected OpenGL error 'invalid operation' at After
Renderer::compile.

The sphere is colored by the base-color, but it is not
emissive. What kind of attributes do I need to set to get it
work, or should I make things in a different order? See code
below.

Kind regards
Patrik

This is the main code:
[code]
osgShadow::ShadowedScene* scene(new osgShadow::ShadowedScene());
osgShadow::ShadowMap* sm(new osgShadow::ShadowMap());
sm-setTextureSize(osg::Vec2s(512,512));
scene-setShadowTechnique(sm);
osg::Group* root = new osg::Group;
osg::Geode* em = new osg::Geode();
em-addDrawable(new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0,0,0), 10.0) ) );
osg::Geode* geode = new osg::Geode();
geode-addDrawable(new osg::ShapeDrawable( new
osg::Cylinder(osg::Vec3(0,0,-3.0),10,0.2 ) )) ;
geode-setCullingActive(true);
root-addChild(em);
root-addChild(geode);
scene-addChild(root);
osg::TextureCubeMap* tex = readCubeMap();

{
osg::StateSet* ss = em-getOrCreateStateSet();
osg::Program* program = new osg::Program;
program-setName( IBL );
program-addShader( new osg::Shader( osg::Shader::VERTEX,
IBLVertSource ) );
program-addShader( new osg::Shader( osg::Shader::FRAGMENT,
IBLFragSource ) );
ss-setAttributeAndModes( program, osg::StateAttribute::ON );
osg::Uniform* baseColor = new osg::Uniform( BaseColor,
osg::Vec3(0.2, 0.4, 0.6) );
osg::Uniform* specular = new osg::Uniform(
SpecularPercent, 0);
osg::Uniform* diffuse = new osg::Uniform( DiffusePercent,
1.0);
osg::Uniform* specEnvMap = new
osg::Uniform(SpecularEnvMap, 0);
osg::Uniform* diffEnvMap = new osg::Uniform(
DiffuseEnvMap, 0);
ss-setTextureAttributeAndModes(0, tex,
osg::StateAttribute::ON );
ss-addUniform( baseColor );
ss-addUniform( specular );
ss-addUniform( diffuse );
ss-addUniform( specEnvMap );
ss-addUniform( diffEnvMap );
}

viewer.setSceneData(scene);
viewer.run();
[/code]



Re: [osg-users] Image Based Lighting

2014-05-13 Thread Patrik Andersson
Hi Sebastian,

I have dig down and find the resolution of the OpenGL error, I passed an
int or double instead of a float into the shader. There is something
strange with how I assign the texture, I rewrote it as

[code]
osg::Uniform* specEnvMap = new
osg::Uniform(osg::Uniform::SAMPLER_CUBE,SpecularEnvMap);
specEnvMap-set(tex);
osg::Uniform* diffEnvMap = new osg::Uniform(osg::Uniform::SAMPLER_CUBE,
DiffuseEnvMap);
diffEnvMap-set(tex);
[/code]

To make sure that it is of type sampleCube.

I could upload all code, since I'm trying to write a minimal program which
demonstrates Image Based Lighting. It is two files, one header and one cpp,
in total 170 lines. Would that be of any help?

kind regards
Patrik


On Tue, May 13, 2014 at 11:04 AM, Sebastian Messerschmidt 
sebastian.messerschm...@gmx.de wrote:

  Hi Patrik,


 Okay, I've digged a bit deeper into your code. Somehow your code to add
 the textures seems awkward. You are assigning the cubemap to the first
 texture unit and create 3 uniforms to texture unit 0.
 It is hard to tell what is going wrong on your side, given that small
 piece of code, but since you get an OpenGL error you should chase it down.
 It might be related to binding the texture to multiple sampler objects on
 the same texture unit.  Try to step back and bind the cubemap to a simple
 program with exactly one cubemap sampler and do some debugging with a
 simple cubemapping shader.
 There is a osgcubemap example which you could extend to use shaders
 (beware that TexGen will not work with shaders, so you will have to write
 your own in the vertex shader, which is not complicated though)

 I don't know the specific example you are referring to, so I cannot really
 give your more pointers unless you prepare a small compiling example.

   Hi Sebastian,

  Yes, that works as well, the sphere is red.

  cheers
 Patrik


 On Tue, May 13, 2014 at 10:32 AM, Sebastian Messerschmidt 
 sebastian.messerschm...@gmx.de wrote:

  Hi Patrik,

   Hi Sebastian,

  The baseColor is applied to the sphere, so I can see my shader is in
 use. No differences when using osgShadow or not.

  Yes because it is the first texture unit. Fixed function pipeline and
 osgShadow will handle it. Please follwo my advice and change the output of
 the fragment shader to
 gl_FragColor = vec4(1,0,0,1) or gl_FragData[0] = vec4(1,0,0,1)
 to see if it is _really_ your shader.

 cheers
 Sebastian


  Cheers
 Patrik


 On Tue, May 13, 2014 at 10:03 AM, Sebastian Messerschmidt 
 sebastian.messerschm...@gmx.de wrote:

  Hi Patrick,

 from a glimpse it seems you are setting up the shader to the geode while
 using osgShadow, which will override your shaders.
 I guess you need to set the shaders at the shadowTechnique. Could you
 try it without osgShadow or simply do some shader debugging by setting the
 gl_FragColor to some debug value to see if your shader is used at all?

 cheers
 Sebastian

  HI,

  I'm trying to implement Image Based Lighting in a scene. but I think I
 miss something essential.
 I have copied the fragment shader and vertex shader from the orange
 book, ch 12/Image Based Lighting. Created a sphere which shall be the
 emissive surface.

  When I run I receive following warning/error msg:
 Warning: detected OpenGL error 'invalid operation' at After
 Renderer::compile.

  The sphere is colored by the base-color, but it is not emissive. What
 kind of attributes do I need to set to get it work, or should I make things
 in a different order? See code below.

  Kind regards
 Patrik

  This is the main code:
 [code]
  osgShadow::ShadowedScene* scene(new osgShadow::ShadowedScene());
  osgShadow::ShadowMap* sm(new osgShadow::ShadowMap());
  sm-setTextureSize(osg::Vec2s(512,512));
  scene-setShadowTechnique(sm);
osg::Group* root = new osg::Group;
  osg::Geode* em = new osg::Geode();
  em-addDrawable(new osg::ShapeDrawable(new
 osg::Sphere(osg::Vec3(0,0,0), 10.0) ) );
   osg::Geode* geode = new osg::Geode();
  geode-addDrawable(new osg::ShapeDrawable( new  
 osg::Cylinder(osg::Vec3(0,0,-3.0),10,0.2
 ) )) ;
  geode-setCullingActive(true);
  root-addChild(em);
  root-addChild(geode);
  scene-addChild(root);
  osg::TextureCubeMap* tex = readCubeMap();

  {
  osg::StateSet* ss = em-getOrCreateStateSet();
 osg::Program* program = new osg::Program;
 program-setName( IBL );
  program-addShader( new osg::Shader( osg::Shader::VERTEX,
 IBLVertSource ) );
  program-addShader( new osg::Shader( osg::Shader::FRAGMENT,
 IBLFragSource ) );

  ss-setAttributeAndModes( program, osg::StateAttribute::ON );
  osg::Uniform* baseColor = new osg::Uniform( BaseColor,
 osg::Vec3(0.2, 0.4, 0.6) );
  osg::Uniform* specular = new osg::Uniform( SpecularPercent, 0);
  osg::Uniform* diffuse = new osg::Uniform( DiffusePercent, 1.0);
  osg::Uniform* specEnvMap = new osg::Uniform(SpecularEnvMap, 0);
  osg::Uniform* diffEnvMap = new osg::Uniform( DiffuseEnvMap, 0);
   ss-setTextureAttributeAndModes(0, tex, osg::StateAttribute::ON );
  

Re: [osg-users] Image Based Lighting

2014-05-13 Thread Sebastian Messerschmidt

Hi Patrik,

Simply attach the code (probably compress it with zip) so others might 
check on this too.

Hi Sebastian,

I have dig down and find the resolution of the OpenGL error, I passed 
an int or double instead of a float into the shader. There is 
something strange with how I assign the texture, I rewrote it as


[code]
osg::Uniform* specEnvMap = new 
osg::Uniform(osg::Uniform::SAMPLER_CUBE,SpecularEnvMap);

specEnvMap-set(tex);
osg::Uniform* diffEnvMap = new 
osg::Uniform(osg::Uniform::SAMPLER_CUBE, DiffuseEnvMap);

diffEnvMap-set(tex);
[/code]

To make sure that it is of type sampleCube.

I could upload all code, since I'm trying to write a minimal program 
which demonstrates Image Based Lighting. It is two files, one header 
and one cpp, in total 170 lines. Would that be of any help?


kind regards
Patrik


On Tue, May 13, 2014 at 11:04 AM, Sebastian Messerschmidt 
sebastian.messerschm...@gmx.de 
mailto:sebastian.messerschm...@gmx.de wrote:


Hi Patrik,


Okay, I've digged a bit deeper into your code. Somehow your code
to add the textures seems awkward. You are assigning the cubemap
to the first texture unit and create 3 uniforms to texture unit 0.
It is hard to tell what is going wrong on your side, given that
small piece of code, but since you get an OpenGL error you should
chase it down. It might be related to binding the texture to
multiple sampler objects on the same texture unit.  Try to step
back and bind the cubemap to a simple program with exactly one
cubemap sampler and do some debugging with a simple cubemapping
shader.
There is a osgcubemap example which you could extend to use
shaders (beware that TexGen will not work with shaders, so you
will have to write your own in the vertex shader, which is not
complicated though)

I don't know the specific example you are referring to, so I
cannot really give your more pointers unless you prepare a small
compiling example.


Hi Sebastian,

Yes, that works as well, the sphere is red.

cheers
Patrik


On Tue, May 13, 2014 at 10:32 AM, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de
mailto:sebastian.messerschm...@gmx.de wrote:

Hi Patrik,


Hi Sebastian,

The baseColor is applied to the sphere, so I can see my
shader is in use. No differences when using osgShadow or not.

Yes because it is the first texture unit. Fixed function
pipeline and osgShadow will handle it. Please follwo my
advice and change the output of the fragment shader to
gl_FragColor = vec4(1,0,0,1) or gl_FragData[0] = vec4(1,0,0,1)
to see if it is _really_ your shader.

cheers
Sebastian



Cheers
Patrik


On Tue, May 13, 2014 at 10:03 AM, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de
mailto:sebastian.messerschm...@gmx.de wrote:

Hi Patrick,

from a glimpse it seems you are setting up the shader to
the geode while using osgShadow, which will override
your shaders.
I guess you need to set the shaders at the
shadowTechnique. Could you try it without osgShadow or
simply do some shader debugging by setting the
gl_FragColor to some debug value to see if your shader
is used at all?

cheers
Sebastian

HI,

I'm trying to implement Image Based Lighting in a
scene. but I think I miss something essential.
I have copied the fragment shader and vertex shader
from the orange book, ch 12/Image Based Lighting.
Created a sphere which shall be the emissive surface.

When I run I receive following warning/error msg:
Warning: detected OpenGL error 'invalid operation' at
After Renderer::compile.

The sphere is colored by the base-color, but it is not
emissive. What kind of attributes do I need to set to
get it work, or should I make things in a different
order? See code below.

Kind regards
Patrik

This is the main code:
[code]
osgShadow::ShadowedScene* scene(new
osgShadow::ShadowedScene());
osgShadow::ShadowMap* sm(new osgShadow::ShadowMap());
sm-setTextureSize(osg::Vec2s(512,512));
scene-setShadowTechnique(sm);
osg::Group* root = new osg::Group;
osg::Geode* em = new osg::Geode();
em-addDrawable(new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0,0,0), 10.0) ) );
osg::Geode* geode = new osg::Geode();
geode-addDrawable(new osg::ShapeDrawable( new
osg::Cylinder(osg::Vec3(0,0,-3.0),10,0.2 ) )) ;
geode-setCullingActive(true);
root-addChild(em);

Re: [osg-users] Image Based Lighting

2014-05-13 Thread Sebastian Messerschmidt

Can you add the texture as well?

cheers


Thank you Sebastian!


On Tue, May 13, 2014 at 11:18 AM, Sebastian Messerschmidt 
sebastian.messerschm...@gmx.de 
mailto:sebastian.messerschm...@gmx.de wrote:


Hi Patrik,

Simply attach the code (probably compress it with zip) so others
might check on this too.

Hi Sebastian,

I have dig down and find the resolution of the OpenGL error, I
passed an int or double instead of a float into the shader. There
is something strange with how I assign the texture, I rewrote it as

[code]
osg::Uniform* specEnvMap = new
osg::Uniform(osg::Uniform::SAMPLER_CUBE,SpecularEnvMap);
specEnvMap-set(tex);
osg::Uniform* diffEnvMap = new
osg::Uniform(osg::Uniform::SAMPLER_CUBE, DiffuseEnvMap);
diffEnvMap-set(tex);
[/code]

To make sure that it is of type sampleCube.

I could upload all code, since I'm trying to write a minimal
program which demonstrates Image Based Lighting. It is two files,
one header and one cpp, in total 170 lines. Would that be of any
help?

kind regards
Patrik


On Tue, May 13, 2014 at 11:04 AM, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de
mailto:sebastian.messerschm...@gmx.de wrote:

Hi Patrik,


Okay, I've digged a bit deeper into your code. Somehow your
code to add the textures seems awkward. You are assigning the
cubemap to the first texture unit and create 3 uniforms to
texture unit 0.
It is hard to tell what is going wrong on your side, given
that small piece of code, but since you get an OpenGL error
you should chase it down. It might be related to binding the
texture to multiple sampler objects on the same texture
unit.  Try to step back and bind the cubemap to a simple
program with exactly one cubemap sampler and do some
debugging with a simple cubemapping shader.
There is a osgcubemap example which you could extend to use
shaders (beware that TexGen will not work with shaders, so
you will have to write your own in the vertex shader, which
is not complicated though)

I don't know the specific example you are referring to, so I
cannot really give your more pointers unless you prepare a
small compiling example.


Hi Sebastian,

Yes, that works as well, the sphere is red.

cheers
Patrik


On Tue, May 13, 2014 at 10:32 AM, Sebastian Messerschmidt
sebastian.messerschm...@gmx.de
mailto:sebastian.messerschm...@gmx.de wrote:

Hi Patrik,


Hi Sebastian,

The baseColor is applied to the sphere, so I can see my
shader is in use. No differences when using osgShadow
or not.

Yes because it is the first texture unit. Fixed function
pipeline and osgShadow will handle it. Please follwo my
advice and change the output of the fragment shader to
gl_FragColor = vec4(1,0,0,1) or gl_FragData[0] =
vec4(1,0,0,1)
to see if it is _really_ your shader.

cheers
Sebastian



Cheers
Patrik


On Tue, May 13, 2014 at 10:03 AM, Sebastian
Messerschmidt sebastian.messerschm...@gmx.de
mailto:sebastian.messerschm...@gmx.de wrote:

Hi Patrick,

from a glimpse it seems you are setting up the
shader to the geode while using osgShadow, which
will override your shaders.
I guess you need to set the shaders at the
shadowTechnique. Could you try it without osgShadow
or simply do some shader debugging by setting the
gl_FragColor to some debug value to see if your
shader is used at all?

cheers
Sebastian

HI,

I'm trying to implement Image Based Lighting in a
scene. but I think I miss something essential.
I have copied the fragment shader and vertex
shader from the orange book, ch 12/Image Based
Lighting. Created a sphere which shall be the
emissive surface.

When I run I receive following warning/error msg:
Warning: detected OpenGL error 'invalid operation'
at After Renderer::compile.

The sphere is colored by the base-color, but it is
not emissive. What kind of attributes do I need to
set to get it work, or should I make things in a
different order? See code below.

Kind regards
Patrik

This is the main code:
[code]
osgShadow::ShadowedScene* scene(new
osgShadow::ShadowedScene());

Re: [osg-users] Image Based Lighting

2014-05-13 Thread Patrik Andersson
Hi Sebastian,

Thank you for sorting it out for me. Now the shader shows the texture, but
only for texture-unit 0, so I only get specular texture as your code show.

I do also wondering how I proceed with Image Based Lighting. Do I assign
the material above other materials in the scene to illuminate them or any
other approach?

Kind regards
Patrik


On Tue, May 13, 2014 at 12:16 PM, Sebastian Messerschmidt 
sebastian.messerschm...@gmx.de wrote:

  Hi Partrik,

 It was the setup of the textures and samplers:
 Try

 ss-setTextureAttributeAndModes(0, tex, osg::StateAttribute::ON ); //bind
 the texture to texture unit 0
 ss-setTextureAttributeAndModes(1, tex, osg::StateAttribute::ON );
 //you propably want to add a different texture for specular for texture
 unit 1


 ss-setAttributeAndModes( program, osg::StateAttribute::ON );
 osg::Uniform* baseColor = new osg::Uniform( BaseColor,
 osg::Vec3(1.0, 0.4, 0.6) );
 osg::Uniform* specular = new osg::Uniform( SpecularPercent,
 1.0f);
 osg::Uniform* diffuse = new osg::Uniform( DiffusePercent, 0.5f);
 //osg::Uniform* specEnvMap = new
 osg::Uniform(osg::Uniform::SAMPLER_CUBE,SpecularEnvMap);
 osg::Uniform* specEnvMap = new osg::Uniform(SpecularEnvMap, 0);
 //sampler for unit 0
 //specEnvMap-set(tex);
 //osg::Uniform* diffEnvMap = new
 osg::Uniform(osg::Uniform::SAMPLER_CUBE, DiffuseEnvMap); //The uniform is
 smart enough to create a correct sampler object using the texture type
 osg::Uniform* diffEnvMap = new osg::Uniform(DiffuseEnvMap,
 1);//sampler for unit 1
 //diffEnvMap-set(tex);



 ss-addUniform( baseColor );
 ss-addUniform( specular );
 ss-addUniform( diffuse );
 ss-addUniform( specEnvMap );
 ss-addUniform( diffEnvMap );


  Thank you Sebastian!


 On Tue, May 13, 2014 at 11:18 AM, Sebastian Messerschmidt 
 sebastian.messerschm...@gmx.de wrote:

  Hi Patrik,

 Simply attach the code (probably compress it with zip) so others might
 check on this too.

 Hi Sebastian,

  I have dig down and find the resolution of the OpenGL error, I passed
 an int or double instead of a float into the shader. There is something
 strange with how I assign the texture, I rewrote it as

  [code]
  osg::Uniform* specEnvMap = new
 osg::Uniform(osg::Uniform::SAMPLER_CUBE,SpecularEnvMap);
  specEnvMap-set(tex);
  osg::Uniform* diffEnvMap = new osg::Uniform(osg::Uniform::SAMPLER_CUBE,
 DiffuseEnvMap);
  diffEnvMap-set(tex);
  [/code]

  To make sure that it is of type sampleCube.

  I could upload all code, since I'm trying to write a minimal program
 which demonstrates Image Based Lighting. It is two files, one header and
 one cpp, in total 170 lines. Would that be of any help?

  kind regards
 Patrik


 On Tue, May 13, 2014 at 11:04 AM, Sebastian Messerschmidt 
 sebastian.messerschm...@gmx.de wrote:

  Hi Patrik,


 Okay, I've digged a bit deeper into your code. Somehow your code to add
 the textures seems awkward. You are assigning the cubemap to the first
 texture unit and create 3 uniforms to texture unit 0.
 It is hard to tell what is going wrong on your side, given that small
 piece of code, but since you get an OpenGL error you should chase it down.
 It might be related to binding the texture to multiple sampler objects on
 the same texture unit.  Try to step back and bind the cubemap to a simple
 program with exactly one cubemap sampler and do some debugging with a
 simple cubemapping shader.
 There is a osgcubemap example which you could extend to use shaders
 (beware that TexGen will not work with shaders, so you will have to write
 your own in the vertex shader, which is not complicated though)

 I don't know the specific example you are referring to, so I cannot
 really give your more pointers unless you prepare a small compiling
 example.

Hi Sebastian,

  Yes, that works as well, the sphere is red.

  cheers
 Patrik


 On Tue, May 13, 2014 at 10:32 AM, Sebastian Messerschmidt 
 sebastian.messerschm...@gmx.de wrote:

  Hi Patrik,

   Hi Sebastian,

  The baseColor is applied to the sphere, so I can see my shader is in
 use. No differences when using osgShadow or not.

  Yes because it is the first texture unit. Fixed function pipeline and
 osgShadow will handle it. Please follwo my advice and change the output of
 the fragment shader to
 gl_FragColor = vec4(1,0,0,1) or gl_FragData[0] = vec4(1,0,0,1)
 to see if it is _really_ your shader.

 cheers
 Sebastian


  Cheers
 Patrik


 On Tue, May 13, 2014 at 10:03 AM, Sebastian Messerschmidt 
 sebastian.messerschm...@gmx.de wrote:

  Hi Patrick,

 from a glimpse it seems you are setting up the shader to the geode
 while using osgShadow, which will override your shaders.
 I guess you need to set the shaders at the shadowTechnique. Could you
 try it without osgShadow or simply do some shader debugging by setting the
 gl_FragColor to some debug value to see if your shader is used at all?

 cheers
 

[osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node

2014-05-13 Thread Robert Osfield
Hi All,

Over the last day I have been experimenting with changing
osg::Drawable so that it is subclassed from osg::Node rather than
osg::Object.  The motivation behind this change is to make it simpler
to build scene graphs that only contain a single geometry and enabling
one to just directly attach a Geometry to the scene graph, without the
need for decorating it with a Geode first.

I have got the OSG build and running fine with this change, but I had
to make more changes to code that accessed Drawable than I'd have
liked, and this concerns me about the impact it may have on end users
that will be forced to update their code toI  ideally I'd get things
to a point where very few users need to do anything more than a
recompile against the new version of the OSG.  With this goal in mind
I'd like feedback from the community about what solutions

The problem area is the overlap between the Node::getBound() that
returns a BoundingSphere and the Drawable::getBound() that returns a
BoundingBox.  Any code that gets the bounding box from the Drawable
using the getBound() method will now fail to compile as it'll be
getting a BoundingSphere back in place.  My current workaround to this
is to have a Drawable::getBoundingBox() method that the can be used to
directly access the Drawable's BoundingBox.   This tweak is perfectly
valid implementation but it does require calling code to be modified.

Might there be alternatives that C++ can help us with?  In a perfect
world we'd be able to select the appropriate getBound() implementation
depending upon what type it's being assigned to ie.:

// get the bounding sphere of the Drawable
const BoundingSphere bs = drawable-getBound();

// but we also want the old code to keep compiling where we want
the bounding box
const BoundingBox bb = drawable-getBound();

I'm currently trying to think of ways to solve this conundrum.  There
might be a simple C++ trick that I've overlooked, which is why having
a nice big community of C++ programmers is an asset :-)

So what's solutions can you think of?

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


Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node

2014-05-13 Thread Lionel Lagarde

Hi,

Wonderful. Our code is full of:
  if the object is a drawable then
do something for the drawable
  else
do something for the node

For the getBound problem, I think there is no solution. The return type
is not included in the function prototype.

Lionel.


On 13/05/2014 17:13, Robert Osfield wrote:

Hi All,

Over the last day I have been experimenting with changing
osg::Drawable so that it is subclassed from osg::Node rather than
osg::Object.  The motivation behind this change is to make it simpler
to build scene graphs that only contain a single geometry and enabling
one to just directly attach a Geometry to the scene graph, without the
need for decorating it with a Geode first.

I have got the OSG build and running fine with this change, but I had
to make more changes to code that accessed Drawable than I'd have
liked, and this concerns me about the impact it may have on end users
that will be forced to update their code toI  ideally I'd get things
to a point where very few users need to do anything more than a
recompile against the new version of the OSG.  With this goal in mind
I'd like feedback from the community about what solutions

The problem area is the overlap between the Node::getBound() that
returns a BoundingSphere and the Drawable::getBound() that returns a
BoundingBox.  Any code that gets the bounding box from the Drawable
using the getBound() method will now fail to compile as it'll be
getting a BoundingSphere back in place.  My current workaround to this
is to have a Drawable::getBoundingBox() method that the can be used to
directly access the Drawable's BoundingBox.   This tweak is perfectly
valid implementation but it does require calling code to be modified.

Might there be alternatives that C++ can help us with?  In a perfect
world we'd be able to select the appropriate getBound() implementation
depending upon what type it's being assigned to ie.:

 // get the bounding sphere of the Drawable
 const BoundingSphere bs = drawable-getBound();

 // but we also want the old code to keep compiling where we want
the bounding box
 const BoundingBox bb = drawable-getBound();

I'm currently trying to think of ways to solve this conundrum.  There
might be a simple C++ trick that I've overlooked, which is why having
a nice big community of C++ programmers is an asset :-)

So what's solutions can you think of?

Robert.
___
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] Promoting Drawable from being subclassed from osg::Object to osg::Node

2014-05-13 Thread Robert Osfield
HI Lionel,

On 13 May 2014 16:56, Lionel Lagarde lionel.laga...@oktal-se.fr wrote:
 Wonderful. Our code is full of:
   if the object is a drawable then
 do something for the drawable
   else
 do something for the node

This is one of the benefits.  The existence of Geode and Drawable not
being a Node is actually a hang up of the very early days of the OSG.
Attempting to promote Drawable to Node and sucumvent the need for
using Geode is something I've been pondering for a very long time as
it simplifies usage of the scene graph in a number of cases, but
always known that some bits of the changes might be painful.

I think I've solved most of the painful bits already but I'm stuck
trying to find a way to keep end user code compiling when they use
const BoundingBox bb = drawable-getBound().

 For the getBound problem, I think there is no solution. The return type
 is not included in the function prototype.

The straight forward interpretation of C++ suggests this, and that the
only way to differentiate will be to have a different method name as I
have done the work I have done so far.  However, I know that C++ is
quite a rich language and there are sometimes clever ways to solve
certain problems, so I'm not giving up right away.

I'm currently wondering if a helper Bound class might be able to help,
with it providing automatic type conversion to BoundingSphere or
BoundingBox, the Node::getBound() would then return a Bound object,
that gets automatically cast to the type the user is using.

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


Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node

2014-05-13 Thread Robert Osfield
I have come up with a possible solution to my Drawable::getBound()
conundrum, it's a bit hacky/convoluted and itself might introduce
problems... but here it is for discussion, code below.

The basic idea is to pass back a temporary Bound object from
getBound() and have this provide the type conversion:


#include osg/BoundingBox
#include osg/BoundingSphere

struct Bound
{
Bound():
bb(0),
bs(0) {}

Bound(const osg::BoundingSphere bs):
bb(0),
bs(bs) {}

Bound(const osg::BoundingBox bb):
bb(bb),
bs(0) {}

Bound(const osg::BoundingSphere bs, const osg::BoundingBox bb):
bb(bb),
bs(bs) {}

const osg::BoundingBox*bb;
const osg::BoundingSphere* bs;

operator const osg::BoundingBox () const { return *bb; }
operator const osg::BoundingSphere () const { return *bs; }
};

struct BaseClass
{
osg::BoundingSphere _bs;
virtual Bound getBound() const { return Bound(_bs); }
};

struct SubClass : public BaseClass
{
osg::BoundingBox _bb;
virtual Bound getBound() const { return Bound(_bs, _bb); }
};


int main(int, char**)
{

BaseClass object1;
SubClass object2;

const osg::BoundingSphere bs1 = object1.getBound();
const osg::BoundingBox bb1 = object1.getBound();

OSG_NOTICEbs1 =  bs1std::endl;
OSG_NOTICEbb1 =  bb1std::endl;

const osg::BoundingSphere bs2 = object2.getBound();
const osg::BoundingBox bb2 = object2.getBound();

OSG_NOTICEbs2 =  bs2std::endl;
OSG_NOTICEbb2 =  bb2std::endl;

return 1;
}

The little OSG_NOTICE output works as expected, returning a valid
BoundingSphere and NULL BoundingBox for BaseClass, and a valid
BoundingSphere and valid BoundingBox for SubClass.

It could be that we have this Bound helper class just compiled in when
users want compatibility, but can disable this if they have converted
all their code to use the Drawable::getBoundingBox() method.

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


Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node

2014-05-13 Thread Glenn Waldron
Robert, do you see this impacting the concept of data variance, which has
traditionally had different semantics for a Drawable versus a Node?

Glenn Waldron / @glennwaldron


On Tue, May 13, 2014 at 11:13 AM, Robert Osfield
robert.osfi...@gmail.comwrote:

 Hi All,

 Over the last day I have been experimenting with changing
 osg::Drawable so that it is subclassed from osg::Node rather than
 osg::Object.  The motivation behind this change is to make it simpler
 to build scene graphs that only contain a single geometry and enabling
 one to just directly attach a Geometry to the scene graph, without the
 need for decorating it with a Geode first.

 I have got the OSG build and running fine with this change, but I had
 to make more changes to code that accessed Drawable than I'd have
 liked, and this concerns me about the impact it may have on end users
 that will be forced to update their code toI  ideally I'd get things
 to a point where very few users need to do anything more than a
 recompile against the new version of the OSG.  With this goal in mind
 I'd like feedback from the community about what solutions

 The problem area is the overlap between the Node::getBound() that
 returns a BoundingSphere and the Drawable::getBound() that returns a
 BoundingBox.  Any code that gets the bounding box from the Drawable
 using the getBound() method will now fail to compile as it'll be
 getting a BoundingSphere back in place.  My current workaround to this
 is to have a Drawable::getBoundingBox() method that the can be used to
 directly access the Drawable's BoundingBox.   This tweak is perfectly
 valid implementation but it does require calling code to be modified.

 Might there be alternatives that C++ can help us with?  In a perfect
 world we'd be able to select the appropriate getBound() implementation
 depending upon what type it's being assigned to ie.:

 // get the bounding sphere of the Drawable
 const BoundingSphere bs = drawable-getBound();

 // but we also want the old code to keep compiling where we want
 the bounding box
 const BoundingBox bb = drawable-getBound();

 I'm currently trying to think of ways to solve this conundrum.  There
 might be a simple C++ trick that I've overlooked, which is why having
 a nice big community of C++ programmers is an asset :-)

 So what's solutions can you think of?

 Robert.
 ___
 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] Promoting Drawable from being subclassed from osg::Object to osg::Node

2014-05-13 Thread Robert Osfield
HI Glenn,

On 13 May 2014 17:41, Glenn Waldron gwald...@gmail.com wrote:
 Robert, do you see this impacting the concept of data variance, which has
 traditionally had different semantics for a Drawable versus a Node?

No, the same rules will apply to Drawable in that their DataVariance
is used by the draw dispatch when multi-threading.

The usage of DataVariance on other Node's won't change either, it'll
still be their as hint to scene graph processing such as
osgUtil::Optimizer.

My hope with these changes is that the majority of existing
application will just work with no code changes, how close I can get
to this I don't know yet.

I have already checked in one related change that was a little less
controversial - that Node::ParentList used to be a vectorGroup* but
now is a vectorNode*, this change allows classes not subclass from
Group to now own children, which is what Geode will now do - it's
children will be Drawable Nodes.  I had to make a few OSG code changes
to handle this change but most code, and I expect most end user
application code won't need any changes so I went ahead and checked it
in.  If code does break then simply changing from a Group* to Node*
will typically be sufficient to keep the code compiling.

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


Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node

2014-05-13 Thread Robert Osfield
I have made a further tweak to my experimental Bound class, adding
center(), radius() from BoundingSphere and xMin(), yMin() etc. methods
from BoundingBox to help make it easier for Bound to act more like a
BoundingSphrere or BoundingBox.

In the code below I provide a segment that deliberately tries to
access BoundingBox methods from a BaseClass object that doesn't have a
BoundingBox so it accesses a NULL and creates a seg fault.  One could
potentially compute xMin() from a BoundingSphere, or we could throw an
exception. I'm not quite sure how much effort to make with this
temporary helper class though as it's only meant as a temporary helper
class to add porting to new versions of the OSG.

Thoughts?
Robert.

Latest Bound implementation:

struct Bound
{
Bound():
bb(0),
bs(0) {}

Bound(const osg::BoundingSphere bs):
bb(0),
bs(bs) {}

Bound(const osg::BoundingBox bb):
bb(bb),
bs(0) {}

Bound(const osg::BoundingSphere bs, const osg::BoundingBox bb):
bb(bb),
bs(bs) {}

const osg::BoundingBox*bb;
const osg::BoundingSphere* bs;

const osg::Vec3 center() const { return bs-center(); }
float radius() const { return bs-radius(); }

float xMin() const { return bb-xMin(); }
float yMin() const { return bb-yMin(); }
float zMin() const { return bb-zMin(); }

float xMax() const { return bb-xMax(); }
float yMax() const { return bb-yMax(); }
float zMax() const { return bb-zMax(); }

operator const osg::BoundingBox () const { return *bb; }
operator const osg::BoundingSphere () const { return *bs; }
};

struct BaseClass
{
osg::BoundingSphere _bs;
virtual Bound getBound() const { return Bound(_bs); }
};

struct SubClass : public BaseClass
{
osg::BoundingBox _bb;
virtual Bound getBound() const { return Bound(_bs, _bb); }
};


int main(int, char**)
{

BaseClass object1;
SubClass object2;

const osg::BoundingSphere bs1 = object1.getBound();
const osg::BoundingBox bb1 = object1.getBound();

OSG_NOTICEbs1 =  bs1std::endl;
OSG_NOTICEbb1 =  bb1std::endl;

const osg::BoundingSphere bs2 = object2.getBound();
const osg::BoundingBox bb2 = object2.getBound();

OSG_NOTICEbs2 =  bs2std::endl;
OSG_NOTICEbb2 =  bb2std::endl;

OSG_NOTICEcenter2 = object2.getBound().center()std::endl;
OSG_NOTICEradius2 = object2.getBound().radius()std::endl;

OSG_NOTICExMin2 = object2.getBound().xMin()std::endl;
OSG_NOTICExMax2 = object2.getBound().xMax()std::endl;


OSG_NOTICExMin1 = object1.getBound().xMin()std::endl;
OSG_NOTICExMax1 = object1.getBound().xMax()std::endl;

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


Re: [osg-users] Adding uniforms to shaders that are part of the osgShadow::MinimalShadowMap

2014-05-13 Thread Jaime
Thanks Nick!

Yes, I think it is an important issue. For example, a shadowed scene with bump 
mapping in the road.

It would be great if we could solve this!

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





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


Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node

2014-05-13 Thread Farshid Lashkari
Hi Robert,

I'm definitely in favor of this change. It will simplify a lot of code.

Regarding the change to Node::ParentList, I think this will cause some
breakage. I know I have a lot of code that assumes the elements of
ParentList are group nodes and performs Group operations on them (addChild,
removeChild, etc..). Perhaps Geode could be modified to inherit from Group
instead? The add/remove drawable methods could simply be wrappers for
add/remove child. Just throwing the idea out there, I'm sure this would
cause a whole host of other problems though. In general, I think breaking
code is going to be unavoidable.

The bounding sphere/box wrapper class is an interesting solution. I'm
worried about the potential for segfaults though. It might be better to
simply rename the method and force people to update their code at compile
time, rather than dealing with possible segfaults at runtime.

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