Re: [osg-users] strange pushModelViewMatrix behavior

[Emmanuel Roche]

Hi !

please forget about the previous question: it was simply due to the fact
that the _modelView matrix was shared between multiple objects because of a
desing error.

cheers,
Manu.


2011/11/21 Emmanuel Roche roche.emman...@gmail.com

 Hi everyone,

 I'm wondering about a strange thing I noticed when trying to use
 osgUtil::pushModelViewMatrix() directly:

 - Suppose I have a class where I store a ref pointer on a RefMatrix:

  osg::ref_ptrosg::RefMatrix _modelView.

 - Suppose in that class I have a function called during the cull traversal:

 draw(osgUtil::CullVisitor cv) {

osg::Matrixd mat =  // I compute the matrix I want to use as model
 view here.

 #if STRANGE_BEHAVIOR
   _modelView-set(mat)
   cv.pushModelViewMatrix( _modelView.get(), osg::Transform::RELATIVE_RF)
 #else
   cv.pushModelViewMatrix(new osg::RefMatrix(mat),
 osg::Transform::RELATIVE_RF)
 #endif

// drawing something here with a member geode object:
   _geode-accept(cv);
   cv.popModelViewMatrix();

 }

 = If I try the STRANGE_BEHAVIOR section, I get nothing displayed
 properly (even it the OSG Stats report a good number of vertices). If I use
 the other section everythig is fine...

 Any idea what I'm missing here ?? I think it would be better if I could
 avoid creating a new object on the heap for each call to this function :-)

 cheers,
 Manu.


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

[osg-users] strange pushModelViewMatrix behavior

[Emmanuel Roche]

Hi everyone,

I'm wondering about a strange thing I noticed when trying to use
osgUtil::pushModelViewMatrix() directly:

- Suppose I have a class where I store a ref pointer on a RefMatrix:

 osg::ref_ptrosg::RefMatrix _modelView.

- Suppose in that class I have a function called during the cull traversal:

draw(osgUtil::CullVisitor cv) {

   osg::Matrixd mat =  // I compute the matrix I want to use as model
view here.

#if STRANGE_BEHAVIOR
  _modelView-set(mat)
  cv.pushModelViewMatrix( _modelView.get(), osg::Transform::RELATIVE_RF)
#else
  cv.pushModelViewMatrix(new osg::RefMatrix(mat),
osg::Transform::RELATIVE_RF)
#endif

   // drawing something here with a member geode object:
  _geode-accept(cv);
  cv.popModelViewMatrix();

}

= If I try the STRANGE_BEHAVIOR section, I get nothing displayed
properly (even it the OSG Stats report a good number of vertices). If I use
the other section everythig is fine...

Any idea what I'm missing here ?? I think it would be better if I could
avoid creating a new object on the heap for each call to this function :-)

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

[osg-users] multiple cull traversal for single object

[Emmanuel Roche]

Hi everyone,

I have a question concerning the possible limitations that might exist in
the following scenario:

- Let's say I have a special node object in my scene graph:

class SpecialNode : public osg::Node {
protected:
  osg::ref_ptrosg::PositionAttitudeTransform _subgraph;

public:
  void traverse(osg::NodeVisitor nv);
}

- note that this SpecialNode is not even an osg::Group.
- on creation, I build a simple sphere geode with a
PositionAttitudeTransform, and store this directly in my SpecialNode with a
referenced pointer member, _subgraph
- I also specify a initialBounding sphere to avoid the complete special
node being removed because it has no size.
- I override the traverse(osg::NodeVisitor) function in that SpecialNode
so that, in case I have a cull traversal, I also do:

 _subgraph-accept(nv);

As a result, my subgraph is correctly displayed on screen when rendering
this scene.

Now more interesting, I can also do in this traverse() operation:

_subgraph-accept(nv)
_subgraph-setPosition(pos2)
_subgraph-accept(nv)
_subgraph-setPosition(pos3)
_subgraph-accept(nv)
...

And this will render multiple copies of my subgraph with the proper
position offsets.

= The question I have is : to which extend could such a mechanism be used:
- would this still work as expected, if instead of changing the Position, I
were to change:

   1. A StateAttribute in a sub stateset ?
   2. An uniform value ?

- Are there some obvious issues I should be aware of when using this
approach ?


The whole idea behind the scene is: I when to render a planet, and in this
traverse operation I am to generate multiple subtiles and cull them
(hundreds of them) so I would like to optimise the cull stage, and it
doesn't really make sense to store all the tiles as regular children since
they are always changing. And at the end I would consider directly pushing
the modelView matrix (to move to the proper tile location) on the cull
visitor, them traversing a shared tile template, then pushing the next
modelview matrix, etc... Any advise on this ? ;-)


Cheers,

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

Re: [osg-users] multiple cull traversal for single object

[Emmanuel Roche]

Hi J-S,

I was suspecting the pointer issue with statesets, thanks for your
clarifications!

But I didn't realize I could just as simply push/pop another stateset, will
certainly use that tip ! ;-)

Cheers,
Manu.




2011/11/17 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com

 Hi Emmanuel,

  = The question I have is : to which extend could such a mechanism be
 used:
 - would this still work as expected, if instead of changing the
 Position, I were to change:

  1. A StateAttribute in a sub stateset ?
  2. An uniform value ?


 No, not as simply as changing the position. The reason is that the cull
 visitor accumulates matrices by value, so each time you change the position
 and re-traverse you're adding a new matrix on the stack before each
 traversal. But Uniforms and state in general are accumulated by pointer
 (the last pointer that was in a StateSet when a drawable gets drawn is the
 one that is applied) so changing a uniform or other state attribute for the
 second traversal will change it for all instances of your object.

 However you can do it another way: create different statesets with the
 different attributes you want, and before calling accept() each time, do
 cv-pushStateSet(ss1.get()); and after do cv-popStateSet(); .


  - Are there some obvious issues I should be aware of when using this
 approach ?


 Not really, this is what the cull visitor does itself when it traverses a
 node (group, etc)...


  And at the end I would consider directly
 pushing the modelView matrix (to move to the proper tile location) on
 the cull visitor, them traversing a shared tile template, then pushing
 the next modelview matrix, etc... Any advise on this ? ;-)


 This is what you're doing (indirectly) with your setPosition() between
 each accept(). So it's fine.

 Hope this helps,

 J-S
 --
 __**
 Jean-Sébastien Guay
 jean-sebastien.guay@cm-labs.**comjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/

 http://whitestar02.dyndns-web.**com/http://whitestar02.dyndns-web.com/
 __**_
 osg-users mailing list
 osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
 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] Scene grph cycles with cameras

[Emmanuel Roche]

Hi everyone,

I have a simple question regarding pre/post render cameras:

- suppose I have a scene graph under a viewer camera
- the scene data for this camera starts with a root group.
- somewhere in that root group, I add a pre_render camera, to render a
texture on an FBO, and as a child of that pre render camera... I use the
root group itself !...

What would be the behavior in that case ?
- Would OSG notice that the pre_render camera is to be rendered before but
render it only once
- Or would OSG fail to notice this and prepare pre-pre-pre... pre-render
stages forever ? (and actually freeze completely) ?

Or is there a way to achieve what I want to do here properly if this option
is known to block ?

Basically, I want to render a World view camera but also the view of a
helicopter embedded camera on the complete world... (and the helicopter
itself is in the world obviously...)

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

Re: [osg-users] Scene grph cycles with cameras

[Emmanuel Roche]

Ok ! Thanks Paul

 that's unfortunately what I suspected :-)

Will go the way you suggested then.

Cheers,
Manu.


2011/10/6 Paul Martz pma...@skew-matrix.com

 On 10/6/2011 4:54 AM, Emmanuel Roche wrote:

 Hi everyone,

 I have a simple question regarding pre/post render cameras:

 - suppose I have a scene graph under a viewer camera
 - the scene data for this camera starts with a root group.
 - somewhere in that root group, I add a pre_render camera, to render a
 texture on an FBO, and as a child of that pre render camera... I use the
 root group itself !...


 OSG scene graphs must be acyclic, so don't do that.



 What would be the behavior in that case ?
 - Would OSG notice that the pre_render camera is to be rendered before but
 render it only once
 - Or would OSG fail to notice this and prepare pre-pre-pre... pre-render
 stages forever ? (and actually freeze completely) ?


 I'm guessing it would infinite loop, but there's no need to speculate: try
 it and see for yourself. :-)


  Or is there a way to achieve what I want to do here properly if this
 option is known to block ?


 Multiparent your scene, once to the pre-render camera, and once again to
 the root camera (which would also have the pre-render camera as a child).
   -Paul


 __**_
 osg-users mailing list
 osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
 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] Setting up FBO in drawable

[Emmanuel Roche]

Hi everyone,

I'm trying to setup an pure OpenGL FBO with render to texture target in an
OSG drawable. But I just can't figure out how to do that properly (eg. how
to isolate those pure openGL calls from the rest of the OSG scene).

in my drawa implementation I just have:

virtual void drawImplementation(osg::RenderInfo info) const
{
OSG_NOTICE  Drawing PingPongDrawable...;

osg::State* state = info.getState();
const unsigned int contextID = state-getContextID();

if(!_initialized  !init(contextID,*state)) {
OSG_WARN  Failed FBO setup!;
return;
}

state-checkGLErrors(end of PingPongDrawable drawing.);
}

So i'm really just calling an init function once to jus try to *create* an
FBO... I didn't even start using it..., the code of the init function is as
follow:

bool init(unsigned int contextID, osg::State state) const {

const FBOExtensions* fbo_ext =
FBOExtensions::instance(contextID,true);
const osg::Texture2DArray::Extensions* t2darray_ext =
osg::Texture2DArray::getExtensions(contextID,true);

// Push attribs to avoid collisions with existing OSG scene ?
glPushAttrib(GL_VIEWPORT_BIT | GL_COLOR_BUFFER_BIT | GL_TEXTURE_BIT |
GL_ENABLE_BIT);

state.checkGLErrors(Before PPD init.);

// Prepare the target texture for the FBO:
state.setActiveTextureUnit(1);
state.checkGLErrors(Activating texture slot 1);

int FFT_SIZE=256;

GLuint fftaTex = 0;
glGenTextures(1, fftaTex);
glBindTexture(GL_TEXTURE_2D_ARRAY_EXT, fftaTex);
glTexParameteri(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_MIN_FILTER,
GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_MAG_FILTER,
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D_ARRAY_EXT, GL_TEXTURE_MAX_ANISOTROPY_EXT,
16);
t2darray_ext-glTexImage3D(GL_TEXTURE_2D_ARRAY_EXT, 0, GL_RGBA16F_ARB,
FFT_SIZE, FFT_SIZE, 5, 0, GL_RGBA, GL_FLOAT, NULL);
fbo_ext-glGenerateMipmap(GL_TEXTURE_2D_ARRAY_EXT);
state.checkGLErrors(preparing target texture);


// Initialize the FBO
fbo_ext-glGenFramebuffers(1, _fftFbo);
state.checkGLErrors(Generating FBO);


fbo_ext-glBindFramebuffer(GL_FRAMEBUFFER_EXT, _fftFbo);
state.checkGLErrors(Bind Framebuffer in init.);
#ifdef ATTACH_TEXTURE
fbo_ext-glFramebufferTexture(GL_FRAMEBUFFER_EXT,
GL_COLOR_ATTACHMENT0_EXT, fftaTex, 0);
state.checkGLErrors(FramebufferTexture setup);
#endif
GLuint fboId = state.getGraphicsContext() ?
state.getGraphicsContext()-getDefaultFboId() : 0;
fbo_ext-glBindFramebuffer(GL_FRAMEBUFFER_EXT, fboId);


if(fbo_ext-glCheckFramebufferStatus(GL_FRAMEBUFFER_EXT) !=
GL_FRAMEBUFFER_COMPLETE_EXT) {
OSG_WARN  Error while setting up Pingpong FBO.;
}

state.checkGLErrors(end of Framebuffer settings);

glBindTexture( GL_TEXTURE_2D_ARRAY_EXT, 0 );

glPopAttrib();

_initialized = true;
return true;
}

Adding such a drawable in my scene, i don't have any problem as long as
ATTACH_TEXTURE is *undefined*. But when I define this, I still don't have
any error reported by the drawable itself (all the checkGLErrors I
inserted). But then getcontinous list of

 Warning: detected OpenGL error 'invalid operation' at after
RenderBin::draw(..) messages :-(

= Any idea what I'm doing wrong here ? How can I enforce the isolation
between those openGL calls and what's left from the OSG scene ? after all,
since this init function is called only once, there should not be any
continous warning report if it didn't have a side effect outside of this
drawable encapsulation...


Thanks for you help !! I really feel desperated now... :'(

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

Re: [osg-users] Setting up FBO in drawable

[Emmanuel Roche]

Thanks J.P,

but actually I know the gameoflife example almost by heart already and this
won't fit the bill: I need a real single pass ping pong rendering here if
I want to achieve good performances.

Cheers,
Manu.


2011/9/28 J.P. Delport jpdelp...@csir.co.za

 Hi,

 I can't help you with your specific drawable question, but what would you
 like to achieve? In the osggameoflife example there is an example of
 ping-pong using multiple cameras and switches. You can also swap output
 textures if they are exactly the same using a callback. See here for
 inspiration:
 http://code.google.com/p/**flitr/source/browse/trunk/**
 examples/keep_history_pass/**keep_history_pass.cpphttp://code.google.com/p/flitr/source/browse/trunk/examples/keep_history_pass/keep_history_pass.cpp

 cheers
 jp


 On 28/09/2011 10:45, Emmanuel Roche wrote:

 Hi everyone,

 I'm trying to setup an pure OpenGL FBO with render to texture target in
 an OSG drawable. But I just can't figure out how to do that properly
 (eg. how to isolate those pure openGL calls from the rest of the OSG
 scene).

 in my drawa implementation I just have:

 virtual void drawImplementation(osg::**RenderInfo info) const
 {
 OSG_NOTICE  Drawing PingPongDrawable...;

 osg::State* state = info.getState();
 const unsigned int contextID = state-getContextID();

 if(!_initialized  !init(contextID,*state)) {
 OSG_WARN  Failed FBO setup!;
 return;
 }

 state-checkGLErrors(end of PingPongDrawable drawing.);
 }

 So i'm really just calling an init function once to jus try to
 _create_ an FBO... I didn't even start using it..., the code of the init
 function is as follow:

 bool init(unsigned int contextID, osg::State state) const {

 const FBOExtensions* fbo_ext =
 FBOExtensions::instance(**contextID,true);
 const osg::Texture2DArray::**Extensions* t2darray_ext =
 osg::Texture2DArray::**getExtensions(contextID,true);

 // Push attribs to avoid collisions with existing OSG scene ?
 glPushAttrib(GL_VIEWPORT_BIT | GL_COLOR_BUFFER_BIT | GL_TEXTURE_BIT
 | GL_ENABLE_BIT);

 state.checkGLErrors(Before PPD init.);

 // Prepare the target texture for the FBO:
 state.setActiveTextureUnit(1);
 state.checkGLErrors(**Activating texture slot 1);

 int FFT_SIZE=256;

 GLuint fftaTex = 0;
 glGenTextures(1, fftaTex);
 glBindTexture(GL_TEXTURE_2D_**ARRAY_EXT, fftaTex);
 glTexParameteri(GL_TEXTURE_2D_**ARRAY_EXT, GL_TEXTURE_MIN_FILTER,
 GL_LINEAR_MIPMAP_LINEAR);
 glTexParameteri(GL_TEXTURE_2D_**ARRAY_EXT, GL_TEXTURE_MAG_FILTER,
 GL_LINEAR);
 glTexParameteri(GL_TEXTURE_2D_**ARRAY_EXT, GL_TEXTURE_WRAP_S,
 GL_REPEAT);
 glTexParameteri(GL_TEXTURE_2D_**ARRAY_EXT, GL_TEXTURE_WRAP_T,
 GL_REPEAT);
 glTexParameterf(GL_TEXTURE_2D_**ARRAY_EXT,
 GL_TEXTURE_MAX_ANISOTROPY_EXT, 16);
 t2darray_ext-glTexImage3D(GL_**TEXTURE_2D_ARRAY_EXT, 0,
 GL_RGBA16F_ARB, FFT_SIZE, FFT_SIZE, 5, 0, GL_RGBA, GL_FLOAT, NULL);
 fbo_ext-glGenerateMipmap(GL_**TEXTURE_2D_ARRAY_EXT);
 state.checkGLErrors(preparing target texture);


 // Initialize the FBO
 fbo_ext-glGenFramebuffers(1, _fftFbo);
 state.checkGLErrors(**Generating FBO);


 fbo_ext-glBindFramebuffer(GL_**FRAMEBUFFER_EXT, _fftFbo);
 state.checkGLErrors(Bind Framebuffer in init.);
 #ifdef ATTACH_TEXTURE
 fbo_ext-glFramebufferTexture(**GL_FRAMEBUFFER_EXT,
 GL_COLOR_ATTACHMENT0_EXT, fftaTex, 0);
 state.checkGLErrors(**FramebufferTexture setup);
 #endif
 GLuint fboId = state.getGraphicsContext() ?
 state.getGraphicsContext()-**getDefaultFboId() : 0;
 fbo_ext-glBindFramebuffer(GL_**FRAMEBUFFER_EXT, fboId);


 if(fbo_ext-**glCheckFramebufferStatus(GL_**FRAMEBUFFER_EXT) !=
 GL_FRAMEBUFFER_COMPLETE_EXT) {
 OSG_WARN  Error while setting up Pingpong FBO.;
 }

 state.checkGLErrors(end of Framebuffer settings);

 glBindTexture( GL_TEXTURE_2D_ARRAY_EXT, 0 );

 glPopAttrib();

 _initialized = true;
 return true;
 }

 Adding such a drawable in my scene, i don't have any problem as long as
 ATTACH_TEXTURE is *undefined*. But when I define this, I still don't
 have any error reported by the drawable itself (all the checkGLErrors I
 inserted). But then getcontinous list of

  Warning: detected OpenGL error 'invalid operation' at after
 RenderBin::draw(..) messages :-(

 = Any idea what I'm doing wrong here ? How can I enforce the
 isolation between those openGL calls and what's left from the OSG scene
 ? after all, since this init function is called only once, there should
 not be any continous warning report if it didn't have a side effect
 outside of this drawable encapsulation...


 Thanks for you help !! I really feel desperated now... :'(

 Manu.





 __**_
 osg-users mailing list
 osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
 openscenegraph.orghttp

Re: [osg-users] Setting up FBO in drawable

[Emmanuel Roche]

 with multiple OSG cameras? Is it too slow for you?

 jp


 On 28/09/2011 11:30, Emmanuel Roche wrote:

 Thanks J.P,

 but actually I know the gameoflife example almost by heart already and
 this won't fit the bill: I need a real single pass ping pong rendering
 here if I want to achieve good performances.

 Cheers,
 Manu.


 2011/9/28 J.P. Delport jpdelp...@csir.co.za mailto:jpdelp...@csir.co.za
 


Hi,

I can't help you with your specific drawable question, but what
would you like to achieve? In the osggameoflife example there is an
example of ping-pong using multiple cameras and switches. You can
also swap output textures if they are exactly the same using a
callback. See here for inspiration:
http://code.google.com/p/__**flitr/source/browse/trunk/__**
 examples/keep_history_pass/__**keep_history_pass.cpphttp://code.google.com/p/__flitr/source/browse/trunk/__examples/keep_history_pass/__keep_history_pass.cpp
http://code.google.com/p/**flitr/source/browse/trunk/**
 examples/keep_history_pass/**keep_history_pass.cpphttp://code.google.com/p/flitr/source/browse/trunk/examples/keep_history_pass/keep_history_pass.cpp
 

cheers
jp


On 28/09/2011 10:45, Emmanuel Roche wrote:

Hi everyone,

I'm trying to setup an pure OpenGL FBO with render to texture
target in
an OSG drawable. But I just can't figure out how to do that
properly
(eg. how to isolate those pure openGL calls from the rest of
the OSG
scene).

in my drawa implementation I just have:

virtual void drawImplementation(osg::__**RenderInfo info) const
{
 OSG_NOTICE  Drawing PingPongDrawable...;

 osg::State* state = info.getState();
 const unsigned int contextID = state-getContextID();

 if(!_initialized  !init(contextID,*state)) {
 OSG_WARN  Failed FBO setup!;
 return;
 }

 state-checkGLErrors(end of PingPongDrawable drawing.);
}

So i'm really just calling an init function once to jus try to
_create_ an FBO... I didn't even start using it..., the code of
the init
function is as follow:

bool init(unsigned int contextID, osg::State state) const {

 const FBOExtensions* fbo_ext =
FBOExtensions::instance(__**contextID,true);
 const osg::Texture2DArray::__**Extensions* t2darray_ext =
osg::Texture2DArray::__**getExtensions(contextID,true);

 // Push attribs to avoid collisions with existing OSG scene ?
 glPushAttrib(GL_VIEWPORT_BIT | GL_COLOR_BUFFER_BIT |
GL_TEXTURE_BIT
| GL_ENABLE_BIT);

 state.checkGLErrors(Before PPD init.);

 // Prepare the target texture for the FBO:
 state.setActiveTextureUnit(1);
 state.checkGLErrors(__**Activating texture slot 1);

 int FFT_SIZE=256;

 GLuint fftaTex = 0;
 glGenTextures(1, fftaTex);
 glBindTexture(GL_TEXTURE_2D___**ARRAY_EXT, fftaTex);
 glTexParameteri(GL_TEXTURE_2D_**__ARRAY_EXT,
GL_TEXTURE_MIN_FILTER,
GL_LINEAR_MIPMAP_LINEAR);
 glTexParameteri(GL_TEXTURE_2D_**__ARRAY_EXT,
GL_TEXTURE_MAG_FILTER,
GL_LINEAR);
 glTexParameteri(GL_TEXTURE_2D_**__ARRAY_EXT,
GL_TEXTURE_WRAP_S, GL_REPEAT);
 glTexParameteri(GL_TEXTURE_2D_**__ARRAY_EXT,
GL_TEXTURE_WRAP_T, GL_REPEAT);
 glTexParameterf(GL_TEXTURE_2D_**__ARRAY_EXT,
GL_TEXTURE_MAX_ANISOTROPY_EXT, 16);
 t2darray_ext-glTexImage3D(GL_**__TEXTURE_2D_ARRAY_EXT, 0,
GL_RGBA16F_ARB, FFT_SIZE, FFT_SIZE, 5, 0, GL_RGBA, GL_FLOAT, NULL);
 fbo_ext-glGenerateMipmap(GL__**_TEXTURE_2D_ARRAY_EXT);
 state.checkGLErrors(preparing target texture);


 // Initialize the FBO
 fbo_ext-glGenFramebuffers(1, _fftFbo);
 state.checkGLErrors(__**Generating FBO);


 fbo_ext-glBindFramebuffer(GL_**__FRAMEBUFFER_EXT, _fftFbo);
 state.checkGLErrors(Bind Framebuffer in init.);
#ifdef ATTACH_TEXTURE
 fbo_ext-glFramebufferTexture(**__GL_FRAMEBUFFER_EXT,
GL_COLOR_ATTACHMENT0_EXT, fftaTex, 0);
 state.checkGLErrors(__**FramebufferTexture setup);
#endif
 GLuint fboId = state.getGraphicsContext() ?
state.getGraphicsContext()-__**getDefaultFboId() : 0;
 fbo_ext-glBindFramebuffer(GL_**__FRAMEBUFFER_EXT, fboId);


 if(fbo_ext-__**glCheckFramebufferStatus(GL___**FRAMEBUFFER_EXT)
 !=
GL_FRAMEBUFFER_COMPLETE_EXT) {
 OSG_WARN  Error while setting up Pingpong FBO.;
 }

 state.checkGLErrors(end of Framebuffer settings);

 glBindTexture( GL_TEXTURE_2D_ARRAY_EXT, 0 );

 glPopAttrib

Re: [osg-users] Setting up FBO in drawable

[Emmanuel Roche]

Hi !

I performed some additional tests on this issue and now I think I'm reaching
the bottom of it:

when I attach my Texture2DArray as:


cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER0,result.ffts[1],0,0,true);


cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER1,result.ffts[0],0,0,true);

And then force the GLSL program to only handle and write the computed values
for layer 0, the final result is perfect (on layer 0 of the Texture2DArray).

Now, if I switch the indexes to handle the layer 1 with:


cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER0,result.ffts[1],0,1,true);


cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER1,result.ffts[0],0,1,true);

And then force the GLSL program to write only that layer 1 data, then may
layer 1 on the second Texture2DArray is completely black and the layer 1 on
the first Texture2DArray seems unchanged (that first Texture2DArray is
initialized first with non zero data.

= So it seems nothing in written on my layers 1 on that second case.

No idea what could be wrong with those Texture2DArray targets ?

Cheers,
Manu.


2011/9/28 Emmanuel Roche roche.emman...@gmail.com

 Yes J.P,

 as far as I understand the code I'm trying to integrate into OSG, this step
 will basically perform a FFT computation on the GPU.

 The code I'm using as template is written in pure opengl: it is the Ocean
 lighting implementation from Eric Brunetton (
 http://evasion.inrialpes.fr/~Eric.Bruneton/). My goal is to integrate this
 code with osgEarth and achieve realistic ocean rendering this way.

 in the opengl implementation, he is basically doing this:

  1. Setting up 2 texture2Darrays with 5 layers both
  2. attaching those texture arrays as color buffer 0 and 1 on a FBO,
  3. ping ponging the rendering between those two texture arrays with 2x8
 passes in a single rendering cycle (= a single frame), this is done this
 way:

 glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fftFbo2);
 glUseProgram(fftx-program);
 glUniform1i(glGetUniformLocation(fftx-program, nLayers), choppy ? 5 :
 3);
 for (int i = 0; i  2; ++i) { //
 glUniform1f(glGetUniformLocation(fftx-program, pass), float(i + 0.5)
 / PASSES);
 if (i%2 == 0) {
 glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
 FFT_A_UNIT);
 glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
 } else {
 glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
 FFT_B_UNIT);
 glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
 }
 drawQuad();
 }

 glUseProgram(ffty-program);
 glUniform1i(glGetUniformLocation(ffty-program, nLayers), choppy ? 5 :
 3);
 for (int i = PASSES; i  2 * PASSES; ++i) {
 glUniform1f(glGetUniformLocation(ffty-program, pass), float(i -
 PASSES + 0.5) / PASSES);
 if (i%2 == 0) {
 glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
 FFT_A_UNIT);
 glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
 } else {
 glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
 FFT_B_UNIT);
 glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
 }
 drawQuad();
 }

 glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

 = as you can see, a single FBO is used and the glDrawBuffer is called
 multiple times to toggle the target on the fly.

 The good news in this story is, I don't if you following my previous
 discussion with Sergey, (thread called Changing DrawBuffer for FBO) but it
 turns out the DrawBuffer stateAttribute I created is working just as
 expected in fact 

 So this ping pong implementation is basically working, but the problem I
 noticed comes from another point: the GLSL program used in the process.

 in the openGL code, the two texture2D arrays are attached to the FBO this
 way:

 glGenFramebuffersEXT(1, fftFbo2);
 glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fftFbo2);
 glReadBuffer(GL_COLOR_ATTACHMENT0_EXT);
 glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
 glFramebufferTextureEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,
 fftaTex, 0);
 glFramebufferTextureEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT,
 fftbTex, 0);
 glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

 So, in my OSG implementation I turned that into (this is lua code):


 cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER0,result.ffts[1],0,0,true);


 cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER1,result.ffts[0],0,0,true);

 But, now I think the problem comes from how those bindings are
 interpretated in both case:

   - the GLSL program performing the rendering contains a geometry shader.
 and this shader with emit a screen quad for each of the 5 layers in the
 texture2Darray, then the fragment shader just use the gl_FragColor as target
 and it seems that:
   - with the pure OpenGL code, automagically, the texture2DArray layer that
 is written it is the layer corresponding to the geometry layer currently
 emitted...
   - Whereas in the OSG code, the results are... well... it seems only the
 first layer is attached... which would make sense this the second 0 after

Re: [osg-users] Setting up FBO in drawable

[Emmanuel Roche]

 hmmm and God created:

*osg::Camera::FACE_CONTROLLED_**BY_GEOMETRY_SHADER*

and

*setImplicitBufferAttachmentMask(osg.Camera.ImplicitBufferAttachment.IMPLICIT_COLOR_BUFFER_ATTACHMENT,
osg.Camera.ImplicitBufferAttachment.IMPLICIT_COLOR_BUFFER_ATTACHMENT);*

It now works perfectly !! That's the most beautiful day in my life !
(well... almost :-) )

Thanks for your support guys!

Now I can finally proceed with this task.

Cheers,
Manu.




2011/9/28 Emmanuel Roche roche.emman...@gmail.com

 Hi !

 I performed some additional tests on this issue and now I think I'm
 reaching the bottom of it:

 when I attach my Texture2DArray as:



 cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER0,result.ffts[1],0,0,true);


 cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER1,result.ffts[0],0,0,true);

 And then force the GLSL program to only handle and write the computed
 values for layer 0, the final result is perfect (on layer 0 of the
 Texture2DArray).

 Now, if I switch the indexes to handle the layer 1 with:


 cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER0,result.ffts[1],0,1,true);


 cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER1,result.ffts[0],0,1,true);

 And then force the GLSL program to write only that layer 1 data, then may
 layer 1 on the second Texture2DArray is completely black and the layer 1 on
 the first Texture2DArray seems unchanged (that first Texture2DArray is
 initialized first with non zero data.

 = So it seems nothing in written on my layers 1 on that second case.

 No idea what could be wrong with those Texture2DArray targets ?

 Cheers,
 Manu.



 2011/9/28 Emmanuel Roche roche.emman...@gmail.com

 Yes J.P,

 as far as I understand the code I'm trying to integrate into OSG, this
 step will basically perform a FFT computation on the GPU.

 The code I'm using as template is written in pure opengl: it is the Ocean
 lighting implementation from Eric Brunetton (
 http://evasion.inrialpes.fr/~Eric.Bruneton/). My goal is to integrate
 this code with osgEarth and achieve realistic ocean rendering this way.

 in the opengl implementation, he is basically doing this:

  1. Setting up 2 texture2Darrays with 5 layers both
  2. attaching those texture arrays as color buffer 0 and 1 on a FBO,
  3. ping ponging the rendering between those two texture arrays with 2x8
 passes in a single rendering cycle (= a single frame), this is done this
 way:

 glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fftFbo2);
 glUseProgram(fftx-program);
 glUniform1i(glGetUniformLocation(fftx-program, nLayers), choppy ? 5 :
 3);
 for (int i = 0; i  2; ++i) { //
 glUniform1f(glGetUniformLocation(fftx-program, pass), float(i +
 0.5) / PASSES);
 if (i%2 == 0) {
 glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
 FFT_A_UNIT);
 glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
 } else {
 glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
 FFT_B_UNIT);
 glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
 }
 drawQuad();
 }

 glUseProgram(ffty-program);
 glUniform1i(glGetUniformLocation(ffty-program, nLayers), choppy ? 5 :
 3);
 for (int i = PASSES; i  2 * PASSES; ++i) {
 glUniform1f(glGetUniformLocation(ffty-program, pass), float(i -
 PASSES + 0.5) / PASSES);
 if (i%2 == 0) {
 glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
 FFT_A_UNIT);
 glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
 } else {
 glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
 FFT_B_UNIT);
 glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
 }
 drawQuad();
 }

 glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

 = as you can see, a single FBO is used and the glDrawBuffer is called
 multiple times to toggle the target on the fly.

 The good news in this story is, I don't if you following my previous
 discussion with Sergey, (thread called Changing DrawBuffer for FBO) but it
 turns out the DrawBuffer stateAttribute I created is working just as
 expected in fact 

 So this ping pong implementation is basically working, but the problem I
 noticed comes from another point: the GLSL program used in the process.

 in the openGL code, the two texture2D arrays are attached to the FBO this
 way:

 glGenFramebuffersEXT(1, fftFbo2);
 glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fftFbo2);
 glReadBuffer(GL_COLOR_ATTACHMENT0_EXT);
 glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
 glFramebufferTextureEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,
 fftaTex, 0);
 glFramebufferTextureEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT1_EXT,
 fftbTex, 0);
 glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

 So, in my OSG implementation I turned that into (this is lua code):


 cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER0,result.ffts[1],0,0,true);


 cam:attach(osg.Camera.BufferComponent.COLOR_BUFFER1,result.ffts[0],0,0,true);

 But, now I think the problem comes from how those bindings are
 interpretated in both case:

   - the GLSL program performing

Re: [osg-users] Changing DrawBuffer for FBO

[Emmanuel Roche]

 and numPasses as
arguments)
fftx_passes:addChild(pass)

Thanks for your help guys!

cheers,
Manu.



2011/9/26 Emmanuel Roche roche.emman...@gmail.com

 Hi Sergey and everyone,

 I've been trying to setup a ping pong rendering with multiple cameras as
 previously mentioned... unfortunately this is not really working :-) : I
 guess I just can't render to one texture / use it as input / re-render again
 as easily as I expected.

 So now I have to switch to another option. I have some experience with
 osgPPU already, but I only used it in a regular wait (with Texture2D,
 rendering  a couple of gauss passes in X and Y...) : here the situation is
 much more tricky: I have to ping pong between texture2DArrays with Texture3D
 samplers and with much more passes : it might be possible with osgPPU, but I
 have the feeling I could spend a lot of time to get everything properly set
 up first... (I already spent a log of time trying to setup something with
 regular OSG cameras, so I would like to use that work if possible).

 So my idea is:  how about if I create a simple new StateAttribute class to
 call glDrawBuffer() ?? This stateAttribute would be as simple as the
 AlphaFunc StateAttribute for instance...: Would this make sense ? Or do you
 think I would be waiting a few additional hours here ? :-)

 Then the plan would be to build a graph such as:

   Camera (PRE-Render, attachment color0=first Texture2DArray, attachment
 color1=second texture2D Array, rendering shader program)
  | -- Screen Quad 0 with stateset ( stateattribute
 glDrawBuffer=GL_COLOR_ATTACHMENT1_EXT)
  | -- Screen Quad 1 with stateset ( stateattribute
 glDrawBuffer=GL_COLOR_ATTACHMENT0_EXT)
  | -- Screen Quad 2 with stateset ( stateattribute
 glDrawBuffer=GL_COLOR_ATTACHMENT1_EXT)
  | -- etc

 ... I might have the ensure the quads are rendered in that exact order, but
 I think a simple bin number settings should be enough to do that no ?


 If this is really working as expected, this would also mean I would not
 have to use more that one camera to perform all the needed passes... So I
 really think this is the next option I should try, except is someone already
 knows why this won't work :-)


 Cheers,
 Manu.





 2011/9/23 Sergey Polischuk pol...@yandex.ru

 Hi, Manu

 Cant comment on performance gain with pure gl, but you can write small
 test to see possible gain. Osg dont share fbos with cameras and dont keep
 track of vbo's binded so most of gain would be from reducing number of
 glBindFramebuffer...(..) calls and geometry setup (vertex\index\texcoord
 arrays\pointers).*
 *

 It is possible to create whatever objects you need inside
 renderImplementation, also you need to info osg::State about all gl state
 that osg::State keep track of, that you change with opengl calls (look at
 osg::State::haveApplied...(...) ), or use osg::State functionality instead
 of opengl calls (look at applyMode(..)/applyAttribute(..)), though not all
 gl calls can be done through osg::State interface. Instead you can use pure
 gl and call osg::State::dirtyAll...() afterwards. Dont forget to restore fbo
 used by osg if you change fbo binding inside drawImplementation(). Also
 there could be issues with multiple opengl contexts handling if you use
 multiple screens, so you may need to track current contextID and
 create\store opengl handles for each contextID used, and pick right handles
 for current contextID.

 Also with pure gl approach you can get rid of fbo and drawBuffers switch
 if you can use NV_texture_barrier extension - you can create texture array
 with two textures, reading from one layer and writing to another based on
 uniform value or instanceID if you use instanced drawing for sqreen aligned
 quads.

 Cheers,
 Sergey.
 23.09.2011, 15:50, Emmanuel Roche roche.emman...@gmail.com:

 Thanks Sergey,

 Right now I'm using multiple cameras rendered one after another... but I
 have the feeling the performances are not too good (with 17 pre render
 cameras...). Do you think I'm right to assume I could  really improve the
 performances by using pure GL code instead  and create only one FBO ?

 as a matter of fact, my second idea would be to encapsulate all this using
 approximately the code snippet of the previous mail in a special drawable.
 But i'm wondering if this will not lead to other issues (I'm not that
 familiar with pure GL code and creating special drawables):  is it possible
 to allocate by FBO  and everything I could need from within the
 renderImplementation of a drawable ? Could somebody predict a big issue
 doing this ?

 Cheers,
 Manu.


 2011/9/23 Sergey Polischuk pol...@yandex.ru

 Hi, Manu

 There are no convenient support for renderbuffer ping-ponging. You can
 either use pure gl, graph with lots of cameras setup with correct render
 order and output textures, or osgppu graph with chain of units

 Cheers,
 Sergey.
 22.09.2011, 16:28, Emmanuel Roche roche.emman...@gmail.com:


 Hi everyone,

 I have a question regarding

Re: [osg-users] Changing DrawBuffer for FBO

[Emmanuel Roche]

Hi Sergey and everyone,

I've been trying to setup a ping pong rendering with multiple cameras as
previously mentioned... unfortunately this is not really working :-) : I
guess I just can't render to one texture / use it as input / re-render again
as easily as I expected.

So now I have to switch to another option. I have some experience with
osgPPU already, but I only used it in a regular wait (with Texture2D,
rendering  a couple of gauss passes in X and Y...) : here the situation is
much more tricky: I have to ping pong between texture2DArrays with Texture3D
samplers and with much more passes : it might be possible with osgPPU, but I
have the feeling I could spend a lot of time to get everything properly set
up first... (I already spent a log of time trying to setup something with
regular OSG cameras, so I would like to use that work if possible).

So my idea is:  how about if I create a simple new StateAttribute class to
call glDrawBuffer() ?? This stateAttribute would be as simple as the
AlphaFunc StateAttribute for instance...: Would this make sense ? Or do you
think I would be waiting a few additional hours here ? :-)

Then the plan would be to build a graph such as:

  Camera (PRE-Render, attachment color0=first Texture2DArray, attachment
color1=second texture2D Array, rendering shader program)
 | -- Screen Quad 0 with stateset ( stateattribute
glDrawBuffer=GL_COLOR_ATTACHMENT1_EXT)
 | -- Screen Quad 1 with stateset ( stateattribute
glDrawBuffer=GL_COLOR_ATTACHMENT0_EXT)
 | -- Screen Quad 2 with stateset ( stateattribute
glDrawBuffer=GL_COLOR_ATTACHMENT1_EXT)
 | -- etc

... I might have the ensure the quads are rendered in that exact order, but
I think a simple bin number settings should be enough to do that no ?


If this is really working as expected, this would also mean I would not have
to use more that one camera to perform all the needed passes... So I really
think this is the next option I should try, except is someone already knows
why this won't work :-)

Cheers,
Manu.





2011/9/23 Sergey Polischuk pol...@yandex.ru

 Hi, Manu

 Cant comment on performance gain with pure gl, but you can write small test
 to see possible gain. Osg dont share fbos with cameras and dont keep track
 of vbo's binded so most of gain would be from reducing number of
 glBindFramebuffer...(..) calls and geometry setup (vertex\index\texcoord
 arrays\pointers).*
 *

 It is possible to create whatever objects you need inside
 renderImplementation, also you need to info osg::State about all gl state
 that osg::State keep track of, that you change with opengl calls (look at
 osg::State::haveApplied...(...) ), or use osg::State functionality instead
 of opengl calls (look at applyMode(..)/applyAttribute(..)), though not all
 gl calls can be done through osg::State interface. Instead you can use pure
 gl and call osg::State::dirtyAll...() afterwards. Dont forget to restore fbo
 used by osg if you change fbo binding inside drawImplementation(). Also
 there could be issues with multiple opengl contexts handling if you use
 multiple screens, so you may need to track current contextID and
 create\store opengl handles for each contextID used, and pick right handles
 for current contextID.

 Also with pure gl approach you can get rid of fbo and drawBuffers switch if
 you can use NV_texture_barrier extension - you can create texture array with
 two textures, reading from one layer and writing to another based on uniform
 value or instanceID if you use instanced drawing for sqreen aligned quads.

 Cheers,
 Sergey.
 23.09.2011, 15:50, Emmanuel Roche roche.emman...@gmail.com:

 Thanks Sergey,

 Right now I'm using multiple cameras rendered one after another... but I
 have the feeling the performances are not too good (with 17 pre render
 cameras...). Do you think I'm right to assume I could  really improve the
 performances by using pure GL code instead  and create only one FBO ?

 as a matter of fact, my second idea would be to encapsulate all this using
 approximately the code snippet of the previous mail in a special drawable.
 But i'm wondering if this will not lead to other issues (I'm not that
 familiar with pure GL code and creating special drawables):  is it possible
 to allocate by FBO  and everything I could need from within the
 renderImplementation of a drawable ? Could somebody predict a big issue
 doing this ?

 Cheers,
 Manu.


 2011/9/23 Sergey Polischuk pol...@yandex.ru

 Hi, Manu

 There are no convenient support for renderbuffer ping-ponging. You can
 either use pure gl, graph with lots of cameras setup with correct render
 order and output textures, or osgppu graph with chain of units

 Cheers,
 Sergey.
 22.09.2011, 16:28, Emmanuel Roche roche.emman...@gmail.com:


 Hi everyone,

 I have a question regarding FBO usage and Draw/Read buffer changes:

 - I have one pre render camera using FBO and with 2 textures attached (to
 COLOR_BUFFER0 and COLOR_BUFFER1)
 - Under that camera I would like to add

Re: [osg-users] Changing DrawBuffer for FBO

[Emmanuel Roche]

Thanks Sergey,

Right now I'm using multiple cameras rendered one after another... but I
have the feeling the performances are not too good (with 17 pre render
cameras...). Do you think I'm right to assume I could  really improve the
performances by using pure GL code instead  and create only one FBO ?

as a matter of fact, my second idea would be to encapsulate all this using
approximately the code snippet of the previous mail in a special drawable.
But i'm wondering if this will not lead to other issues (I'm not that
familiar with pure GL code and creating special drawables):  is it possible
to allocate by FBO  and everything I could need from within the
renderImplementation of a drawable ? Could somebody predict a big issue
doing this ?

Cheers,
Manu.


2011/9/23 Sergey Polischuk pol...@yandex.ru

 Hi, Manu

 There are no convenient support for renderbuffer ping-ponging. You can
 either use pure gl, graph with lots of cameras setup with correct render
 order and output textures, or osgppu graph with chain of units

 Cheers,
 Sergey.
 22.09.2011, 16:28, Emmanuel Roche roche.emman...@gmail.com:

 Hi everyone,

 I have a question regarding FBO usage and Draw/Read buffer changes:

 - I have one pre render camera using FBO and with 2 textures attached (to
 COLOR_BUFFER0 and COLOR_BUFFER1)
 - Under that camera I would like to add multiple screen aligned quads that
 would use the attached textures this way: (call them tex0 and tex1):
   - quad0 would using the tex0 as input and draw on tex1
   - quad1 would then use tex1 as input and draw on tex0
   - quad2 would using the tex0 as input and draw on tex1
   - quad3 would then use tex1 as input and draw on tex0
   - etc.

 This is possible in pure OpenGL using something like that:

* glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fftFbo2);
 glUseProgram(fftx-program);
 glUniform1i(glGetUniformLocation(fftx-program, nLayers), choppy ? 5
 : 3);
 for (int i = 0; i  PASSES; ++i) {
 glUniform1f(glGetUniformLocation(fftx-program, pass), float(i +
 0.5) / PASSES);
 if (i%2 == 0) {
 glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
 FFT_A_UNIT);
 glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
 } else {
 glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
 FFT_B_UNIT);
 glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
 }
 drawQuad();
 }
 glUseProgram(ffty-program);
 glUniform1i(glGetUniformLocation(ffty-program, nLayers), choppy ? 5
 : 3);
 for (int i = PASSES; i  2 * PASSES; ++i) {
 glUniform1f(glGetUniformLocation(ffty-program, pass), float(i -
 PASSES + 0.5) / PASSES);
 if (i%2 == 0) {
 glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
 FFT_A_UNIT);
 glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
 } else {
 glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
 FFT_B_UNIT);
 glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
 }
 drawQuad();
 }

 glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);*

 .. but I can't figure out how to do something equivalent to the internal
 calls to glDrawBuffer in the previous snippet when I have a single camera.
 (as calling setDrawBuffer() is done once and for all before rendering
 anything... Any idea what could be worth trying here ?

 Cheers,
 Manu.

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


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


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

[osg-users] Changing DrawBuffer for FBO

[Emmanuel Roche]

Hi everyone,

I have a question regarding FBO usage and Draw/Read buffer changes:

- I have one pre render camera using FBO and with 2 textures attached (to
COLOR_BUFFER0 and COLOR_BUFFER1)
- Under that camera I would like to add multiple screen aligned quads that
would use the attached textures this way: (call them tex0 and tex1):
  - quad0 would using the tex0 as input and draw on tex1
  - quad1 would then use tex1 as input and draw on tex0
  - quad2 would using the tex0 as input and draw on tex1
  - quad3 would then use tex1 as input and draw on tex0
  - etc.

This is possible in pure OpenGL using something like that:

   * glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fftFbo2);
glUseProgram(fftx-program);
glUniform1i(glGetUniformLocation(fftx-program, nLayers), choppy ? 5 :
3);
for (int i = 0; i  PASSES; ++i) {
glUniform1f(glGetUniformLocation(fftx-program, pass), float(i +
0.5) / PASSES);
if (i%2 == 0) {
glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
FFT_A_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
} else {
glUniform1i(glGetUniformLocation(fftx-program, imgSampler),
FFT_B_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
}
drawQuad();
}
glUseProgram(ffty-program);
glUniform1i(glGetUniformLocation(ffty-program, nLayers), choppy ? 5 :
3);
for (int i = PASSES; i  2 * PASSES; ++i) {
glUniform1f(glGetUniformLocation(ffty-program, pass), float(i -
PASSES + 0.5) / PASSES);
if (i%2 == 0) {
glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
FFT_A_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT1_EXT);
} else {
glUniform1i(glGetUniformLocation(ffty-program, imgSampler),
FFT_B_UNIT);
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
}
drawQuad();
}

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);*

.. but I can't figure out how to do something equivalent to the internal
calls to glDrawBuffer in the previous snippet when I have a single camera.
(as calling setDrawBuffer() is done once and for all before rendering
anything... Any idea what could be worth trying here ?

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

[osg-users] Changing eye position in cull traversal

[Emmanuel Roche]

Hi everyone,

I've have a specific question for which I could use some help/advises:

- I'm quite up-to-date with OSG 3.0.0 and osgEarth current git version
- I'm build an app where I use the osgEarth library to display the earth
model.
- When I setup a camera on that model, I use a camera with a very very small
field of view (about 0.5 degrees in both horizontal and vertical
directions), and my camera is actually far away from the earth model I'm
looking at.

- as a result of this, only low resolution tiles are loaded (because the
camera distance to the tiles is used to diced what to load or not).

- What I want to do is : to get high resolution tiles displayed around the
ground location the camera is pointing at even if it is physically far
away. then, because (or thanks to?) the small field of view, I would still
see the local details on the high res tile textures.

So, any advise how to achieve this ?

- so far I have tried the following:
  1. Setup this famous camera just as described before,
  2. Add a slave camera, using the earth as child too, but this time,
positioned very close to the first camera target point on earth (and looking
down that point from the local zenith).

Both cameras share the same databasepager (I think) and high res tiles are
indeed properly loaded because of the second camera cull traversal. The
problem is: I was expecting the loaded tiles to be shared by both cameras,
yet that is not the case: I still only get the low res tiles displayed by
the far away camera. Is there a way to share the tiles as I was
expecting ?


- The other main idea I have then would be to find a way to trick the cull
traversal of the far away camera so that, when traversing pagedLODs the
reported distance to the tile would be as if the camera was actually much
closer to its target point on the ground. Would that be a good idea ? Any
hint on how to proceed then ??


- of course, option 3 would be to actually move the camera to that close
location and change the field of view to a bigger value to try to
approximate the previous small field of view coverage. But the point is,
this camera is meant for a simulator system, and the generated view should
not approximate the actual view, it should really be the same, so
computing a new field of view would actually be impossible (or too complex
to be worth at least).


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

Re: [osg-users] Changing eye position in cull traversal

[Emmanuel Roche]

Thanks for those inputs Sergey, but actually I tried to follow the way
described in another OSG post: to create a custom CullVisitor and override
the getDistanceFromViewPoint() method:

And this seems to work great !!

Just in case someone would need some hints on this:

1. To override the CullVisitor, I do soemthing like:

   camera-getRenderer()-getSceneView(id)-setCullVisitor(new
MyOwnCullVisitor)  (do this for id=0 and 1)

2. In my own cull visitor I then have something like:

virtual float getDistanceToViewPoint(const osg::Vec3 pos, bool
withLODScale) const
{
if(_lastTraversalNumber!=_traversalNumber) {
// Retrieve the beamTarget position X and use it as -Z position
in the view frame:
osg::PositionAttitudeTransform* beamTarget =
_data-getRefosg::PositionAttitudeTransform(beamTarget);
CHECK_POINTER(beamTarget,Invalid beamTarget PAT in callback.);

double offset = beamTarget-getPosition().x();
referencePoint = osg::Vec3(0.0,0.0,-offset);
_lastTraversalNumber = _traversalNumber;
}

osg::Matrixd mat;
if(!_modelviewStack.empty()) {
const osg::RefMatrix* mview = _modelviewStack.back().get();
mat.invert(*mview);
}

osg::Vec3f localViewPoint = referencePoint*mat;

//wxLogMessage(I'm in my special getDistanceToViewPoint!);
if (withLODScale) return
(pos-localViewPoint).length()*getLODScale();
else return (pos-localViewPoint).length();
}

And with this I get the expected results without significant performance
lost.

So all good for me.

Cheers,
Manu.

2011/8/10 Sergey Polischuk pol...@yandex.ru

 Hi,

 osg::LOD have option to use object's size on screen (in pixels?) instead of
 distance to camera to determine which lod to use, you can try these setting.

 Cheers,
 Sergey.
 10.08.2011, 16:03, Emmanuel Roche roche.emman...@gmail.com:

 Hi everyone,

 I've have a specific question for which I could use some help/advises:

 - I'm quite up-to-date with OSG 3.0.0 and osgEarth current git version
 - I'm build an app where I use the osgEarth library to display the earth
 model.
 - When I setup a camera on that model, I use a camera with a very very
 small field of view (about 0.5 degrees in both horizontal and vertical
 directions), and my camera is actually far away from the earth model I'm
 looking at.

 - as a result of this, only low resolution tiles are loaded (because the
 camera distance to the tiles is used to diced what to load or not).

 - What I want to do is : to get high resolution tiles displayed around the
 ground location the camera is pointing at even if it is physically far
 away. then, because (or thanks to?) the small field of view, I would still
 see the local details on the high res tile textures.

 So, any advise how to achieve this ?

 - so far I have tried the following:
   1. Setup this famous camera just as described before,
   2. Add a slave camera, using the earth as child too, but this time,
 positioned very close to the first camera target point on earth (and looking
 down that point from the local zenith).

 Both cameras share the same databasepager (I think) and high res tiles are
 indeed properly loaded because of the second camera cull traversal. The
 problem is: I was expecting the loaded tiles to be shared by both cameras,
 yet that is not the case: I still only get the low res tiles displayed by
 the far away camera. Is there a way to share the tiles as I was
 expecting ?


 - The other main idea I have then would be to find a way to trick the
 cull traversal of the far away camera so that, when traversing pagedLODs the
 reported distance to the tile would be as if the camera was actually much
 closer to its target point on the ground. Would that be a good idea ? Any
 hint on how to proceed then ??


 - of course, option 3 would be to actually move the camera to that close
 location and change the field of view to a bigger value to try to
 approximate the previous small field of view coverage. But the point is,
 this camera is meant for a simulator system, and the generated view should
 not approximate the actual view, it should really be the same, so
 computing a new field of view would actually be impossible (or too complex
 to be worth at least).


 cheers,
 Manu.

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


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


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

Re: [osg-users] Composite viewer Threading model

[Emmanuel Roche]

well well well,

I'm wondering if this could be related to one of the previous thread on this
list called: OSG seems to have a problem scaling to multiple windows on
multiple graphics cards :-(


I'm currently diving into the GraphicsContext operations code, but I doubt I
can find any clear evidence that: this is just the way it is supposed to
work or not so please, someone, correct me if I'm wrong here:

= I assume that with a CompositeViewer, if I display multiple windows with
one graphics context (= one osg::GraphicsWindow) per window, and one camera
per windows, then using a threading model  CullDrawThreadPerContext should
result in the Cull/draw phase to run concurrently and this should be visible
when displaying the stats...

... or maybe it just doesn't work like that ? :-) Maybe the draw cycles must
be sequential (just as the GPU cycles ?) but then what is the meaning for
those threading models ? any clear description anywhere ?

cheers,
Manu.



2011/8/5 Emmanuel Roche roche.emman...@gmail.com

 Hi everyone,

 I'm currently trying to experiment with OSG multi-threading support in an
 application:

 I have the following setup:

 - One app with 2 or more OSG rendering windows displaying the same scene (+
 different overlays, so nto really the same osg::Scene actually)
 - I can choose to either use a shared openGL context or not for those 2 (or
 more) windows.
 - I run the app on a 2 screens computer with 1x Geforce GTX 480
 - The rendering is done using a CompositeViewer derived class with very
 minor changes.

 The problem/question is:

 = I tried all the possible threading models, displaying the osg stats each
 time: and there is just no change at all in the resulting
 performances/reported stats:

 = All the cull/draw cycles still seem to be performed sequentially.

 So I'm wondering : what could I be missing here ??

 Even when I don't use a shared context for instance: I would have expected
 a setting such as DrawThreadPerContext to mean per OpenGL context Am I
 wrong on that ??

 Any idea what I should check first to ensure everything is OK for
 multithreading to occur ??

 Please see the attached image for the current stats I get.

 thanks for your advises guys ! :-)

 Cheers!
 Manu.


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

[osg-users] Perform all traversals except draw...

[Emmanuel Roche]

Hi Everyone,

I think I have a very specific issue here, and I could use some help to fix
this:

- I'm trying to compute interections with an osgEarth model using the
osgSim::LineOfSight helper class.
- The problem is, this helper class seems to just be freezing when loading
the earth tiles in the readcallback (at least, this is just taking too
long): I guess this is because all the needed tiles are loaded synchronously
before one can perform the first intersection test.
-So I was wondering if there was a way to acheive a more real time
behavior using a regular intersection situation: when you have a osgEarth
model loaded and rendered then the camera is used to decide which tiles to
load and the database pager will load them smoothly. And then, a simple
intersectionVisitor can give you the current intersection result desired
without blocking the rendering loop for ages.

= But at the same time, I just don't want to render this osgEarth model...
it should just be an hidden model used for intersection tests.

So I was wondering: is there a way, to easily setup a complete traversal
loop (event,update, and cull traversal) but prevent the drawing traversal of
a scene ? If this possible the cull traversal with appropriate camera
location would trigger new requests for tiles, the update traversal would
allow the database pager to load those tiles, and I could still save the
ressources and hardware compatibility needed for the drawing traversal...

Any idea if this is possible or not or how to proceed ??

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

Re: [osg-users] Perform all traversals except draw...

[Emmanuel Roche]

HI Robert,

2011/6/15 Robert Osfield robert.osfi...@gmail.com

 Hi Emmanuel,

 You can certain use the OSG and paging without rendering, but the
 stall in the intersection traversal you are getting has nothing to do
 with rendering, it's simply the the LineOfSight algorithm is set up to
 drill down to the highest level of detail.


I understand this as nothing to do with rendering, but it has to do with
loading all tiles in a row instead of loading them only when there is some
time available between two frames as the databasepager does. Since the
intersection is done for me in the rendering loop this is blocking
everything for too long.



 The LineOfSight class by default assigns a
 osgSim::DatabaseCacheReadCallback the IntersectionVisitor that it uses
 to intersect the scene graph, it's this ReadCallback that is reading
 the external tile and causing the slow down.  It does cache the
 requests so on subsequent intersection tests you'll get better speed,
 but for the first intersection where it has to load all the tiles
 required by the intersection it will be slow, especially if there are
 many levels of detail to pull in.

 You can reset the LineOfSight::DatabaseCacheReadCallback off by doing
 setDatabaseCacheReadCallback(0), but this will disable it's ability to
 pull in external tiles so that it will be limited by what data is
 already loaded into memory.

 What you'd want in your case I can't answer - do you need the highest
 level of detail to do the intersection?  If so you'll need to see if
 you can pre-populate the DatabaseCacheReadCallback with the tiles you
 are expecting to need.   If not then just reset th callback to 0, or
 just use your own IntersectionVisitor traversal.


In fact, I need the highest possible resolution. But I would not mind
getting this final accurate result after multiple cycles (as would be the
case if I let the database pager load the tiles progressively. So I guess,
just putting a camera very close to the ground on the intersection ray would
be a good option.

= Now, could I really just setup a Cullvisitor manually, traverse the scene
with this visitor, and then perform a updateSceneGraph() call on a regular
basis with the databasepager, and except the tiles to be progressively
loaded this way ?

Manu.





 Robert.

 On Wed, Jun 15, 2011 at 9:16 AM, Emmanuel Roche
 roche.emman...@gmail.com wrote:
  Hi Everyone,
 
  I think I have a very specific issue here, and I could use some help to
 fix
  this:
 
  - I'm trying to compute interections with an osgEarth model using the
  osgSim::LineOfSight helper class.
  - The problem is, this helper class seems to just be freezing when
 loading
  the earth tiles in the readcallback (at least, this is just taking too
  long): I guess this is because all the needed tiles are loaded
 synchronously
  before one can perform the first intersection test.
  -So I was wondering if there was a way to acheive a more real time
  behavior using a regular intersection situation: when you have a osgEarth
  model loaded and rendered then the camera is used to decide which tiles
 to
  load and the database pager will load them smoothly. And then, a simple
  intersectionVisitor can give you the current intersection result desired
  without blocking the rendering loop for ages.
 
  = But at the same time, I just don't want to render this osgEarth
 model...
  it should just be an hidden model used for intersection tests.
 
  So I was wondering: is there a way, to easily setup a complete traversal
  loop (event,update, and cull traversal) but prevent the drawing traversal
 of
  a scene ? If this possible the cull traversal with appropriate camera
  location would trigger new requests for tiles, the update traversal would
  allow the database pager to load those tiles, and I could still save the
  ressources and hardware compatibility needed for the drawing traversal...
 
  Any idea if this is possible or not or how to proceed ??
 
  Cheers,
  Manu.
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] Perform all traversals except draw...

[Emmanuel Roche]

Hi Robert,

Sure, I can use a dedicated scene graph, but the other key aspect here is I
really want to avoid drawing that scene anywhere [when I say this
intersection test is in my rendering loop it's because I'm actually
rendering *another scene*, but not this one]. It that currently possible out
of the box ? Or is there a simple way to just prevent the camera drawing
traversal ?

= What I have in mind is: as long as I don't try to render anything on
screen I won't have to take into account any kind of hardware compatibilty
issue (since I won't have to rely on any kind of OpenGL call and will rather
manipulate only an in memory scene graph. This would ensure the highest
possible compatibility with various hardware configurations with no cost
since I'm just not interested in actually seeing this 3D earth model.

Cheers,
Manu.



2011/6/15 Robert Osfield robert.osfi...@gmail.com

 Hi Manu,

 On Wed, Jun 15, 2011 at 9:49 AM, Emmanuel Roche
 roche.emman...@gmail.com wrote:
  I understand this as nothing to do with rendering, but it has to do with
  loading all tiles in a row instead of loading them only when there is
 some
  time available between two frames as the databasepager does. Since the
  intersection is done for me in the rendering loop this is blocking
  everything for too long.

 Doing intersections in the rendering loop should only be done with no
 external file excees - the DatabasePager loads in a background thread
 to prevent any stalls.  For you case you either need to stop using
 LineOfSight with the it's file cache callback installed, or move the
 intersections tests entirely out of the rendering loop and do it a
 background thread.
  In fact, I need the highest possible resolution. But I would not mind
  getting this final accurate result after multiple cycles (as would be the
  case if I let the database pager load the tiles progressively. So I
 guess,
  just putting a camera very close to the ground on the intersection ray
 would
  be a good option.

 Hacking around with the camera won't address the basic problem - if you
 want the highest level of detail for interesection you have to load them,
 and
 loading them takes time - this simply doesn't mix with a real-time
 rendering
 loop.  You can't be clever and avoid this, it's an intractable problem
 that
 can only be resolved by moving the intersections out of the rendering loop
 into it's own dedicated intersection thread.

  = Now, could I really just setup a Cullvisitor manually, traverse the
 scene
  with this visitor, and then perform a updateSceneGraph() call on a
 regular
  basis with the databasepager, and except the tiles to be progressively
  loaded this way ?

 You can't solve the problem this way.

 You *have* to move the interesection testing outside of the main
 rendering thread.  Consdier using an enterily dedicated scene graph
 for just this purpose, running it's own threads.

 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] Render to 3D image...

[Emmanuel Roche]

Hi guys !

The solution I suggested to myself, actually works !

So, if someone needs to render to a 3D image one day, one available option
is to attach slices of the target images as mentioned below.

To get those slices I used some code like (where z is the slice to render
to)

*osg::Image* SceneTools::get3DImageSlice(osg::Image * src, int z)
{
// Create a new image:
osg::Image* img = new osg::Image();
int ww = src-s();
int hh = src-t();
unsigned char* data = src-data(0,0,z);
img-setImage (ww, hh, 1, src-getInternalTextureFormat(),
src-getPixelFormat(), src-getDataType(), data, osg::Image::NO_DELETE,
src-getPacking());

return img;
}*


Now I have another issue related to those 3D texture/images usage:

I'm trying to copy a 3D Texture/image into another 3D texture/image with
GLSL. And for a reason I cannot explain this is just not working... :-(

I have the following setup:


   -   created a target 3D image to hold the copy result.
   - create multiple cameras, with multiple color attachment (one camera for
   slice of the target image), each camera has the proper slice uniform
   interger.
   - Assigned the source 3D image as a SAMPLER_3D uniform on a parent group
   for all the cameras.
   - Applied a shader on the parent group for all the cameras to just copy
   the source image slice into the target image slice...


== Is there something I could be missing here ?

Just let me know if you need some code to have a better idea of what I'm
doing (but almost everything is written in Lua).


== One very strange thing about this is: if I use a 2D source image instead
of a 3D source image, everything works just fine ! [I can for instance use
the slice index to fade the input 2D image, and thus get a valid resulting
3D image with different slices].


Any help would really be appreciated here :-)

Cheers!
Manu.


2010/8/4 Emmanuel Roche roche.emman...@gmail.com

 Concerning this problem, I'm wondering if I could use the following
 solution:

  1. Create a master 3D image, and allocate it;
  2. Since attaching 2D images to a camera would not require any face
 argument, I could create sub images, one per z slice of the master camera,
 and use setImage with an offset data pointer in the master image data...
  3. Then assign those sub images to each camera I'm using to render the
 complete 3D image.

 Would this work as expected ?? Or would attaching an image to a camera
 actually somehow reallocate the image data ??? (and thus we would not be
 able to write the slice data into the master image data).

 I hope, those explanations are clear enough :-)

 Manu.


 2010/8/4 Emmanuel Roche roche.emman...@gmail.com

 Hi everyone,

 I'm currently trying to generate some 3D images in an OSG based app.

 I've read the previous discussions on the OSG forums concerning the 3D
 texture rendering, but this doesn't help in my situation. What I really need
 is *3D image* rendering not *3D texture* rendering.

 More explanations:

  * One can attach an osg::Image or an osg::Texture to the color buffer of
 a given camera. But one can only specify the face argument for textures:

 *void attach http://a00098.html#a496ed6d69392c1fdb8548085900a1a87 (
 BufferComponent http://a00098.html#af4d8ae808500a2f5bc9fe7b605386e74buffer,
 osg::Texture http://a00946.html *texture, unsigned int level=0,
 unsigned int face=0, bool mipMapGeneration=false, unsigned int
 multisampleSamples=0, unsigned int multisampleColorSamples=0)

 void attach http://a00098.html#a4124951a5032de595c5d28d0cc5e87a3 (
 BufferComponent http://a00098.html#af4d8ae808500a2f5bc9fe7b605386e74buffer,
 osg::Image http://a00389.html *image, unsigned int
 multisampleSamples=0, unsigned int multisampleColorSamples=0)

 ** So,
   - if I attach a 3D image directly to the camera, the depth of the image
 is not taken into account, and all the image slices will contain the same
 result.
   - if I attach a Texture3D object, whether I assign it an underlying
 image doesn't matter: the content of the texture cannot be retrieved with
 the assigned image...

 Is there something I'm missing here ? Did someone already successfully
 render to a 3D texture *AND* wrote that texture to a file for instance ??

 Or is there a way to retrieve the content of a 3D texture into a 3D image
 (I guess retrieving the texture data from the graphic card somehow ?) [I'm
 not very good at pure OpenGL considerations, thus the question :-) ].

 Cheers! Thanks for your help guys!

 Manu.



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

Re: [osg-users] Render to 3D image...

[Emmanuel Roche]

Hey, thanks for the info Frederic!


Actually, the atmospheric scattering effect you're pointing me at is what
I've been trying to integrate into OSG for a few days now and the reason why
I ask those questions :-) So I already know the content of the main.cpp and
copyInscatter1 program quite well. But the problem now is that I'm still
relying on OSG 2.9.6 (snif...) so I haven't seen this
FACE_CONTROLLED_BY_GEOMETRY_SHADER parameter, and thus I ended up removing
the geometry shaders from the atmosphere precomputation process and using
multiple cameras...

At least now I know there is a second path I could investigate if I really
cannot go further with my current implementation... (but there is still some
hope left ! :-) )


Also, if this face parameter if not available for Image attachment, I
don't think this would fit into my design: from what I understand the pure
openGL implementation from Eric Bruneton will actually precompute the
textures in a given context and then use them directly in that context (so
no image generated in the process). For my part, I would like to perform the
precompute stage only once, save the resulting images, and use them in
multiple GL contexts...[and attaching textures will not allow an easy access
to the image data as far as I know...]

Cheers!
Manu.


2010/8/6 Frederic Bouvier fredlis...@free.fr


 - Emmanuel Roche a écrit :
  Just let me know if you need some code to have a better idea of what
  I'm doing (but almost everything is written in Lua).

 If you have OSG 2.9.8, there is a new possible value for the face parameter
 : osg::Camera::FACE_CONTROLLED_BY_GEOMETRY_SHADER

 To render to a 3d texture in one run, with only one camera, you can :

 * draw a quad with draw instancing, the number of instance being the number
 of slice,
 * in the vertex shader, copy the gl_InstanceID uniform to a varying
 * in the geometry shader, copy the varying holding the instance id into
 gl_Layer that control the slice
 * do what you want in the fragment shader.

 If you get
 http://www-evasion.imag.fr/Membres/Eric.Bruneton/PrecomputedAtmosphericScattering2.zip

 Look in Main.cpp and in copyInscatter1.glsl, there is a variant of this,
 without instancing, drawing each quad separately.

 Regards,
 -Fred
 ___
 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] Render to 3D image...

[Emmanuel Roche]

OK, forget about this issue of non-used 3D textures guys ! This was due to a
stupid mistake:

I was assigning a sampler with a not yet rendered image!

Manu.


2010/8/6 Emmanuel Roche roche.emman...@gmail.com

 Hi guys !

 The solution I suggested to myself, actually works !

 So, if someone needs to render to a 3D image one day, one available option
 is to attach slices of the target images as mentioned below.

 To get those slices I used some code like (where z is the slice to render
 to)

 *osg::Image* SceneTools::get3DImageSlice(osg::Image * src, int z)
 {
 // Create a new image:
 osg::Image* img = new osg::Image();
 int ww = src-s();
 int hh = src-t();
 unsigned char* data = src-data(0,0,z);
 img-setImage (ww, hh, 1, src-getInternalTextureFormat(),
 src-getPixelFormat(), src-getDataType(), data, osg::Image::NO_DELETE,
 src-getPacking());

 return img;
 }*


 Now I have another issue related to those 3D texture/images usage:

 I'm trying to copy a 3D Texture/image into another 3D texture/image with
 GLSL. And for a reason I cannot explain this is just not working... :-(

 I have the following setup:


-   created a target 3D image to hold the copy result.
- create multiple cameras, with multiple color attachment (one camera
for slice of the target image), each camera has the proper slice uniform
interger.
- Assigned the source 3D image as a SAMPLER_3D uniform on a parent
group for all the cameras.
- Applied a shader on the parent group for all the cameras to just copy
the source image slice into the target image slice...


 == Is there something I could be missing here ?

 Just let me know if you need some code to have a better idea of what I'm
 doing (but almost everything is written in Lua).


 == One very strange thing about this is: if I use a 2D source image
 instead of a 3D source image, everything works just fine ! [I can for
 instance use the slice index to fade the input 2D image, and thus get a
 valid resulting 3D image with different slices].


 Any help would really be appreciated here :-)

 Cheers!

 Manu.


 2010/8/4 Emmanuel Roche roche.emman...@gmail.com

 Concerning this problem, I'm wondering if I could use the following
 solution:

  1. Create a master 3D image, and allocate it;
  2. Since attaching 2D images to a camera would not require any face
 argument, I could create sub images, one per z slice of the master camera,
 and use setImage with an offset data pointer in the master image data...
  3. Then assign those sub images to each camera I'm using to render the
 complete 3D image.

 Would this work as expected ?? Or would attaching an image to a camera
 actually somehow reallocate the image data ??? (and thus we would not be
 able to write the slice data into the master image data).

 I hope, those explanations are clear enough :-)

 Manu.


 2010/8/4 Emmanuel Roche roche.emman...@gmail.com

 Hi everyone,

 I'm currently trying to generate some 3D images in an OSG based app.

 I've read the previous discussions on the OSG forums concerning the 3D
 texture rendering, but this doesn't help in my situation. What I really need
 is *3D image* rendering not *3D texture* rendering.

 More explanations:

  * One can attach an osg::Image or an osg::Texture to the color buffer of
 a given camera. But one can only specify the face argument for textures:

 *void attach http://a00098.html#a496ed6d69392c1fdb8548085900a1a87 (
 BufferComponent 
 http://a00098.html#af4d8ae808500a2f5bc9fe7b605386e74buffer,
 osg::Texture http://a00946.html *texture, unsigned int level=0,
 unsigned int face=0, bool mipMapGeneration=false, unsigned int
 multisampleSamples=0, unsigned int multisampleColorSamples=0)

 void attach http://a00098.html#a4124951a5032de595c5d28d0cc5e87a3 (
 BufferComponent 
 http://a00098.html#af4d8ae808500a2f5bc9fe7b605386e74buffer,
 osg::Image http://a00389.html *image, unsigned int
 multisampleSamples=0, unsigned int multisampleColorSamples=0)

 ** So,
   - if I attach a 3D image directly to the camera, the depth of the image
 is not taken into account, and all the image slices will contain the same
 result.
   - if I attach a Texture3D object, whether I assign it an underlying
 image doesn't matter: the content of the texture cannot be retrieved with
 the assigned image...

 Is there something I'm missing here ? Did someone already successfully
 render to a 3D texture *AND* wrote that texture to a file for instance
 ??

 Or is there a way to retrieve the content of a 3D texture into a 3D image
 (I guess retrieving the texture data from the graphic card somehow ?) [I'm
 not very good at pure OpenGL considerations, thus the question :-) ].

 Cheers! Thanks for your help guys!

 Manu.




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

Re: [osg-users] Render to 3D image...

[Emmanuel Roche]

Well, Fred,  if this is rendered within OSG then I guess that's exactly what
I want to achieve with respect to the atmosphere :-) No chance to get any
source sample for the texture precomputation stage I guess ??? :-)

By the way, there is another major issue I would like to submit to the OSG
community:

This atmospheric effect is rendered on top of everything as a screen aligned
quad. But in my application I need to be able to render multiple planets
with their own atmosphere, and satellites outside of the atmosphere (on top
of it, or behind it)...

Thus some objects must be rendered after this atmospheric Quad.


Now, the point is I'm already using the modified DepthPartitionNode to
handle cutting the complete scene into proper depth segments

== Any idea how I could force the atmospheric quad to be rendered on top of
all the Earth rendering cameras (for instance for the earth atmosphere) and
not on the closer cameras ??

Or maybe someone has another idea how to handle this kind of issue ?

Another option I'm already thinking about require to force my depth
partition node generated cameras to only write depth values between sub
values of the [0,1] segment, for instance, between [0.25,0.5] : is there an
easy way to achieve this ??

Cheers,
Manu.


2010/8/6 Frederic Bouvier fredlis...@free.fr


 - Emmanuel Roche roche.emman...@gmail.com a écrit :

  Hey, thanks for the info Frederic!
 
 
  Actually, the atmospheric scattering effect you're pointing me at is
  what I've been trying to integrate into OSG for a few days now and the
  reason why I ask those questions :-)

 So have a look here : http://www.youtube.com/user/fgfred64 ;-)

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

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

[osg-users] Render to 3D image...

[Emmanuel Roche]

Hi everyone,

I'm currently trying to generate some 3D images in an OSG based app.

I've read the previous discussions on the OSG forums concerning the 3D
texture rendering, but this doesn't help in my situation. What I really need
is *3D image* rendering not *3D texture* rendering.

More explanations:

 * One can attach an osg::Image or an osg::Texture to the color buffer of a
given camera. But one can only specify the face argument for textures:

*void attach a00098.html#a496ed6d69392c1fdb8548085900a1a87 (
BufferComponent a00098.html#af4d8ae808500a2f5bc9fe7b605386e74 buffer,
osg::Texture a00946.html *texture, unsigned int level=0, unsigned int
face=0, bool mipMapGeneration=false, unsigned int multisampleSamples=0,
unsigned int multisampleColorSamples=0)

void attach a00098.html#a4124951a5032de595c5d28d0cc5e87a3
(BufferComponenta00098.html#af4d8ae808500a2f5bc9fe7b605386e74buffer,
osg::Image a00389.html *image, unsigned int multisampleSamples=0, unsigned
int multisampleColorSamples=0)

** So,
  - if I attach a 3D image directly to the camera, the depth of the image is
not taken into account, and all the image slices will contain the same
result.
  - if I attach a Texture3D object, whether I assign it an underlying image
doesn't matter: the content of the texture cannot be retrieved with the
assigned image...

Is there something I'm missing here ? Did someone already successfully
render to a 3D texture *AND* wrote that texture to a file for instance ??

Or is there a way to retrieve the content of a 3D texture into a 3D image (I
guess retrieving the texture data from the graphic card somehow ?) [I'm not
very good at pure OpenGL considerations, thus the question :-) ].

Cheers! Thanks for your help guys!

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

Re: [osg-users] Render to 3D image...

[Emmanuel Roche]

Concerning this problem, I'm wondering if I could use the following
solution:

 1. Create a master 3D image, and allocate it;
 2. Since attaching 2D images to a camera would not require any face
argument, I could create sub images, one per z slice of the master camera,
and use setImage with an offset data pointer in the master image data...
 3. Then assign those sub images to each camera I'm using to render the
complete 3D image.

Would this work as expected ?? Or would attaching an image to a camera
actually somehow reallocate the image data ??? (and thus we would not be
able to write the slice data into the master image data).

I hope, those explanations are clear enough :-)

Manu.


2010/8/4 Emmanuel Roche roche.emman...@gmail.com

 Hi everyone,

 I'm currently trying to generate some 3D images in an OSG based app.

 I've read the previous discussions on the OSG forums concerning the 3D
 texture rendering, but this doesn't help in my situation. What I really need
 is *3D image* rendering not *3D texture* rendering.

 More explanations:

  * One can attach an osg::Image or an osg::Texture to the color buffer of a
 given camera. But one can only specify the face argument for textures:

 *void attach http://a00098.html#a496ed6d69392c1fdb8548085900a1a87 (
 BufferComponent http://a00098.html#af4d8ae808500a2f5bc9fe7b605386e74buffer,
 osg::Texture http://a00946.html *texture, unsigned int level=0, unsigned
 int face=0, bool mipMapGeneration=false, unsigned int multisampleSamples=0,
 unsigned int multisampleColorSamples=0)

 void attach http://a00098.html#a4124951a5032de595c5d28d0cc5e87a3 (
 BufferComponent http://a00098.html#af4d8ae808500a2f5bc9fe7b605386e74buffer,
 osg::Image http://a00389.html *image, unsigned int multisampleSamples=0,
 unsigned int multisampleColorSamples=0)

 ** So,
   - if I attach a 3D image directly to the camera, the depth of the image
 is not taken into account, and all the image slices will contain the same
 result.
   - if I attach a Texture3D object, whether I assign it an underlying image
 doesn't matter: the content of the texture cannot be retrieved with the
 assigned image...

 Is there something I'm missing here ? Did someone already successfully
 render to a 3D texture *AND* wrote that texture to a file for instance ??

 Or is there a way to retrieve the content of a 3D texture into a 3D image
 (I guess retrieving the texture data from the graphic card somehow ?) [I'm
 not very good at pure OpenGL considerations, thus the question :-) ].

 Cheers! Thanks for your help guys!

 Manu.


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

Re: [osg-users] osgVolume volume rendering ?

[Emmanuel Roche]

Hello Dzenan!

i've just tried the website you suggested, downloaded the baby.pvm,
bonsai1.pvm and bunny.pvm datasets, and tried commands such as:

osgvolume --window 50 50 600 400 --raw 256 256 98 1 1 big baby.pvm

-- As I have no idea about the numberOfcomponents and endianness of
those files I did multiple tests with big/little endianness and 1, 3 or
4 components

Unfortunately, everything I tried just resulted in a crash of osgvolume
without displaying anything on Windows. (I'm now using osg v2.9.8 for those
tests).

I'm now about to test all this on Linux... But for the moment, I still
haven't got any kind of volumetric rendering on Windows...


One note by the way, I didn't bother settings up the osg Data folder at all,
could it be the the osgVolume library is in fact trying to retrieve maybe
shaders or other needed ressources from that data folder ? [but I guess I
should get a warning of something like that in that case...]


Cheers!
Manu.




2010/7/12 Dženan Zukić dzen...@gmail.com

 Hi,

 I have a working osgVolume used in my program - I use it as a preliminary
 visualization. Since it has only 1D transfer function support, and does not
 combine with polygonal models, in later stage I replace it with
 isosurface+polygonal model.

 My version is basically a simplified osgVolume example. Of course, before
 modifying it I played with it a bit - the simplest way to get it to
 visualize 3D image is giving it raw data. You can find some free 3D images
 here:
 http://www9.informatik.uni-erlangen.de/External/vollib/

 Cheers,
 Dženan

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





 ___
 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] osgVolume volume rendering ?

[Emmanuel Roche]

Thanks for your help Dzenan,

but unfortunetaly, this is still not working (still get a crash and no
display), I used:

*osgvolume --raw 256 256 256 1 3 big bonzai.raw*

Note that I must specify the endianness and number of components (but I
tried multiple tests again), here is the help for the --raw argument
(according to the source code)

*//arguments.getApplicationUsage()-addCommandLineOption(--raw sizeX
sizeY sizeZ numberBytesPerComponent numberOfComponents endian
filename,read a raw image data);*

= but as you can see this line is commented. So it might be known not to
work in the version I have (v2.9.8).

Thanks !

Manu.

2010/7/17 Dženan Zukić dzen...@gmail.com

 Hi,

 I don't think osg's data folder has anything to do with it.

 I just took a look, and realized .pvm format is compressed. You can get
 gzipped datasets from volvis.org, for example this 256x256x256 dataset:
 http://www.gris.uni-tuebingen.de/edu/areas/scivis/volren/datasets/data/bonsai.raw.gz

 Try that - 1 byte per voxel (no endiannes, no components). These are raw
 files.

 Thank you!

 Cheers,
 Dženan

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





 ___
 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] osgVolume volume rendering ?

[Emmanuel Roche]

One very interesting detail concerning those osgVolume tests (still on
Windows) by the way:

I use a command like:

*osgvolume --test2 --shader --zSize 100 --window 50 50 600 400
CEMRA_HIGHRES\IM-0001-0001.png CEMRA_HIGHRES\IM-0001-0002.png
CEMRA_HIGHRES\IM-0001-0003.png ... [more files here] ...
CEMRA_HIGHRES\IM-0001-0119.png CEMRA_HIGHRES\IM-0001-0120.png -o result.dds*

I use 120 input png images.

And I get the output:

*Creating sequence of 120 volumes.*

But the resulting image (see the -o result.dds in the previous command
line), only has a size of about 500 KB, and that's clearly not enough to
hold all the 2D images. So is this really supposed to save the 3D image
content here ?? In that case it there must be a something going wrong.

Moreother, if I then try:

*osgvolume result.dds*

it seems to load the image as a simple 2D image (and outputs: *Single image
1 volumes.*)

Now, let's see on linux...

Manu.


2010/7/17 Emmanuel Roche roche.emman...@gmail.com

 Hello Dzenan!

 i've just tried the website you suggested, downloaded the baby.pvm,
 bonsai1.pvm and bunny.pvm datasets, and tried commands such as:

 osgvolume --window 50 50 600 400 --raw 256 256 98 1 1 big baby.pvm

 -- As I have no idea about the numberOfcomponents and endianness of
 those files I did multiple tests with big/little endianness and 1, 3 or
 4 components

 Unfortunately, everything I tried just resulted in a crash of osgvolume
 without displaying anything on Windows. (I'm now using osg v2.9.8 for those
 tests).

 I'm now about to test all this on Linux... But for the moment, I still
 haven't got any kind of volumetric rendering on Windows...


 One note by the way, I didn't bother settings up the osg Data folder at
 all, could it be the the osgVolume library is in fact trying to retrieve
 maybe shaders or other needed ressources from that data folder ? [but I
 guess I should get a warning of something like that in that case...]


 Cheers!
 Manu.




 2010/7/12 Dženan Zukić dzen...@gmail.com

 Hi,

 I have a working osgVolume used in my program - I use it as a preliminary
 visualization. Since it has only 1D transfer function support, and does not
 combine with polygonal models, in later stage I replace it with
 isosurface+polygonal model.

 My version is basically a simplified osgVolume example. Of course, before
 modifying it I played with it a bit - the simplest way to get it to
 visualize 3D image is giving it raw data. You can find some free 3D images
 here:
 http://www9.informatik.uni-erlangen.de/External/vollib/

 Cheers,
 Dženan

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





 ___
 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] osgVolume volume rendering ?

[Emmanuel Roche]

Okay guys !

I've just tested this on linux, and the command:

*osgvolume --raw 256 256 256 1 1 big bonzai.raw

worked just fine !!!

*So I guess this problem is only on Windows.


The good news is, I also did:

*osgvolume --raw 256 256 256 1 1 big bonzai.raw -o bonzai.dds  [on linux]

*then used the generated dds file (which has a much bigger size this time
!!! :-) )

*osgvolume bonzai.dds [on windows]

And this time, this worked too !!!

**
== So my fisrt impression is that the issue is only related to the
generation of the 3D image somehow. I don't have time to investigate this
further right now, but I might come back to this issue a bit later!

Thanks for your support guys !

Now I finally got a volume rendered on Windows, that's nice !!!

Cheers,
Manu.

*
*

*
*
*
2010/7/17 Emmanuel Roche roche.emman...@gmail.com

 Thanks for your help Dzenan,

 but unfortunetaly, this is still not working (still get a crash and no
 display), I used:

 *osgvolume --raw 256 256 256 1 3 big bonzai.raw*

 Note that I must specify the endianness and number of components (but I
 tried multiple tests again), here is the help for the --raw argument
 (according to the source code)

 *//arguments.getApplicationUsage()-addCommandLineOption(--raw
 sizeX sizeY sizeZ numberBytesPerComponent numberOfComponents
 endian filename,read a raw image data);*

 = but as you can see this line is commented. So it might be known not to
 work in the version I have (v2.9.8).

 Thanks !

 Manu.

 2010/7/17 Dženan Zukić dzen...@gmail.com

 Hi,

 I don't think osg's data folder has anything to do with it.

 I just took a look, and realized .pvm format is compressed. You can get
 gzipped datasets from volvis.org, for example this 256x256x256 dataset:
 http://www.gris.uni-tuebingen.de/edu/areas/scivis/volren/datasets/data/bonsai.raw.gz

 Try that - 1 byte per voxel (no endiannes, no components). These are raw
 files.

 Thank you!

 Cheers,
 Dženan

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





 ___
 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] osgVolume volume rendering ?

[Emmanuel Roche]

Concerning the DICOM issue, I performed additional tests:

 - The error seems to be related to compressed DICOM datasets.
 - On the website http://pubimage.hcuge.ch:8080/, most dataset will generate
errors (Invalid data value) when trying to read the dcm files as is). the
PHENIX dataset works (it doesn't seem to be compressed as the dcm files are
much bigger). The website indicates that the dataset are JPEG2000 compressed
(as far as I understand).
 - I tried to read those files on Linux too: same errors !
 - I set the dicom dictionary path properly (DCMDICTPATH=...) so that's not
the problem.
 - trying to use dcmdjpeg to try to decompress the images doesn't work
 - dcm2pnm doesnt work either
 - dcmj2pnm doesn't work too.

Any idea what I could be missing here ???


Manu.


2010/7/10 Robert Osfield robert.osfi...@gmail.com

 Hi Manu,

 It sounds like you aren't using osgVolume correctly.  First up I would
 recommend using 2.9.2 or svn/trunk as this will contain the latests
 update to osgVolume.

 Second up you talk about DCMTK build problems, you'll need to be more
 precise that this for others to help.  In general I would say the
 DCMTK under Windows can be a bit tricky, have a look through the
 archives to see how others tackled it.  I'm under Linux so don't see
 problems.

 Using dicom files is currently the easiest route to loading a full 3D
 volume, but building the 3D osg::Image yourself it's difficult.  With
 the osgvolume example you'll just have to run with --images filenames
 to get it to read a series of 2D images and pack them into an 3D
 osg::Image for rendering.

 Robert.

 On Fri, Jul 9, 2010 at 10:47 AM, Emmanuel Roche
 roche.emman...@gmail.com wrote:
  Hi everyone,
 
  I'm just starting to play with the osgVolume sample and I have a very
  beginner question about it:
 
  - Can you actually have any kind of volumetric rendering with this ???
 
  I perform many tests with various arguments,  but each time, all I get is
 a
  simple 2D image sequence of all the provided 2D images: so it's basically
  playinig just like a movie... Why would we have complex Raytracing
 shader
  techniques just to render an image sequence ? I must be missing something
  here.
 
 
  Also, note that I actually managed to get a 3D rendering specifying
 zSize,
  ySize and xSize, but again the 3D result  is merly the projection of a
  single 2D image (an the image is dynamically changing...) I know the
  osgVolume still needs more development, but is that really all I can
 expect
  from it for the moment ??
 
  Also, I could not use DICOM images directly: I got errors from the dcmtk
  library, so I first used image magick to convert my dcm images to png
  images, could it be I lost usefull 3D volumetric rendering info with
 that
  step ?
 
  And last but not least, those tests were performed on Windows, with OSG
  2.9.6. Any known limitation due to this ?
 
 
  In fact, if anyone as any screenshot I would be interested ! :-)
 
  Cheers,
  Manu.
 
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[osg-users] osgVolume volume rendering ?

[Emmanuel Roche]

Hi everyone,

I'm just starting to play with the osgVolume sample and I have a very
beginner question about it:

- Can you actually have any kind of volumetric rendering with this ???

I perform many tests with various arguments,  but each time, all I get is a
simple 2D image sequence of all the provided 2D images: so it's basically
playinig just like a movie... Why would we have complex Raytracing  shader
techniques just to render an image sequence ? I must be missing something
here.


Also, note that I actually managed to get a 3D rendering specifying zSize,
ySize and xSize, but again the 3D result  is merly the projection of a
single 2D image (an the image is dynamically changing...) I know the
osgVolume still needs more development, but is that really all I can expect
from it for the moment ??

Also, I could not use DICOM images directly: I got errors from the dcmtk
library, so I first used image magick to convert my dcm images to png
images, could it be I lost usefull 3D volumetric rendering info with that
step ?

And last but not least, those tests were performed on Windows, with OSG
2.9.6. Any known limitation due to this ?


In fact, if anyone as any screenshot I would be interested ! :-)

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

Re: [osg-users] CompositeViewer + MultiView + databasepager -- Framerate drop

[Emmanuel Roche]

Hello everyone !

Robert, in fact I found exactly where the problem comes from:

Above my star object (so all my points in a geometry in a geode) I added an
osg::Camera

On this camera I have an event callback, and in this event callback I used
to set the Camera viewport and graphics window to be the same as the master
camera (except that: 1. I doesn't make sense with a CompositeViewer since we
have 1 event traversal for possibly many View, and 2. Now I know this is
pointless anyway since a sub camera will retrieve the parent camera viewport
if it doesn't have its own (and I assume it's the same for the graphics
context ?) )

Anyway, if I remove this event callback from that camera, everything is
fine, if i keep it, I get this awfully long draw + GPU phases for at least
one View when I have two of them on the same scene.

Maybe you have an explanation for this ? But I just need to find a better
implementation for handling those stars anyway.

Manu.


2010/2/3 Robert Osfield robert.osfi...@gmail.com

 Hi Manu,

 I haven't tried osgEarth+multi-views+multiple-contexts like you are
 attempting so can't offer to much insight.  In your investigation one
 thing you could try is instead of creating two windows/two graphics
 contexts, is to create a single window/graphics context and then have
 the two views share this window using separate viewport to what
 portion of the window is dedicated to each view.  Using a single
 graphics context will drive both the OSG and the graphics/drover card
 more efficiently.

 To set the viewport just set the view's master camera to be attached
 to the window, and then set master camera's viewport to the
 appropriate portion.  Have a look at the osgcamera example to see how.

 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

[osg-users] CompositeViewer + MultiView + databasepager -- Framerate drop

[Emmanuel Roche]

hello everyone,

Just another strange issue I can't solve by myself here:

I have a scene with an osgEarth earth model,
I use a composite viewer to manage the display,

- When I use a single View on that scene everything is fine, and I get for
instance something around 200fps
- As soon as I add an additional View on the same scene, my global
framerate drops to no more than 30 fps !

I used the on screen statistics and noticed that when I have two views, then
the first one takes ages during the draw phase whereas the second one seems
to behave just fine. (the GPU phase is also a lot longer) (I'm using
SingleThreaded mode for now)

Also, this is when I use a shared context for my scene,

If I disable context sharing, then with a single View everything is still
fine, but with two views *both* views will take ages during the draw phase
(and also a very long time for the GPU phase)...

Strangely, this doesn't seem to happen when I don't have an osgEarth model
in my scene (ie so it could be somehow PagedLODs  databasePager related ?)

Did someone already face this situation ? Or do you have an idea where I
should start investigating ?

Thanks for you help guys !

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

Re: [osg-users] CompositeViewer + MultiView + databasepager -- Framerate drop

[Emmanuel Roche]

Okay, I was wrong: this is not related to the pagedLOD+databasepager I can
reproduce the same behavior without my earth model if I keep the stars, sun,
moon and mars models...

So I'm now trying to remove additional objects :-)

= In fact I use a depthPartitionNode in that scene, could this be the
source of the problem ???

Manu.


2010/2/2 Emmanuel Roche roche.emman...@gmail.com

 By the way, I also checked the camera/view details on the Screen stats, and
 both display exactly the same content.

 Manu.


 2010/2/2 Emmanuel Roche roche.emman...@gmail.com

 hello everyone,

 Just another strange issue I can't solve by myself here:

 I have a scene with an osgEarth earth model,
 I use a composite viewer to manage the display,

 - When I use a single View on that scene everything is fine, and I get
 for instance something around 200fps
 - As soon as I add an additional View on the same scene, my global
 framerate drops to no more than 30 fps !

 I used the on screen statistics and noticed that when I have two views,
 then the first one takes ages during the draw phase whereas the second one
 seems to behave just fine. (the GPU phase is also a lot longer) (I'm using
 SingleThreaded mode for now)

 Also, this is when I use a shared context for my scene,

 If I disable context sharing, then with a single View everything is still
 fine, but with two views *both* views will take ages during the draw
 phase (and also a very long time for the GPU phase)...

 Strangely, this doesn't seem to happen when I don't have an osgEarth model
 in my scene (ie so it could be somehow PagedLODs  databasePager related ?)

 Did someone already face this situation ? Or do you have an idea where I
 should start investigating ?

 Thanks for you help guys !

 Manu.




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

Re: [osg-users] CompositeViewer + MultiView + databasepager -- Framerate drop

[Emmanuel Roche]

I've managed to narrow the source of the problem even further:

If I keep all my planet models and remove the stars then everything is still
fine with 2 views !!!

= So I'm on my star model now... this model is a simple geometry with about
11 vertices, rendered as POINTS... I know I should cut this geometry
into pieces, but could this really explain the problem I'm facing now ??

Manu.


2010/2/2 Emmanuel Roche roche.emman...@gmail.com

 Okay, I was wrong: this is not related to the pagedLOD+databasepager I can
 reproduce the same behavior without my earth model if I keep the stars, sun,
 moon and mars models...

 So I'm now trying to remove additional objects :-)

 = In fact I use a depthPartitionNode in that scene, could this be the
 source of the problem ???


 Manu.


 2010/2/2 Emmanuel Roche roche.emman...@gmail.com

 By the way, I also checked the camera/view details on the Screen stats,
 and both display exactly the same content.

 Manu.


 2010/2/2 Emmanuel Roche roche.emman...@gmail.com

 hello everyone,

 Just another strange issue I can't solve by myself here:

 I have a scene with an osgEarth earth model,
 I use a composite viewer to manage the display,

 - When I use a single View on that scene everything is fine, and I get
 for instance something around 200fps
 - As soon as I add an additional View on the same scene, my global
 framerate drops to no more than 30 fps !

 I used the on screen statistics and noticed that when I have two views,
 then the first one takes ages during the draw phase whereas the second one
 seems to behave just fine. (the GPU phase is also a lot longer) (I'm using
 SingleThreaded mode for now)

 Also, this is when I use a shared context for my scene,

 If I disable context sharing, then with a single View everything is still
 fine, but with two views *both* views will take ages during the draw
 phase (and also a very long time for the GPU phase)...

 Strangely, this doesn't seem to happen when I don't have an osgEarth
 model in my scene (ie so it could be somehow PagedLODs  databasePager
 related ?)

 Did someone already face this situation ? Or do you have an idea where I
 should start investigating ?

 Thanks for you help guys !

 Manu.





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

Re: [osg-users] CompositeViewer + MultiView + databasepager -- Framerate drop

[Emmanuel Roche]

Also note that I store texture coordinates for those vertices (in fact I use
the texture coords array to store color data for the stars as a Vec2 [ie BV
index and Magnitude]) and I process this data using a shader...

Manu.


2010/2/2 Emmanuel Roche roche.emman...@gmail.com

 I've managed to narrow the source of the problem even further:

 If I keep all my planet models and remove the stars then everything is
 still fine with 2 views !!!

 = So I'm on my star model now... this model is a simple geometry with
 about 11 vertices, rendered as POINTS... I know I should cut this
 geometry into pieces, but could this really explain the problem I'm facing
 now ??


 Manu.


 2010/2/2 Emmanuel Roche roche.emman...@gmail.com

 Okay, I was wrong: this is not related to the pagedLOD+databasepager I can
 reproduce the same behavior without my earth model if I keep the stars, sun,
 moon and mars models...

 So I'm now trying to remove additional objects :-)

 = In fact I use a depthPartitionNode in that scene, could this be the
 source of the problem ???


 Manu.


 2010/2/2 Emmanuel Roche roche.emman...@gmail.com

 By the way, I also checked the camera/view details on the Screen stats,
 and both display exactly the same content.

 Manu.


 2010/2/2 Emmanuel Roche roche.emman...@gmail.com

 hello everyone,

 Just another strange issue I can't solve by myself here:

 I have a scene with an osgEarth earth model,
 I use a composite viewer to manage the display,

 - When I use a single View on that scene everything is fine, and I get
 for instance something around 200fps
 - As soon as I add an additional View on the same scene, my global
 framerate drops to no more than 30 fps !

 I used the on screen statistics and noticed that when I have two views,
 then the first one takes ages during the draw phase whereas the second one
 seems to behave just fine. (the GPU phase is also a lot longer) (I'm using
 SingleThreaded mode for now)

 Also, this is when I use a shared context for my scene,

 If I disable context sharing, then with a single View everything is
 still fine, but with two views *both* views will take ages during the
 draw phase (and also a very long time for the GPU phase)...

 Strangely, this doesn't seem to happen when I don't have an osgEarth
 model in my scene (ie so it could be somehow PagedLODs  databasePager
 related ?)

 Did someone already face this situation ? Or do you have an idea where I
 should start investigating ?

 Thanks for you help guys !

 Manu.






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

Re: [osg-users] uniform update question

[Emmanuel Roche]

Hi Paul,

On my side I finally ended with the initial design I had in mind:

I use a specific nodecallback on the node where the stateset containing my
uniforms is. This callbacks, used as a CullCallback give me the opportunity
to call the uniform update callbacks with a cullvisitor during the cull
phase.

It's not the cleanest option (I'd really wish there were cull callbacks for
uniforms directly!) but it works very well for me:

void UniformCullCallbackBridge::operator()(osg::Node * node,
osg::NodeVisitor * nv) {

  // Bouml preserved body begin 00035E8A
// retrieve the stateset on the node:
osg::StateSet* ss = node-getStateSet();
if(ss) {
osg::StateSet::UniformList uniforms = ss-getUniformList();

for(osg::StateSet::UniformList::iterator uitr = uniforms.begin();
uitr != uniforms.end();
++uitr)
{
osg::Uniform::Callback* callback =
uitr-second.first-getUpdateCallback();
if (callback) (*callback)(uitr-second.first.get(),nv);
}
}

return traverse(node,nv);
  // Bouml preserved body end 00035E8A
}

Thanks to everyone for your help/explanations on this.

Manu.


2010/1/30 Paul Martz pma...@skew-matrix.com

 Emmanuel Roche wrote:

 Those questions were indeed closely related. Yet since I'm not planing to
 use slave cameras for the moment I guess I'm better of with my node
 cullcallback to update uniforms, at least I will try that.


 The subject was poorly chosen. The thread was more related to how to set a
 different uniform per cull/draw pair - per display or per window. Setting
 the uniforms in the slave camera StateSet is one solution, and Robert's
 recent code change is designed to support that usage.

 I wanted my solution to work whether the application used slave cameras or
 not, so, like you, I needed this to work without slave cameras. The solution
 I choose was to push a StateSet containing a uniform onto the CullVisitor's
 state stack.

 Hope that helps.
   -Paul


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

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

[osg-users] uniform update question

[Emmanuel Roche]

Hi everyone,

I'm facing a problem I cannot solve by myself here, I thought I could just
ask:

- I have a scene (so a scene graph)
- I use multiple View on this single scene

-- Currently I have an homemade mixture of customized osgViewer::Viewer
objects to deal with everything so basically, for each View, I go through a
complete (EventTraversal(), UpdateTraversal(), RenderingTraversals() ) loop
sequentially.

- Now I would like to switch to a CompositeViewer and thus go through the
event/update traversals only once per Scene (If I understand the
CompositeViewer design properly).

But I have a very specific problem to solve here:

In my scene graph I use shaders and uniforms. those uniforms have update
callbacks, and in those update callbacks, I retrieve my currently rendering
View and then the View matrix to generate eye coordinates.

-- I assume using the osg_ViewMatrix uniform is not an option for me
because I need to convert very big position vector and very big view matrix
translation, and I would clearly get a problem here if I don't have double
precision.
-- With the CompositeViewer I can't access the individual View anymore in
the update traversal() since this process is View agnostic I would say.


-- Since my views will need different settings for the uniforms, I was
thinking I would just need to do something in the cull traversal, but here I
realized something which seems strange to me: there is no such method as
uniform::setCullCallback(...)

So, the question is, how would you update your uniforms properly in that
case ?

I mean, I could still put a cullcallback on the node owning the stateset
containing the uniform for instance and update from here (assuming I can
retrieve the Viewmatrix I need somehow in that Cullcallback...) but is this
really the best option ??

- And generally speaking, would a uniform::setCullCallback() not make sense
for some reason I'm apparently missing for now ?

Bonus question by the way: How would I access the master camera ViewMatrix
in a cullcallback ? i've seen we have
osgUtil::CullVisitor::getCurrentCamera() but would this return the Master
camera of the View or just the current camera in the scene graph (as I use
DepthPartitionNode I have many sub cameras in my scene...)

Thanks in advance is someone has any tip/advise/complete solution on those
questions!

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

Re: [osg-users] uniform update question

[Emmanuel Roche]

Hello Wojtek,

thanks for the tips !!
I will try with getRenderStage()-getCamera() and let you know if it works
for me too.

But concerning the cull callback for uniforms, isn't it already the case for
the update callback you can put on them ? (if you use the same uniform in
multiple statesets/nodes, then the update callback is called multiple times
per frame... [or is there some kind of security system to prevent this I'm
not aware of ? ]

Cheers,
Manu.


2010/1/29 Wojciech Lewandowski lewandow...@ai.com.pl

  Hi Manu,

 IMHO I can offfer tips for 2 or your questions:

 Why no cull calback for uniform ?
 I guess there is no cull calback for state attribs/uniforms because they
 could be used many times and located in many statesets/nodes. So cull
 visitor can traverse them couple times per one frame.

 How to obtain master camera view matrix ?
 In ViewDependentShadowTechniques I used following method to obtain master
 view or slave view camera:
 cullVisitor-getRenderStage()-getCamera()

 Depending on your setup of extra cameras it may wortk or not, but I guess
 you could try it.

 Cheers,
 Wojtek Lewandowski



 - Original Message -
 *From:* Emmanuel Roche roche.emman...@gmail.com
 *To:* OSG Users osg-users@lists.openscenegraph.org
 *Sent:* Friday, January 29, 2010 1:08 PM
 *Subject:* [osg-users] uniform update question

 Hi everyone,

 I'm facing a problem I cannot solve by myself here, I thought I could just
 ask:

 - I have a scene (so a scene graph)
 - I use multiple View on this single scene

 -- Currently I have an homemade mixture of customized osgViewer::Viewer
 objects to deal with everything so basically, for each View, I go through a
 complete (EventTraversal(), UpdateTraversal(), RenderingTraversals() ) loop
 sequentially.

 - Now I would like to switch to a CompositeViewer and thus go through the
 event/update traversals only once per Scene (If I understand the
 CompositeViewer design properly).

 But I have a very specific problem to solve here:

 In my scene graph I use shaders and uniforms. those uniforms have update
 callbacks, and in those update callbacks, I retrieve my currently rendering
 View and then the View matrix to generate eye coordinates.

 -- I assume using the osg_ViewMatrix uniform is not an option for me
 because I need to convert very big position vector and very big view matrix
 translation, and I would clearly get a problem here if I don't have double
 precision.
 -- With the CompositeViewer I can't access the individual View anymore
 in the update traversal() since this process is View agnostic I would say.


 -- Since my views will need different settings for the uniforms, I was
 thinking I would just need to do something in the cull traversal, but here I
 realized something which seems strange to me: there is no such method as
 uniform::setCullCallback(...)

 So, the question is, how would you update your uniforms properly in that
 case ?

 I mean, I could still put a cullcallback on the node owning the stateset
 containing the uniform for instance and update from here (assuming I can
 retrieve the Viewmatrix I need somehow in that Cullcallback...) but is this
 really the best option ??

 - And generally speaking, would a uniform::setCullCallback() not make sense
 for some reason I'm apparently missing for now ?

 Bonus question by the way: How would I access the master camera
 ViewMatrix in a cullcallback ? i've seen we have
 osgUtil::CullVisitor::getCurrentCamera() but would this return the Master
 camera of the View or just the current camera in the scene graph (as I use
 DepthPartitionNode I have many sub cameras in my scene...)

 Thanks in advance is someone has any tip/advise/complete solution on those
 questions!

 Regards,
 Manu.

  --

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


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


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

Re: [osg-users] uniform update question

[Emmanuel Roche]

Thanks Paul,

Those questions were indeed closely related. Yet since I'm not planing to
use slave cameras for the moment I guess I'm better of with my node
cullcallback to update uniforms, at least I will try that.

Cheers,
Manu.


2010/1/29 Paul Martz pma...@skew-matrix.com

 I recommend you search the archives for the recent thread Uniform per
 slave Camera. Several solutions, including the solution I eventually used,
 are discussed in that thread.

 Paul Martz
 Skew Matrix Software LLC
 _http://www.skew-matrix.com_ http://www.skew-matrix.com/
 +1 303 859 9466



 Emmanuel Roche wrote:

 Hi everyone,

 I'm facing a problem I cannot solve by myself here, I thought I could just
 ask:

 - I have a scene (so a scene graph)
 - I use multiple View on this single scene

 -- Currently I have an homemade mixture of customized osgViewer::Viewer
 objects to deal with everything so basically, for each View, I go through a
 complete (EventTraversal(), UpdateTraversal(), RenderingTraversals() ) loop
 sequentially.

 - Now I would like to switch to a CompositeViewer and thus go through the
 event/update traversals only once per Scene (If I understand the
 CompositeViewer design properly).

 But I have a very specific problem to solve here:

 In my scene graph I use shaders and uniforms. those uniforms have update
 callbacks, and in those update callbacks, I retrieve my currently rendering
 View and then the View matrix to generate eye coordinates.

 -- I assume using the osg_ViewMatrix uniform is not an option for me
 because I need to convert very big position vector and very big view matrix
 translation, and I would clearly get a problem here if I don't have double
 precision.
 -- With the CompositeViewer I can't access the individual View anymore
 in the update traversal() since this process is View agnostic I would say.


 -- Since my views will need different settings for the uniforms, I was
 thinking I would just need to do something in the cull traversal, but here I
 realized something which seems strange to me: there is no such method as
 uniform::setCullCallback(...)

 So, the question is, how would you update your uniforms properly in that
 case ?

 I mean, I could still put a cullcallback on the node owning the stateset
 containing the uniform for instance and update from here (assuming I can
 retrieve the Viewmatrix I need somehow in that Cullcallback...) but is this
 really the best option ??

 - And generally speaking, would a uniform::setCullCallback() not make
 sense for some reason I'm apparently missing for now ?

 Bonus question by the way: How would I access the master camera
 ViewMatrix in a cullcallback ? i've seen we have
 osgUtil::CullVisitor::getCurrentCamera() but would this return the Master
 camera of the View or just the current camera in the scene graph (as I use
 DepthPartitionNode I have many sub cameras in my scene...)

 Thanks in advance is someone has any tip/advise/complete solution on those
 questions!

 Regards,
 Manu.


 


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

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

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

[osg-users] TriStripVisitor issue

[Emmanuel Roche]

Hi everyone,

I have a strange problem with the TryStripVisitor:

When I use it on a model (with about 6000 triangles, described as TRIANGLES
[thus using 18000 vertices]) I get trip strip primitive sets indeed BUT
actually I get a few TRIANGLE_STRIP primitive sets with 4 vertices in each,
and then a single big TRIANGLES primitive set with about 17950 vertices 

So, most of the model is just not stripped at all ! any idea what I could be
doing wrong ???

Moreother, I've noticed that the geometry is then transformed as an indexed
geometry... correct me if I'm wrong but indexed geometries are slower that
simple vertices ordered arrays. If there a way to switch this or am I on my
own on this ?

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

Re: [osg-users] TriStripVisitor issue

[Emmanuel Roche]

Okay,

more details on this:

the problem comes from the helper structure VertexAttribComparitor

in the function VertexAttribComparitor::compare(unsigned int lhs, unsigned
int rhs) we call the template array compare(unsigned int lhs, unsigned int
rhs) function, and there we just use regular comparisons:

virtual int compare(unsigned int lhs,unsigned int rhs) const
{
const T elem_lhs = (*this)[lhs];
const T elem_rhs = (*this)[rhs];
if (elem_lhselem_rhs) return -1;
if (elem_rhselem_lhs) return 1;
return 0;
}

here we don't take any precision into account at all... whereas my
vertices are given in meter units and may have a little resolution of about
0.1 millimeter !

So this implementation won't fit for my needs (and I think there is an high
chance it may not fit the needs for many other people no ?) maybe we should
add a precision parameter at some point, but for now I just don't have the
time to deal with this properly :-)

Cheers,
Manu.


2009/11/23 Emmanuel Roche roche.emman...@gmail.com

 Hi Robert,

 Actually, I've noticed that the problem doesn't come from the underlying
 tristripper library:

 instead, it seems that the indice array generated from my vertices is
 incorrect: I suspect that the comparison function to find if too vertices
 are the same or not is too precise in my case. Do you have a clear idea
 where this is done ? (otherwise, I will just read more code and find it...)

 cheers,

 Manu.



 2009/11/23 Emmanuel Roche roche.emman...@gmail.com

 Actually, I also noticed that OSG v2.8.1 uses version 1.0 of the
 tristripper library.

 As I'm quite in an hurry, I think I will re-implement my own
 tristripvisitor with the latest version of tristripper and check if this
 makes a difference. Will let you know what's the result of this test.

 But I believe this could really be a generic issue (it happens with all
 the models I tested) and thus would mean many people are currently using
 not so well tri-stripped geometries if they use this optimiser feature !
 (it is the case for instance in the OSGExp export plugin for 3DS max as I've
 noticed this issue there for the first time).

 regards,
 Manu.



 2009/11/23 Robert Osfield robert.osfi...@gmail.com

 Hi Manu,

 If the tristripper doesn't connect the triangles together well then it
 can result on few tristrips and lots of unconnected traingles that it
 has to put into a single list of triangles to avoid lots of separate
 primitive calls.

 As to why your model is not being stripped well I can't say.  We've
 used 3rd party code to do the tri-stripping so I'm not best placed to
 answer the low level questions, but... the original author of the cdoe
 Tanguy Fautre is now an OSG user and I believe still on the list so
 perhaps he'll be able to chip in ;-)

 Robert.

 On Mon, Nov 23, 2009 at 11:08 AM, Emmanuel Roche
 roche.emman...@gmail.com wrote:
  Hi everyone,
 
  I have a strange problem with the TryStripVisitor:
 
  When I use it on a model (with about 6000 triangles, described as
 TRIANGLES
  [thus using 18000 vertices]) I get trip strip primitive sets indeed
 BUT
  actually I get a few TRIANGLE_STRIP primitive sets with 4 vertices in
 each,
  and then a single big TRIANGLES primitive set with about 17950 vertices
 
 
  So, most of the model is just not stripped at all ! any idea what I
 could be
  doing wrong ???
 
  Moreother, I've noticed that the geometry is then transformed as an
 indexed
  geometry... correct me if I'm wrong but indexed geometries are slower
 that
  simple vertices ordered arrays. If there a way to switch this or am I
 on my
  own on this ?
 
  Regards,
  Manu.
 
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




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

Re: [osg-users] Sharing PagedLOD node in multiple osgViewer::Viewer windows

[Emmanuel Roche]

Hello Robert !

I followed this thread as I'm facing the same issue Justin discovered:

- I'm on Windows (XP  Vista)
- using OSG 2.8.2
- using wxWidgets 2.8

And I built a multiple view application.
Thoses views are currently built around multiple osgViewer::Viewer objects.
Some of those views may be hidden by the user (they are inside advanced
notebook controls).

I'm currently not using CompositeViewer for two reasons:
1. [the most important] compositeviewer would expect to render all the
views, and if some are hidden this would lead to an issue due to wxWidgets
wxGLCanvas makeCurrent() implementation.
2. My scene must be updated specifically by each viewer, and the each
_updateVisitor has a user data pointer to the viewer itself, whereas the
compositeviewer only as a single _updateVisitor and update the scenes only
once per cycle.

Now I'm also using a PagedLOD in my scene, and when I have 2 different
camera positions, the database pagers seem to get confused. (I tried
multiple db pagers or one shared DB pager, the result is the same).

Why I really wan to know is: where should I look for explanations on the
(supposed?) proper behavior of the CompositeViewer in that case in the
sources ? As it may be easier for my to implement this part in the existing
system rather than switching to CompositeViewer usage.


Otherwise, if I have to switch:
- Concerning my point 1) I supposed I could force the OpenGL context
SetCurrent() call, but then to save ressources, I supposed I can use a
nodemask of 0x0 for the hidden view master cameras, am I wrong ?

- Concerning my point 2) what would be the best (and is there a way in fact
?!) to force a compositeviewer to update each scene just before rendering it
(as some update callbacks will modify the scene depending on the window 
view where it will be rendered ? According to my understanding of
compositeviewer, this would just break everything (the updateTraversal()
function then rendering for all views concept would not hold anymore!)



Cheers!
Manu.



2008/9/28 Robert Osfield robert.osfi...@gmail.com

 Hi Justin,

 Could you please switch to using a CompositeViewer with multiple
 Views, rather than multiple Viewers, as you usage model is intended to
 be supported by CompositeViewer, you are much more likely to find
 success/stability when using the OSG in the way it's intended.

 Also try moving up to OSG 2.6, 2.7.x or SVN/trunk as there are plenty
 of improvements across the board, including to paging and multiple
 window work, I can't say for certain this will fix you problem, but
 there it's definitely worth a try.

 Robert.

 On Sat, Sep 27, 2008 at 1:58 AM, KSpam keesling_s...@cox.net wrote:
  My application utilizes a osg::PagedLOD node for terrain that is shared
 across
  multiple osgViewer::Viewer instances.  The terrain paging works
 beautifully
  when I only have a single window open; however, there are issues whenever
 I
  open a second window.
 
  Some of the issues I see are:
  1) Window 1 appears to revert to the lowest LOD
  2) Window 1 and 2 seem to flicker as if fighting over which texture or
 tile
  should be visible
  3) Sometimes window 2 textures are missing for some tiles (i.e. white
  background)
 
  I suspect that I might be using osgDB::DatabasePager improperly.  I have
 tried
  sharing the same osgDB::DatabasePager across all osgViewer::Viewer
 instances,
  and I have also tried using a unique osgDB::DatabasePager for each
  osgViewer::Viewer instance.  What is the correct approach?
 
  Any ideas as to what I am doing wrong?  Any suggestions for me to try?
 
  I am using OSG 2.4.
 
  Thanks,
  Justin
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] osgEarth + OSG 2.8.0 + ATI card

[Emmanuel Roche]

Hi Jason,

I've already tried deleting the cache folders, unsuccessfully.

And how can I retrieve the version of my current osgEarth lib ?? :-) I
cannot find that in the sources, and I just don't remember which version I
downloaded :-)


And by the way, this as nothing to do with this thread yet, I have another
question for you: are you aware of a mayor problem which would happen if I
try to apply a shader on the osgEarth model and compute the terrain
elevation in the shader ? (I could pass the elevation texture as an
additional ImageLayer I guess ?  And if I add a few uniforms for each
terrain tile, this should not be too complex, is it ? )

Manu.

2009/4/29 Jason Beverage jasonbever...@gmail.com

 Hi Manu,

 Are you using a cache for your .earth files?  If so, try deleting your disk
 cache and see if that helps.

 Also, what version of osgEarth are you using 1.0 or 1.1?  1.1 added support
 for mixing mercator and geodetic sources, which can sometimes result in
 non-power-of-two textures being used.  I wonder if perhaps there is an issue
 with your card and NPOT.

 Thanks,

 Jason


 On Wed, Apr 29, 2009 at 4:49 AM, Emmanuel Roche 
 roche.emman...@gmail.comwrote:

 Here are a few screen captures...

 Note the half visible groenland on the right side on picture 2 (with part
 of africa on the right :-) ).
 Or the low level Europe map on the left on picture 1.

 The position of the camera is somewhere next to munich in Germany !

 If I don't move the camera the textures eventually change but they are
 replaced by other incorrect textures :-(

 So if you have any idea what I could try here this could be very helpful.

 Manu.





 2009/4/29 Emmanuel Roche roche.emman...@gmail.com

 Hi Jason,

 thanks for your answer. Actually, I just downloaded 2.8.1 rc3, built  it
 and tested my software with those binaries: it solved to problem !!... to
 some extends... :-(

 Actually, i think i'm now facing another ATI specific issue: I can start
 my app, retrieve image and elevation tiles and built my earth model...
 except that after some time (and this is also true if I use an simple
 example like osgviewer yahoo_aerial.earth) it seems that my ATI just start
 mixing all the loaded textures!

 And in fact it seems to be a quite advanced feature as the mixing is
 progressive !!! (ie. We have a nice fading effect when you move slowing !!)

 My guess is, it could be that the graphic card memory is filled with
 textures, and then the ATI driver start using old texture objects
 depending on your distance to your model expecting to create a nice fading
 effect (assuming what we have here are mipmaped textures ?) (except that
 osgEarth keeps updating all the textures any way, so old textures for a
 given area are actually replaced by other textures for other areas). Could
 this make sense ? (or maybe I'm just saying silly things I'm really not an
 expert when it comes to the low level details like that :-) ).

 I'm joining a couple of screen capture in a following mail: maybe someone
 already faced this before.

 Manu.


 2009/4/28 Jason Beverage jasonbever...@gmail.com

 Hi Emmanuel,

 Glad to hear osgEarth is working out for you:)

 Try disabling VBO's by setting the OSG_GL_EXTENSION_DISABLE environment
 variable to GL_ARB_vertex_buffer_object.

 This is really a temporary solution, once 2.8.1 is out the door, you can
 probably just upgrade and it should work fine.

 Thanks!

 Jason

 On Tue, Apr 28, 2009 at 6:12 AM, Emmanuel Roche 
 roche.emman...@gmail.com wrote:

 Hi everyone !

 I've been testing osgEarth for a few days now: it works perfectly on my
 nvidia cards.

 But when trying the same application with an ATI cards, the app just
 shutdowns on some cards, or crashes (with the error mentioned on the
 osgEarth forum here: http://n2.nabble.com/Ati-error-td2603275.html )

 I've read that the rc3 for OSG 2.8.1 comes with a fix item : fixes to
 display lists/vbo creation that prevent crash under ATI drivers. My
 question is : do you know if this is related to the problem I'm 
 experiencing
 currently and has someone already tested osgEarth on a previously crashing
 ATI cards with that version of OSG ?

 best regards,
 Manu.


 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org

 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org

 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




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



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


___
osg-users

Re: [osg-users] frustum culling in shader

[Emmanuel Roche]

Ohh !

sorry, I though it was the contrary.

In that case yes, this is a valid option too !! Thanks for your help !

I guess I could also implement this behavior with a cull callback, no ?

manu.

2009/4/30 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com

 Hello Emmanuel,

  Sébastien, I'm afraid I cannot use the transform you're suggesting: in
 fact I should not rely at all on the camera position, because the cam
 position may also depends on moving objects in my scene and the cam position
 is updated during the event traversal.


 That's not a problem because the transform code I've sent will set the
 sky's position during the cull phase, so after the event traversal. Also, as
 I said, if you use this you could use a very small sphere which would then
 have no effect on the rest of your scene.

  So I would update the position with the current cam pos,
 Then update the cam pos with another objet position
 and then render the scene


 That's not what would happen. If your update cam pos with another object
 position above happens in the event traversal as you say, then using the
 Transform subclass I sent you, the skydome's position will be updated in the
 cull traversal, which is after the event traversal, and all will be well.

 Sure, there are different ways of achieving the same result, but IMHO this
 is a really simple way, completely scenegraph-based, and keeps changes local
 to the skydome itself (the skydome does its own work alone and does not rely
 on external factors to do it).


 Hope this helps,

 J-S
 --
 __
 Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.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] frustum culling in shader

[Emmanuel Roche]

Hi Sébastien,

2009/4/30 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com

 Hi Emmanuel,

  I can't get anything to work properly for the moment... (actually I was
 doublely wrong: the eventTraversal() is before the cull traversal yes, but
 also, the camera manipulator matrix is not updated in the event traversal...
 and so I still have my initial issue).


 I forgot to give you a few elements to complete this, perhaps these can
 help:

osg::Transform* transform = new MoveWithCameraTransform;
transform-setCullingActive(false);
transform-addChild(sky); // skydome or skybox
transform-setReferenceFrame(osg::Transform::ABSOLUTE_RF);

 I think the important part here is the ABSOLUTE_RF. Try that out and see if
 it works better.


I haven't try that yet,  but according to my previous tests I'm pretty sure
this won't work: if I use the ABSOLUTE_RF I will loose the camera rotation
(ie the stars will really be fixed on the camera) and that's obviously not
the desired effect: the star points must be influenced by the view point
rotation.




  Yet, I'm trying something even more simple: as you suggested Sébastien,
 I'm building a giant none moving sphere...

 Except that, when I say giant I really mean GIANT, since I'm trying to
 place star points realistically in the universe... (hmm)

 So the radius of my sphere is: 8.80 * 10e26 (in meters :-) )


 For something like that, you'll need to disable the sphere's contribution
 in the auto near/far computation, otherwise the distance between the near
 and far planes will be such that precision will be really bad. That might be
 what you're seeing, since all your other objects are extremely small in
 comparison it's normal that you can't see them after a certain distance but
 it's more obvious that you can't see the sky.


Actually, I'm was using a sub camera to handle this object, so the near/far
planes are computed to fit on this object only and there is no interaction
with the rest of the scene.

And the strange thing is, this didn't work.

But now i'm starting to understand: i'm using the default near/far
computation mode in my sub cam (using bounding spheres) and in fact in this
particular case, I'm in the middle of my object, and the object has this
enormous size, this probably leads to a far too big scale difference between
the planes (something like near ~= 0.0 and far ~= 10e26 ).

This would explain why this is not working with a single sub camera but
working fine with a DepthPartitionNode : the depthpartionnode adds many
other cameras to render this single object properly.



 Check the discussion I linked to before for the final CullCallback and
 DrawCallback I used to make sure my sky was rendered but didn't participate
 in the auto near/far computation. It might help.

 Other than that I don't know if you're running into some other limit.
 Others will have to answer that one.

 Note that since your stars are far enough to be considered at infinity, I
 don't think my solution applies that much to your situation. In your place I
 would really just place a sphere/box at the camera position and make sure it
 renders after all opaque objects, that will give the illusion that the stars
 are at infinity and will eliminate the near/far problems. Try what I
 suggested above and see if it works for you, I think it's a better solution
 if you can get it to work.


Yes, you're totally right: just finding a way to update the star sphere
position after the last update of the camera manipulator would probably be
easier, any way the solution I found with the DPN is already quite nice
(even if doesn't seem to be perfect since I can't see all the stars when I
use this object as a camera target)

regards,
Manu.





 Hope this helps,

 J-S
 --
 __
 Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.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

[osg-users] texture computation

[Emmanuel Roche]

Hi all,

A shader OpenGL context related question now:

suppose I want to pre-compute a few textures.

- I can create the shader programs,
- prepare the textures and attach them to a camera object,
- create a viewer, set its camera
- and ask the camera to render to a frame buffer object.

then what is the best setting so that I DON'T see the viewer window when I
call viewer-frame() ??

if I call viewer-setUpViewInWindow(-1, -1, 1, 1); for instance,  can I
still render my texture properly ? (I guess so if I set the camera viewport
to the correct size, am I wrong ?)

Or maybe there is a way to hide the window properly ?

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

Re: [osg-users] osgEarth + OSG 2.8.0 + ATI card

[Emmanuel Roche]

Hi Jason,

thanks for your answer. Actually, I just downloaded 2.8.1 rc3, built  it and
tested my software with those binaries: it solved to problem !!... to some
extends... :-(

Actually, i think i'm now facing another ATI specific issue: I can start my
app, retrieve image and elevation tiles and built my earth model... except
that after some time (and this is also true if I use an simple example like
osgviewer yahoo_aerial.earth) it seems that my ATI just start mixing all
the loaded textures!

And in fact it seems to be a quite advanced feature as the mixing is
progressive !!! (ie. We have a nice fading effect when you move slowing !!)

My guess is, it could be that the graphic card memory is filled with
textures, and then the ATI driver start using old texture objects
depending on your distance to your model expecting to create a nice fading
effect (assuming what we have here are mipmaped textures ?) (except that
osgEarth keeps updating all the textures any way, so old textures for a
given area are actually replaced by other textures for other areas). Could
this make sense ? (or maybe I'm just saying silly things I'm really not an
expert when it comes to the low level details like that :-) ).

I'm joining a couple of screen capture in a following mail: maybe someone
already faced this before.

Manu.


2009/4/28 Jason Beverage jasonbever...@gmail.com

 Hi Emmanuel,

 Glad to hear osgEarth is working out for you:)

 Try disabling VBO's by setting the OSG_GL_EXTENSION_DISABLE environment
 variable to GL_ARB_vertex_buffer_object.

 This is really a temporary solution, once 2.8.1 is out the door, you can
 probably just upgrade and it should work fine.

 Thanks!

 Jason

 On Tue, Apr 28, 2009 at 6:12 AM, Emmanuel Roche 
 roche.emman...@gmail.comwrote:

 Hi everyone !

 I've been testing osgEarth for a few days now: it works perfectly on my
 nvidia cards.

 But when trying the same application with an ATI cards, the app just
 shutdowns on some cards, or crashes (with the error mentioned on the
 osgEarth forum here: http://n2.nabble.com/Ati-error-td2603275.html )

 I've read that the rc3 for OSG 2.8.1 comes with a fix item : fixes to
 display lists/vbo creation that prevent crash under ATI drivers. My
 question is : do you know if this is related to the problem I'm experiencing
 currently and has someone already tested osgEarth on a previously crashing
 ATI cards with that version of OSG ?

 best regards,
 Manu.


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



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


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

Re: [osg-users] osgEarth + OSG 2.8.0 + ATI card

[Emmanuel Roche]

Hi Robert,

I've already updated my drivers... yesterday :-) So I'm afraid this won't
help so much for now.

Can you tell me which ATI card you are using ?

We are experiencing the same problems here with a Mobility Radeon X1900
and a Radeon HD 3650.

Manu.



2009/4/29 Robert Osfield robert.osfi...@gmail.com

 Hi Manu,

 On Wed, Apr 29, 2009 at 9:27 AM, Emmanuel Roche
 roche.emman...@gmail.com wrote:
  Actually, i think i'm now facing another ATI specific issue: I can start
 my
  app, retrieve image and elevation tiles and built my earth model...
 except
  that after some time (and this is also true if I use an simple example
 like
  osgviewer yahoo_aerial.earth) it seems that my ATI just start mixing
 all
  the loaded textures!
 
  And in fact it seems to be a quite advanced feature as the mixing is
  progressive !!! (ie. We have a nice fading effect when you move slowing
 !!)

 This sounds like it might be mip mapping at fault.  I've not seen this
 first hand on the ATI card I'm testing with, but I've heard about the
 issue over the years w.r.t ATI cards.

 Try updating your OpenGL driver.

 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

[osg-users] frustum culling in shader

[Emmanuel Roche]

Hi everyone,

Just again a simple problem I can't solve myself:

I have an sphere object I want to use as a sky sphere. What's the best wait
to do that ???

The idea I came to is to use a vertex shader to offset each of the sphere
vertex by the current position of the camera in the model frame. But then
nothing is displayed because the moved vertices are behind the near plane
and are culled :-(

Any idea ?

I guess I'm not the first one trying to render a sky sphere any way ??

thanks for your help.

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

Re: [osg-users] frustum culling in shader

[Emmanuel Roche]

Hi Paul,

well, actually, I'm not exactly rendering directly in eye coordinates
(provided I understand what you mean): the sphere should not rotate with the
camera (in fact I'm not rendering a sphere: rather points representing stars
by the way).

But your idea is very good: until now, I was using something like:

 gl_Position = gl_ProjectionMatrix * gl_ModelViewMatrix *
myModifiedVertexPos;

== I'm computing the modified vertex position by offseting the gl_Vertex by
the camera position in the model frame.

Now that you mention it I realize my error must come from the usage of the
gl_ProjectionMatrix which is the latest projection matrix computed by OSG
(using the initial sphere vertices).

I'm not familiar at all with projection matrices computation, but I will
give it a try tomorrow  :-).

thanks for your help.
Manu.


2009/4/29 Paul Martz pma...@skew-matrix.com

  So you are effectively rendering the sphere in eye coordinates. Have you
 tried simply projecting the coordinates (in the vertex shader) onto the far
 plane and rendering them there? The coordinates will (of course) need to be
 between the near and far plane in order to not be clipped, so just
 projecting them into that range (and ideally onto the far plane) should do
 the trick.

 Paul Martz
 *Skew Matrix Software LLC*
 http://www.skew-matrix.com
 +1 303 859 9466


  --
 *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
 osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Emmanuel Roche
 *Sent:* Wednesday, April 29, 2009 9:28 AM
 *To:* OSG Users
 *Subject:* [osg-users] frustum culling in shader

 Hi everyone,

 Just again a simple problem I can't solve myself:

 I have an sphere object I want to use as a sky sphere. What's the best wait
 to do that ???

 The idea I came to is to use a vertex shader to offset each of the sphere
 vertex by the current position of the camera in the model frame. But then
 nothing is displayed because the moved vertices are behind the near plane
 and are culled :-(

 Any idea ?

 I guess I'm not the first one trying to render a sky sphere any way ??

 thanks for your help.

 manu.


 ___
 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] frustum culling in shader

[Emmanuel Roche]

Hi again!

Sébastien, I'm afraid I cannot use the transform you're suggesting: in fact
I should not rely at all on the camera position, because the cam position
may also depends on moving objects in my scene and the cam position is
updated during the event traversal.

So I would update the position with the current cam pos,
Then update the cam pos with another objet position
and then render the scene

== This leads to improper rendering (specially when your targeted objects
are moving very fast) [and I'm rendering a solar system where I use meters
as the base unit  :-)]

regards,
Manu.


2009/4/29 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com

 Hi Emmanuel,

  I have an sphere object I want to use as a sky sphere. What's the best
 wait to do that ???


 There's been discussion over the last few days about ways to disable auto
 near/far calculation and override the far plane setting for a skydome /
 sphere. See this thread:

 http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/43442

 It's a little convoluted but I ended up with something that worked well.

 The sphere itself you can do whatever way you want. I prefer to have a
 large sphere that is in the scene (i.e. that doesn't move with the eye
 point) but you may want it to move, in which case I think the easiest way is
 to use a transform that places it in the right place automatically:

 class MoveWithCameraTransform : public osg::Transform
 {
public:
// Get the transformation matrix which moves from local coords to
 world coords.
virtual bool computeLocalToWorldMatrix(osg::Matrix matrix,
osg::NodeVisitor* nv) const
{
osgUtil::CullVisitor* cv =
 dynamic_castosgUtil::CullVisitor*(nv);
if (cv)
{
osg::Vec3 eyePointLocal = cv-getEyeLocal();
matrix.preMult(osg::Matrix::translate(eyePointLocal));
}

return true;
}

// Get the transformation matrix which moves from world coords to
 local coords.
virtual bool computeWorldToLocalMatrix(osg::Matrix matrix,
osg::NodeVisitor* nv) const
{
osgUtil::CullVisitor* cv =
 dynamic_castosgUtil::CullVisitor*(nv);
if (cv)
{
osg::Vec3 eyePointLocal = cv-getEyeLocal();
matrix.postMult(osg::Matrix::translate(-eyePointLocal));
}

return true;
}
 };

 If you use this, you don't need to muck around with the auto near/far
 calculation like I did. You can use a sphere of very small size and use an
 osg::Depth that sets fragments only at the far plane, rendering it after all
 other opaque objects have been rendered (but before transparent ones so they
 will be blended with the sky if needed):

// ss is the skydome's stateset.
// Transparent bin is #10 by default so render just before
// transparent objects.
ss-setRenderBinDetails(9, RenderBin);
ss-setAttributeAndModes(
new osg::Depth(osg::Depth::LEQUAL, 1.0, 1.0),
osg::StateAttribute::ON);

 Hope this helps,

 J-S
 --
 __
 Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.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

[osg-users] osgEarth + OSG 2.8.0 + ATI card

[Emmanuel Roche]

Hi everyone !

I've been testing osgEarth for a few days now: it works perfectly on my
nvidia cards.

But when trying the same application with an ATI cards, the app just
shutdowns on some cards, or crashes (with the error mentioned on the
osgEarth forum here: http://n2.nabble.com/Ati-error-td2603275.html )

I've read that the rc3 for OSG 2.8.1 comes with a fix item : fixes to
display lists/vbo creation that prevent crash under ATI drivers. My
question is : do you know if this is related to the problem I'm experiencing
currently and has someone already tested osgEarth on a previously crashing
ATI cards with that version of OSG ?

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

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

:-(... I'm really going to cry now...

Guys, I tried something else and I feel like I'm loosing my mind:

Since I cannot pick anything when traversing a sub camera, I tried to build
my scene this way:
- the main View camera  (with cull mask set to 0x1)
  - my root group
- a sub camera (with node mask set to 0x1)
  - a PositionAttitudeTransform (with a scale set)
- an object
- An hidden group (with node mask set to 0x100)
  - a link to the SAME previous PositionAttitudeTransform object.

... With that I still have a proper display (the default node mask is
0x): only my sub camera is rendered and the hidden group is not
visible as expected.

then for my IntersectionVisitor I obviously use the traversal mask 0x100 :
this way I was expecting to traverse my main camera and the hidden group,
but none of the sub camera... and guess what ? It's just not working 
:-( It works if I don't hide my hidden group (giving it a node mask of
0x101, but of course this doesn't make sense considering the goal I
have)... So the IntersectionVisitor traversal also depends on the cull
mask or something like that ? I could really use some explanations on
that...

By the way I'm using OSG 2.6...

regards,
Manu.



2008/9/23 Emmanuel Roche [EMAIL PROTECTED]

 Okay...

  I think I tried everything I could think about, unsuccessfully...
 unfortunately, I'm currently on WinXP with Visual Studio and for some
 obscure reason, I just cannot get/use the debug symbols from some of the OSG
 libraries (maybe beacuse I'm accessing those functions introspectively
 though a Lua release binary ? not sure about all that...) an as a result I
 cannot go deeper into those tests :-(

 But I've just discovered a new fact: this is at least partially linked to
 the scale of my object, I tried the following scene graph:

 - the main View camera
   - my root group
 - a sub camera
   - a PositionAttitudeTransform (with a scale set)
 - an object

 --- then depending on the scale applied in the PositionAttitudeTransform I
 can pick parts of my object or not : the bigger the scale, the closer to the
 object I need to be to get some intersections (and I'm not even sure those
 intersections are correct...). So could there be a scale factor not applied
 somewhere ?? Or maybe, since my main camera renders no objects its near/far
 planes are set to minimal values and then those settings are not modified
 accordingly when going though a sub camera in an intersectionVisitor [this
 could explain why I cannot select objects if I'm not very very close to them
 (and depending on their scale)...] ?

 Is there an other way to render Univers scale + high precision scenes
 without using multiple cameras as children ??? I did a quick test using
 ClearNodes and setting the only camera left to DO_NOT_COMPUTE_NEAR_FAR,
 but the results are not good (it seems to me that the ClearNodes clear the
 color buffer even when I only set the DEPTH_BUFFER_BIT mask... I really
 don't get it...).

 regards,
 Manu.


 2008/9/23 Emmanuel Roche [EMAIL PROTECTED]

 Hi Robert,

 unfortunately I don't think this an available option in my current
 project: our software is already relying quite heavily on our current
 CompositteViewer / View structure  (a view per window [using wxWidgets], a
 camera manipulator, a single scene graph that should not be cut into pieces,
 etc... and any way, I think there is a real problem here (expect if there is
 still something I missed) so I think for me (in both cases) it's important
 to solve this issue instead of just bypassing it.

 I hope you will find some time to give a deeper look to this thread later
 ;-), meanwhile I'm not giving up: I checked the setSceneData(node) methods
 and it's basically the same just a camera-addChild(node) call... so I may
 have the finger on something [as I expected a noticable difference]. I'll
 keep you informed.

 regards,
 Manu.

 2008/9/23 Robert Osfield [EMAIL PROTECTED]

 Hi Manu,

 I don't have the head for complex emails or logic right now, so I
 won't five into the details of thread.  What does jump out from speed
 reading this email is why you don't use osgViewer::CompositeViewer
 with multipler Views as this would totally clear up an ambiguity about
 what camera each intersection test is made against.

 Robert.

 On Tue, Sep 23, 2008 at 5:42 PM, Emmanuel Roche
 [EMAIL PROTECTED] wrote:
  Hello again...
 
  I did other tests, my idea was:
 
  I have a single main camera displaying a root object [an osg::Group]
 and
  this root object contains 5 or 6 osg::Camera object as direct children.
 And
  those sub cameras contain pieces of the scene I want to display.
 Since (I
  don't know why, but) using an IntersectVisitor gives completely
 incorrect
  result on the main camera in that case, I decided to use my
  intersectionvisitor with each sub camera one by one... in that case
  everything should behave as if each of my sub camera was the root
 object
  when it's

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Some more news:

I reverted to OSG 2.2 (I have the same problems with that version), and
retrieved a full debug support, first I'm trying to solve the latest problem
I faced (with the hidden node described in my previous mail), I'm using a
scene like that:


- Main camera
- Root group
- Hidden group
- Position Attitude Transform
- Geode (with a sphere geometry inside).

- On the main camera I use a cull mask of 0x1
- on the Hidden group I switch between node mask 0x100 [not visible]  and
0x101 [visible]
- And my intersectionVisitor still uses the traversal mask 0x100

I went through all the process step by step (now that I retrieved my debug
support, thanks god :-) !!!), and the conclusion I have for the moment is:

-- This is all a Projection Matrix story 

- In the BAD case (when I hide the hidden group) my proj matrix has a
certain value when I start the call view-computeIntersection(x,y,hits,mask)
and this matrix is used in the push_clone() function in
IntersectionVisitor::apply(osg::Camera) to create a cloned Intersector (and
thus this new LineSegmentIntersector gets an incorrect _start vector and the
call IntersectionVisitor::enter(osg::Node) fails when trying to enter the
Root group, and no intersection is found !).

Now, I tried to put a breakpoint on both
Camera::setProjectionMatrix(osg::Matrixf/d ) as this seems to be the only
entry point to modify a camera projection matrix... But I just CAN'T get
on the point when the good camera projection is *correctly* set !!! is that
done some other way ??? I keep investigating, I have no choice any way...

regards,
Manu.




2008/9/24 Emmanuel Roche [EMAIL PROTECTED]

 :-(... I'm really going to cry now...

 Guys, I tried something else and I feel like I'm loosing my mind:

 Since I cannot pick anything when traversing a sub camera, I tried to build
 my scene this way:
 - the main View camera  (with cull mask set to 0x1)
   - my root group
 - a sub camera (with node mask set to 0x1)
   - a PositionAttitudeTransform (with a scale set)
 - an object
 - An hidden group (with node mask set to 0x100)
   - a link to the SAME previous PositionAttitudeTransform object.

 ... With that I still have a proper display (the default node mask is
 0x): only my sub camera is rendered and the hidden group is not
 visible as expected.

 then for my IntersectionVisitor I obviously use the traversal mask 0x100 :
 this way I was expecting to traverse my main camera and the hidden group,
 but none of the sub camera... and guess what ? It's just not working 
 :-( It works if I don't hide my hidden group (giving it a node mask of
 0x101, but of course this doesn't make sense considering the goal I
 have)... So the IntersectionVisitor traversal also depends on the cull
 mask or something like that ? I could really use some explanations on
 that...

 By the way I'm using OSG 2.6...

 regards,
 Manu.



 2008/9/23 Emmanuel Roche [EMAIL PROTECTED]

 Okay...

  I think I tried everything I could think about, unsuccessfully...
 unfortunately, I'm currently on WinXP with Visual Studio and for some
 obscure reason, I just cannot get/use the debug symbols from some of the OSG
 libraries (maybe beacuse I'm accessing those functions introspectively
 though a Lua release binary ? not sure about all that...) an as a result I
 cannot go deeper into those tests :-(

 But I've just discovered a new fact: this is at least partially linked to
 the scale of my object, I tried the following scene graph:

 - the main View camera
   - my root group
 - a sub camera
   - a PositionAttitudeTransform (with a scale set)
 - an object

 --- then depending on the scale applied in the PositionAttitudeTransform
 I can pick parts of my object or not : the bigger the scale, the closer to
 the object I need to be to get some intersections (and I'm not even sure
 those intersections are correct...). So could there be a scale factor not
 applied somewhere ?? Or maybe, since my main camera renders no objects its
 near/far planes are set to minimal values and then those settings are not
 modified accordingly when going though a sub camera in an
 intersectionVisitor [this could explain why I cannot select objects if I'm
 not very very close to them (and depending on their scale)...] ?

 Is there an other way to render Univers scale + high precision scenes
 without using multiple cameras as children ??? I did a quick test using
 ClearNodes and setting the only camera left to DO_NOT_COMPUTE_NEAR_FAR,
 but the results are not good (it seems to me that the ClearNodes clear the
 color buffer even when I only set the DEPTH_BUFFER_BIT mask... I really
 don't get it...).

 regards,
 Manu.


 2008/9/23 Emmanuel Roche [EMAIL PROTECTED]

 Hi Robert,

 unfortunately I don't think this an available option in my current
 project: our software is already relying quite heavily on our current
 CompositteViewer / View structure  (a view

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Okay, I think I have something here:

I started from my first call on my CompositeViewer::frame()

then we get in renderingTraversals() -- runOperations() [for the Contexts]
-- renderer::cull_draw() --- SceneView::cull() and here we have:

_cullVisitor-setTraversalMask(_cullMask);
bool computeNearFar =
cullStage(getProjectionMatrix(),getViewMatrix(),_cullVisitor.get(),_rendergraph.get(),_renderStage.get());

if (computeNearFar)
{
CullVisitor::value_type zNear =
_cullVisitor-getCalculatedNearPlane();
CullVisitor::value_type zFar =
_cullVisitor-getCalculatedFarPlane();

_cullVisitor-clampProjectionMatrix(getProjectionMatrix(),zNear,zFar);
}

And that's where my latest problem comes from !!! This cull visitor uses the
Cull mask to somehow update the projection matrix... (and sorry, I put
breakpoint on setProjectionMatrix(...) but not on getProjectionMatrix() :-(
I didn't notice the reference this function returns...).

And if I'm lucking this may also explain why everything is messed up when I
use sub cameras: the sub camera graph don't get into this cullstage for the
main camera, do they ? and if not, the main projection gets corrupted the
same way and then since the Root group is not entered, the sub cameras are
not reached any way (or they can be sometimes because of those corrupted
projections) !!! So everything is clear now :-D [I've just made a simple
check with a sub camera instead of an hidden group].

Now that the problem is clarified, the big question is: What's the best
option to achieve the desired behavior (hide a node and still be able to
intersect with it, or use sub cameras) ???

I hope this little monologue may help other people stuck on that issue too
(if any :-) )


regards,
Manu.





2008/9/24 Emmanuel Roche [EMAIL PROTECTED]

 Some more news:

 I reverted to OSG 2.2 (I have the same problems with that version), and
 retrieved a full debug support, first I'm trying to solve the latest problem
 I faced (with the hidden node described in my previous mail), I'm using a
 scene like that:


 - Main camera
 - Root group
 - Hidden group
 - Position Attitude Transform
 - Geode (with a sphere geometry inside).

 - On the main camera I use a cull mask of 0x1
 - on the Hidden group I switch between node mask 0x100 [not visible]  and
 0x101 [visible]
 - And my intersectionVisitor still uses the traversal mask 0x100

 I went through all the process step by step (now that I retrieved my debug
 support, thanks god :-) !!!), and the conclusion I have for the moment is:

 -- This is all a Projection Matrix story 

 - In the BAD case (when I hide the hidden group) my proj matrix has a
 certain value when I start the call view-computeIntersection(x,y,hits,mask)
 and this matrix is used in the push_clone() function in
 IntersectionVisitor::apply(osg::Camera) to create a cloned Intersector (and
 thus this new LineSegmentIntersector gets an incorrect _start vector and the
 call IntersectionVisitor::enter(osg::Node) fails when trying to enter the
 Root group, and no intersection is found !).

 Now, I tried to put a breakpoint on both
 Camera::setProjectionMatrix(osg::Matrixf/d ) as this seems to be the only
 entry point to modify a camera projection matrix... But I just CAN'T get
 on the point when the good camera projection is *correctly* set !!! is
 that done some other way ??? I keep investigating, I have no choice any
 way...

 regards,
 Manu.




 2008/9/24 Emmanuel Roche [EMAIL PROTECTED]

 :-(... I'm really going to cry now...

 Guys, I tried something else and I feel like I'm loosing my mind:

 Since I cannot pick anything when traversing a sub camera, I tried to
 build my scene this way:
 - the main View camera  (with cull mask set to 0x1)
   - my root group
 - a sub camera (with node mask set to 0x1)
   - a PositionAttitudeTransform (with a scale set)
 - an object
 - An hidden group (with node mask set to 0x100)
   - a link to the SAME previous PositionAttitudeTransform object.

 ... With that I still have a proper display (the default node mask is
 0x): only my sub camera is rendered and the hidden group is not
 visible as expected.

 then for my IntersectionVisitor I obviously use the traversal mask 0x100 :
 this way I was expecting to traverse my main camera and the hidden group,
 but none of the sub camera... and guess what ? It's just not working 
 :-( It works if I don't hide my hidden group (giving it a node mask of
 0x101, but of course this doesn't make sense considering the goal I
 have)... So the IntersectionVisitor traversal also depends on the cull
 mask or something like that ? I could really use some explanations on
 that...

 By the way I'm using OSG 2.6...

 regards,
 Manu.



 2008/9/23 Emmanuel Roche [EMAIL PROTECTED]

 Okay...

  I think I tried everything I could think about, unsuccessfully...
 unfortunately, I'm currently on WinXP

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

 osg::RefMatrix(camera.getViewMatrix()) );
pushModelMatrix( new osg::RefMatrix() );

// now push an new intersector clone transform to the new local
coordinates
push_clone();

traverse(camera);

// pop the clone.
pop_clone();

popModelMatrix();
popViewMatrix();
popProjectionMatrix();
if (camera.getViewport()) popWindowMatrix();
  // Bouml preserved body end 00043C84
}

... I'm not sure we need to setup the CullVisitor so much : but I just took
most of the implementation from SceneView::cullstate(...) and it's working
like that... and as I said, I'm in an hurry now :-)

regards,
Manu.



2008/9/23 Emmanuel Roche [EMAIL PROTECTED]

 Hi everyone,

 I have an interesting issue here:

 I'm building a scene this way (the following is a lua script using
 osgIntrospection to manipulate OSG stuff) :

 local root = osg.Group()
 root:setName(Universe)

 -- we want to add this root object as a scene in the current project
 (otherwise it will never be found)
 -- this root object will be assigned as the scenedata for the master
 camera.
 local proj = vProj.ProjectManager.instance():getCurrent()
 proj:add_Scene(root)

 local view = vDisplay.DisplayManager.getViewer():getView(0)  -- here,
 getViewer() returns our osgViewer::CompositeViewer object
 local manip =
 reflection.cast(view:getCameraManipulator(),vGA::ArcBallManipulator)

 -- now create the LTS project:
 require('LTS')

 local cam = view:getCamera()  -- this is the main camera, the scene data
 for this camera is the previously declared root object
 local subcam = osg.Camera()  -- we create a sub camera than we will add to
 the main scene (so an inderect child for the main camera...)
 subcam:setGraphicsContext(cam:getGraphicsContext())
 subcam:setViewport(cam:getViewport())
 subcam:setRenderOrder(osg.Camera.RenderOrder.POST_RENDER,3) -- We post
 render this subcamera with an arbitrary order.
 subcam:setClearMask(GL.Mode.GL_DEPTH_BUFFER_BIT) -- We want to render
 Universe scale scenes that's why we introduced this multi pass system.
 root:addChild(subcam)

 local st = vOGL.SceneTools;
 local pat = osg.PositionAttitudeTransform()
 pat:addChild(LTS.createDoubleCraft(K1)) -- Here we create a satellit
 object
 subcam:addChild(pat) -- And we add the object to the sub camera...


 ... this scene is rendered perfectly... but now I'm trying to pick items
 in the scene using the implementation found in
 osgViewer::View::computeIntersections(...) : If I put my K1 object
 directly in the main camera everything is perfect, and I can pick
 intersections correctly. But when using this subcam  as parent then I get
 incorrect results :-( (intersections found when clicking on nothing, or no
 intersections found when cliking on sub parts of the object...)

 I gave a look at the osgUtil::IntersectionVisitor implementation... and I
 think everything is happening in this function:

 void IntersectionVisitor::apply(osg::Camera camera)
 {
 // osg::notify(osg::NOTICE)apply(Camera)std::endl;

 // note, commenting out right now because default Camera setup is with
 the culling active.  Should this be changed?
 // if (!enter(camera)) return;

 // osg::notify(osg::NOTICE)inside apply(Camera)std::endl;

 if (camera.getViewport()) pushWindowMatrix( camera.getViewport() );
 pushProjectionMatrix( new osg::RefMatrix(camera.getProjectionMatrix())
 );
 pushViewMatrix( new osg::RefMatrix(camera.getViewMatrix()) );
 pushModelMatrix( new osg::RefMatrix() );

 // now push an new intersector clone transform to the new local
 coordinates
 push_clone();

 traverse(camera);

 // pop the clone.
 pop_clone();

 popModelMatrix();
 popViewMatrix();
 popProjectionMatrix();
 if (camera.getViewport()) popWindowMatrix();

 // leave();
 }

 I created my own ExtendedIntersectorVisitor (derived from this class) to
 override this function and I made multiple tests to handle the main camera
 and the sub cameras differently:

 void ExtendedIntersectionVisitor::apply(osg::Camera  camera) {
 if(!cameraInitialized) {
 cameraInitialized = true;
 // The first time we get a camera object we use it to setup the
 camera details normaly:

 if (camera.getViewport()) pushWindowMatrix( camera.getViewport() );
 pushProjectionMatrix( new
 osg::RefMatrix(camera.getProjectionMatrix()) );
 pushViewMatrix( new osg::RefMatrix(camera.getViewMatrix()) );
 pushModelMatrix( new osg::RefMatrix() );

 // now push an new intersector clone transform to the new local
 coordinates
 push_clone();

 traverse(camera);

 // pop the clone.
 pop_clone();

 popModelMatrix();
 popViewMatrix();
 popProjectionMatrix();
 if (camera.getViewport()) popWindowMatrix();
 }
 else {
 // here I did multiple tests (one by one):

 // Test 1: treat the camera as a transform  (took implementation
 from

[osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Hi everyone,

I have an interesting issue here:

I'm building a scene this way (the following is a lua script using
osgIntrospection to manipulate OSG stuff) :

local root = osg.Group()
root:setName(Universe)

-- we want to add this root object as a scene in the current project
(otherwise it will never be found)
-- this root object will be assigned as the scenedata for the master camera.
local proj = vProj.ProjectManager.instance():getCurrent()
proj:add_Scene(root)

local view = vDisplay.DisplayManager.getViewer():getView(0)  -- here,
getViewer() returns our osgViewer::CompositeViewer object
local manip =
reflection.cast(view:getCameraManipulator(),vGA::ArcBallManipulator)

-- now create the LTS project:
require('LTS')

local cam = view:getCamera()  -- this is the main camera, the scene data
for this camera is the previously declared root object
local subcam = osg.Camera()  -- we create a sub camera than we will add to
the main scene (so an inderect child for the main camera...)
subcam:setGraphicsContext(cam:getGraphicsContext())
subcam:setViewport(cam:getViewport())
subcam:setRenderOrder(osg.Camera.RenderOrder.POST_RENDER,3) -- We post
render this subcamera with an arbitrary order.
subcam:setClearMask(GL.Mode.GL_DEPTH_BUFFER_BIT) -- We want to render
Universe scale scenes that's why we introduced this multi pass system.
root:addChild(subcam)

local st = vOGL.SceneTools;
local pat = osg.PositionAttitudeTransform()
pat:addChild(LTS.createDoubleCraft(K1)) -- Here we create a satellit
object
subcam:addChild(pat) -- And we add the object to the sub camera...


... this scene is rendered perfectly... but now I'm trying to pick items
in the scene using the implementation found in
osgViewer::View::computeIntersections(...) : If I put my K1 object
directly in the main camera everything is perfect, and I can pick
intersections correctly. But when using this subcam  as parent then I get
incorrect results :-( (intersections found when clicking on nothing, or no
intersections found when cliking on sub parts of the object...)

I gave a look at the osgUtil::IntersectionVisitor implementation... and I
think everything is happening in this function:

void IntersectionVisitor::apply(osg::Camera camera)
{
// osg::notify(osg::NOTICE)apply(Camera)std::endl;

// note, commenting out right now because default Camera setup is with
the culling active.  Should this be changed?
// if (!enter(camera)) return;

// osg::notify(osg::NOTICE)inside apply(Camera)std::endl;

if (camera.getViewport()) pushWindowMatrix( camera.getViewport() );
pushProjectionMatrix( new osg::RefMatrix(camera.getProjectionMatrix())
);
pushViewMatrix( new osg::RefMatrix(camera.getViewMatrix()) );
pushModelMatrix( new osg::RefMatrix() );

// now push an new intersector clone transform to the new local
coordinates
push_clone();

traverse(camera);

// pop the clone.
pop_clone();

popModelMatrix();
popViewMatrix();
popProjectionMatrix();
if (camera.getViewport()) popWindowMatrix();

// leave();
}

I created my own ExtendedIntersectorVisitor (derived from this class) to
override this function and I made multiple tests to handle the main camera
and the sub cameras differently:

void ExtendedIntersectionVisitor::apply(osg::Camera  camera) {
if(!cameraInitialized) {
cameraInitialized = true;
// The first time we get a camera object we use it to setup the
camera details normaly:

if (camera.getViewport()) pushWindowMatrix( camera.getViewport() );
pushProjectionMatrix( new
osg::RefMatrix(camera.getProjectionMatrix()) );
pushViewMatrix( new osg::RefMatrix(camera.getViewMatrix()) );
pushModelMatrix( new osg::RefMatrix() );

// now push an new intersector clone transform to the new local
coordinates
push_clone();

traverse(camera);

// pop the clone.
pop_clone();

popModelMatrix();
popViewMatrix();
popProjectionMatrix();
if (camera.getViewport()) popWindowMatrix();
}
else {
// here I did multiple tests (one by one):

// Test 1: treat the camera as a transform  (took implementation
from IntersectionVisitor::apply(osg::Transform) )
if (!enter(*(camera.asTransform( return;

osg::ref_ptrosg::RefMatrix matrix = _modelStack.empty() ? new
osg::RefMatrix() : new osg::RefMatrix(*_modelStack.back());
camera.computeLocalToWorldMatrix(*matrix,this);

pushModelMatrix(matrix.get());

// now push an new intersector clone transform to the new local
coordinates
push_clone();

traverse(camera);

// pop the clone.
pop_clone();

popModelMatrix();

// tidy up an cached cull variables in the current intersector.
leave();
   // End of Test 1

   // Test 2: treat the camera as a osg::Group only!
if (!enter(*(camera.asGroup( return;

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Okay, more information on this issue I mentioned:

I tested a scene where I have only two satellites (not too far away, the
same size) in two different sub camera (still under the main camera): in
that case, using the Test 2 implementation [treating the camera as a
simple Group] gives correct picking results.

So now, I think the second part of the problem I have in my normal scene
is due to the scale difference between the objects: in the main camera, I
have a subcamera containing an Earth model (radius ~= 6371 units, since I
use km as unit) and in an other subcamera I have my satellite (typical size
~= 0.001 units as the satellite has a small size in meters...)

using the subcam:setClearMask(GL.Mode.GL_DEPTH_BUFFER_BIT) statement is
enough to display everything correctly even with those geant scale
differences [actually I also have a Sun object in an other subcamera with
real size (695 500 units :-( ), and real distance from the earth (150 000
000 units !!! ) :-S ]... maybe this can lead to an overflow of the precision
when performing the intersection tests ??? do those tests use floats or
doubles ?

regards,

Manu.



2008/9/23 Emmanuel Roche [EMAIL PROTECTED]

 Hi everyone,

 I have an interesting issue here:

 I'm building a scene this way (the following is a lua script using
 osgIntrospection to manipulate OSG stuff) :

 local root = osg.Group()
 root:setName(Universe)

 -- we want to add this root object as a scene in the current project
 (otherwise it will never be found)
 -- this root object will be assigned as the scenedata for the master
 camera.
 local proj = vProj.ProjectManager.instance():getCurrent()
 proj:add_Scene(root)

 local view = vDisplay.DisplayManager.getViewer():getView(0)  -- here,
 getViewer() returns our osgViewer::CompositeViewer object
 local manip =
 reflection.cast(view:getCameraManipulator(),vGA::ArcBallManipulator)

 -- now create the LTS project:
 require('LTS')

 local cam = view:getCamera()  -- this is the main camera, the scene data
 for this camera is the previously declared root object
 local subcam = osg.Camera()  -- we create a sub camera than we will add to
 the main scene (so an inderect child for the main camera...)
 subcam:setGraphicsContext(cam:getGraphicsContext())
 subcam:setViewport(cam:getViewport())
 subcam:setRenderOrder(osg.Camera.RenderOrder.POST_RENDER,3) -- We post
 render this subcamera with an arbitrary order.
 subcam:setClearMask(GL.Mode.GL_DEPTH_BUFFER_BIT) -- We want to render
 Universe scale scenes that's why we introduced this multi pass system.
 root:addChild(subcam)

 local st = vOGL.SceneTools;
 local pat = osg.PositionAttitudeTransform()
 pat:addChild(LTS.createDoubleCraft(K1)) -- Here we create a satellit
 object
 subcam:addChild(pat) -- And we add the object to the sub camera...


 ... this scene is rendered perfectly... but now I'm trying to pick items
 in the scene using the implementation found in
 osgViewer::View::computeIntersections(...) : If I put my K1 object
 directly in the main camera everything is perfect, and I can pick
 intersections correctly. But when using this subcam  as parent then I get
 incorrect results :-( (intersections found when clicking on nothing, or no
 intersections found when cliking on sub parts of the object...)

 I gave a look at the osgUtil::IntersectionVisitor implementation... and I
 think everything is happening in this function:

 void IntersectionVisitor::apply(osg::Camera camera)
 {
 // osg::notify(osg::NOTICE)apply(Camera)std::endl;

 // note, commenting out right now because default Camera setup is with
 the culling active.  Should this be changed?
 // if (!enter(camera)) return;

 // osg::notify(osg::NOTICE)inside apply(Camera)std::endl;

 if (camera.getViewport()) pushWindowMatrix( camera.getViewport() );
 pushProjectionMatrix( new osg::RefMatrix(camera.getProjectionMatrix())
 );
 pushViewMatrix( new osg::RefMatrix(camera.getViewMatrix()) );
 pushModelMatrix( new osg::RefMatrix() );

 // now push an new intersector clone transform to the new local
 coordinates
 push_clone();

 traverse(camera);

 // pop the clone.
 pop_clone();

 popModelMatrix();
 popViewMatrix();
 popProjectionMatrix();
 if (camera.getViewport()) popWindowMatrix();

 // leave();
 }

 I created my own ExtendedIntersectorVisitor (derived from this class) to
 override this function and I made multiple tests to handle the main camera
 and the sub cameras differently:

 void ExtendedIntersectionVisitor::apply(osg::Camera  camera) {
 if(!cameraInitialized) {
 cameraInitialized = true;
 // The first time we get a camera object we use it to setup the
 camera details normaly:

 if (camera.getViewport()) pushWindowMatrix( camera.getViewport() );
 pushProjectionMatrix( new
 osg::RefMatrix(camera.getProjectionMatrix()) );
 pushViewMatrix( new osg::RefMatrix(camera.getViewMatrix()) );
 pushModelMatrix( new osg

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Hello again...

I did other tests, my idea was:

I have a single main camera displaying a root object [an osg::Group] and
this root object contains 5 or 6 osg::Camera object as direct children. And
those sub cameras contain pieces of the scene I want to display. Since (I
don't know why, but) using an IntersectVisitor gives completely incorrect
result on the main camera in that case, I decided to use my
intersectionvisitor with each sub camera one by one... in that case
everything should behave as if each of my sub camera was the root object
when it's traversed, no ?... but the answer is: NO... :-( this case doesn't
seem to be the same as using a single camera containing objects as the
intersection results are still completely false

So my big question is now : what's the difference (from a camera point of
view when it comes to intersections) between view-setSceneData(node) and
camera-addChild(node) ??? I keep investigating... :-) but any shortcut
would really be appreciated :-).

regards,
Manu.

PS: here is the main part of the code concerning the previous idea I
mentioned if someone wants to have a look...

osg::Camera* cam = view-getCamera();
osg::Matrixd vm;
osg::Matrixd pm;
osg::ref_ptrosg::Viewport vp;

osgUtil::LineSegmentIntersector::Intersections hits;

vDisplay::DisplayManager::CameraDeq cams =
vDisplay::DisplayManager::getRegisteredCameras(view);
for(vDisplay::DisplayManager::CameraDeq::iterator it = cams.begin(); it
!= cams.end(); ++it) {

osgUtil::LineSegmentIntersector::CoordinateFrame cf =
osgUtil::Intersector::PROJECTION; //(*it)-getViewport() ?
osgUtil::Intersector::WINDOW : osgUtil::Intersector::PROJECTION;
osg::ref_ptr osgUtil::LineSegmentIntersector  picker = new
osgUtil::LineSegmentIntersector(cf, x, y);

//osgUtil::IntersectionVisitor iv(picker.get());
vOGL::ExtendedIntersectionVisitor iv(picker.get());
iv.setTraversalMask(0x);

// Reconfigure the camera:
vm = (*it)-getViewMatrix();  // these are actually identity
matrices as only the main camera is manipulated
pm = (*it)-getProjectionMatrix();
vp = (*it)-getViewport();

(*it)-setViewMatrix(cam-getViewMatrix());
(*it)-setProjectionMatrix(cam-getProjectionMatrix());
(*it)-setViewport(cam-getViewport());

if ((*it)-getViewport()) iv.pushWindowMatrix( (*it)-getViewport()
);
iv.pushProjectionMatrix( new
osg::RefMatrix((*it)-getProjectionMatrix()) );
iv.pushViewMatrix( new osg::RefMatrix((*it)-getViewMatrix()) );
iv.pushModelMatrix( new osg::RefMatrix() );

(*it)-accept(iv);

iv.popModelMatrix();
iv.popViewMatrix();
iv.popProjectionMatrix();
if ((*it)-getViewport()) iv.popWindowMatrix();

(*it)-setViewMatrix(vm);
(*it)-setProjectionMatrix(pm);
(*it)-setViewport(vp.get());

if (picker-containsIntersections())
{
hits = picker-getIntersections();
vLog::logInfo(Got %d intersections,hits.size());
return true;
}
}




2008/9/23 Emmanuel Roche [EMAIL PROTECTED]

 Hi everyone,

 I have an interesting issue here:

 I'm building a scene this way (the following is a lua script using
 osgIntrospection to manipulate OSG stuff) :

 local root = osg.Group()
 root:setName(Universe)

 -- we want to add this root object as a scene in the current project
 (otherwise it will never be found)
 -- this root object will be assigned as the scenedata for the master
 camera.
 local proj = vProj.ProjectManager.instance():getCurrent()
 proj:add_Scene(root)

 local view = vDisplay.DisplayManager.getViewer():getView(0)  -- here,
 getViewer() returns our osgViewer::CompositeViewer object
 local manip =
 reflection.cast(view:getCameraManipulator(),vGA::ArcBallManipulator)

 -- now create the LTS project:
 require('LTS')

 local cam = view:getCamera()  -- this is the main camera, the scene data
 for this camera is the previously declared root object
 local subcam = osg.Camera()  -- we create a sub camera than we will add to
 the main scene (so an inderect child for the main camera...)
 subcam:setGraphicsContext(cam:getGraphicsContext())
 subcam:setViewport(cam:getViewport())
 subcam:setRenderOrder(osg.Camera.RenderOrder.POST_RENDER,3) -- We post
 render this subcamera with an arbitrary order.
 subcam:setClearMask(GL.Mode.GL_DEPTH_BUFFER_BIT) -- We want to render
 Universe scale scenes that's why we introduced this multi pass system.
 root:addChild(subcam)

 local st = vOGL.SceneTools;
 local pat = osg.PositionAttitudeTransform()
 pat:addChild(LTS.createDoubleCraft(K1)) -- Here we create a satellit
 object
 subcam:addChild(pat) -- And we add the object to the sub camera...


 ... this scene is rendered perfectly... but now I'm trying to pick items
 in the scene using the implementation found in
 osgViewer::View::computeIntersections(...) : If I put my K1 object
 directly in the main

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Hi Robert,

unfortunately I don't think this an available option in my current project:
our software is already relying quite heavily on our current
CompositteViewer / View structure  (a view per window [using wxWidgets], a
camera manipulator, a single scene graph that should not be cut into pieces,
etc... and any way, I think there is a real problem here (expect if there is
still something I missed) so I think for me (in both cases) it's important
to solve this issue instead of just bypassing it.

I hope you will find some time to give a deeper look to this thread later
;-), meanwhile I'm not giving up: I checked the setSceneData(node) methods
and it's basically the same just a camera-addChild(node) call... so I may
have the finger on something [as I expected a noticable difference]. I'll
keep you informed.

regards,
Manu.

2008/9/23 Robert Osfield [EMAIL PROTECTED]

 Hi Manu,

 I don't have the head for complex emails or logic right now, so I
 won't five into the details of thread.  What does jump out from speed
 reading this email is why you don't use osgViewer::CompositeViewer
 with multipler Views as this would totally clear up an ambiguity about
 what camera each intersection test is made against.

 Robert.

 On Tue, Sep 23, 2008 at 5:42 PM, Emmanuel Roche
 [EMAIL PROTECTED] wrote:
  Hello again...
 
  I did other tests, my idea was:
 
  I have a single main camera displaying a root object [an osg::Group] and
  this root object contains 5 or 6 osg::Camera object as direct children.
 And
  those sub cameras contain pieces of the scene I want to display. Since
 (I
  don't know why, but) using an IntersectVisitor gives completely incorrect
  result on the main camera in that case, I decided to use my
  intersectionvisitor with each sub camera one by one... in that case
  everything should behave as if each of my sub camera was the root object
  when it's traversed, no ?... but the answer is: NO... :-( this case
 doesn't
  seem to be the same as using a single camera containing objects as the
  intersection results are still completely false
 
  So my big question is now : what's the difference (from a camera point
 of
  view when it comes to intersections) between view-setSceneData(node)
 and
  camera-addChild(node) ??? I keep investigating... :-) but any shortcut
  would really be appreciated :-).
 
  regards,
  Manu.
 
  PS: here is the main part of the code concerning the previous idea I
  mentioned if someone wants to have a look...
 
  osg::Camera* cam = view-getCamera();
  osg::Matrixd vm;
  osg::Matrixd pm;
  osg::ref_ptrosg::Viewport vp;
 
  osgUtil::LineSegmentIntersector::Intersections hits;
 
  vDisplay::DisplayManager::CameraDeq cams =
  vDisplay::DisplayManager::getRegisteredCameras(view);
  for(vDisplay::DisplayManager::CameraDeq::iterator it = cams.begin();
 it
  != cams.end(); ++it) {
 
  osgUtil::LineSegmentIntersector::CoordinateFrame cf =
  osgUtil::Intersector::PROJECTION; //(*it)-getViewport() ?
  osgUtil::Intersector::WINDOW : osgUtil::Intersector::PROJECTION;
  osg::ref_ptr osgUtil::LineSegmentIntersector  picker = new
  osgUtil::LineSegmentIntersector(cf, x, y);
 
  //osgUtil::IntersectionVisitor iv(picker.get());
  vOGL::ExtendedIntersectionVisitor iv(picker.get());
  iv.setTraversalMask(0x);
 
  // Reconfigure the camera:
  vm = (*it)-getViewMatrix();  // these are actually identity
  matrices as only the main camera is manipulated
  pm = (*it)-getProjectionMatrix();
  vp = (*it)-getViewport();
 
  (*it)-setViewMatrix(cam-getViewMatrix());
  (*it)-setProjectionMatrix(cam-getProjectionMatrix());
  (*it)-setViewport(cam-getViewport());
 
  if ((*it)-getViewport()) iv.pushWindowMatrix(
 (*it)-getViewport()
  );
  iv.pushProjectionMatrix( new
  osg::RefMatrix((*it)-getProjectionMatrix()) );
  iv.pushViewMatrix( new osg::RefMatrix((*it)-getViewMatrix()) );
  iv.pushModelMatrix( new osg::RefMatrix() );
 
  (*it)-accept(iv);
 
  iv.popModelMatrix();
  iv.popViewMatrix();
  iv.popProjectionMatrix();
  if ((*it)-getViewport()) iv.popWindowMatrix();
 
  (*it)-setViewMatrix(vm);
  (*it)-setProjectionMatrix(pm);
  (*it)-setViewport(vp.get());
 
  if (picker-containsIntersections())
  {
  hits = picker-getIntersections();
  vLog::logInfo(Got %d intersections,hits.size());
  return true;
  }
  }
 
 
 
 
  2008/9/23 Emmanuel Roche [EMAIL PROTECTED]
 
  Hi everyone,
 
  I have an interesting issue here:
 
  I'm building a scene this way (the following is a lua script using
  osgIntrospection to manipulate OSG stuff) :
 
  local root = osg.Group()
  root:setName(Universe)
 
  -- we want to add this root object as a scene in the current project
  (otherwise it will never be found)
  -- this root object

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Okay...

 I think I tried everything I could think about, unsuccessfully...
unfortunately, I'm currently on WinXP with Visual Studio and for some
obscure reason, I just cannot get/use the debug symbols from some of the OSG
libraries (maybe beacuse I'm accessing those functions introspectively
though a Lua release binary ? not sure about all that...) an as a result I
cannot go deeper into those tests :-(

But I've just discovered a new fact: this is at least partially linked to
the scale of my object, I tried the following scene graph:

- the main View camera
  - my root group
- a sub camera
  - a PositionAttitudeTransform (with a scale set)
- an object

--- then depending on the scale applied in the PositionAttitudeTransform I
can pick parts of my object or not : the bigger the scale, the closer to the
object I need to be to get some intersections (and I'm not even sure those
intersections are correct...). So could there be a scale factor not applied
somewhere ?? Or maybe, since my main camera renders no objects its near/far
planes are set to minimal values and then those settings are not modified
accordingly when going though a sub camera in an intersectionVisitor [this
could explain why I cannot select objects if I'm not very very close to them
(and depending on their scale)...] ?

Is there an other way to render Univers scale + high precision scenes
without using multiple cameras as children ??? I did a quick test using
ClearNodes and setting the only camera left to DO_NOT_COMPUTE_NEAR_FAR,
but the results are not good (it seems to me that the ClearNodes clear the
color buffer even when I only set the DEPTH_BUFFER_BIT mask... I really
don't get it...).

regards,
Manu.


2008/9/23 Emmanuel Roche [EMAIL PROTECTED]

 Hi Robert,

 unfortunately I don't think this an available option in my current project:
 our software is already relying quite heavily on our current
 CompositteViewer / View structure  (a view per window [using wxWidgets], a
 camera manipulator, a single scene graph that should not be cut into pieces,
 etc... and any way, I think there is a real problem here (expect if there is
 still something I missed) so I think for me (in both cases) it's important
 to solve this issue instead of just bypassing it.

 I hope you will find some time to give a deeper look to this thread later
 ;-), meanwhile I'm not giving up: I checked the setSceneData(node) methods
 and it's basically the same just a camera-addChild(node) call... so I may
 have the finger on something [as I expected a noticable difference]. I'll
 keep you informed.

 regards,
 Manu.

 2008/9/23 Robert Osfield [EMAIL PROTECTED]

 Hi Manu,

 I don't have the head for complex emails or logic right now, so I
 won't five into the details of thread.  What does jump out from speed
 reading this email is why you don't use osgViewer::CompositeViewer
 with multipler Views as this would totally clear up an ambiguity about
 what camera each intersection test is made against.

 Robert.

 On Tue, Sep 23, 2008 at 5:42 PM, Emmanuel Roche
 [EMAIL PROTECTED] wrote:
  Hello again...
 
  I did other tests, my idea was:
 
  I have a single main camera displaying a root object [an osg::Group] and
  this root object contains 5 or 6 osg::Camera object as direct children.
 And
  those sub cameras contain pieces of the scene I want to display. Since
 (I
  don't know why, but) using an IntersectVisitor gives completely
 incorrect
  result on the main camera in that case, I decided to use my
  intersectionvisitor with each sub camera one by one... in that case
  everything should behave as if each of my sub camera was the root object
  when it's traversed, no ?... but the answer is: NO... :-( this case
 doesn't
  seem to be the same as using a single camera containing objects as the
  intersection results are still completely false
 
  So my big question is now : what's the difference (from a camera point
 of
  view when it comes to intersections) between view-setSceneData(node)
 and
  camera-addChild(node) ??? I keep investigating... :-) but any shortcut
  would really be appreciated :-).
 
  regards,
  Manu.
 
  PS: here is the main part of the code concerning the previous idea I
  mentioned if someone wants to have a look...
 
  osg::Camera* cam = view-getCamera();
  osg::Matrixd vm;
  osg::Matrixd pm;
  osg::ref_ptrosg::Viewport vp;
 
  osgUtil::LineSegmentIntersector::Intersections hits;
 
  vDisplay::DisplayManager::CameraDeq cams =
  vDisplay::DisplayManager::getRegisteredCameras(view);
  for(vDisplay::DisplayManager::CameraDeq::iterator it = cams.begin();
 it
  != cams.end(); ++it) {
 
  osgUtil::LineSegmentIntersector::CoordinateFrame cf =
  osgUtil::Intersector::PROJECTION; //(*it)-getViewport() ?
  osgUtil::Intersector::WINDOW : osgUtil::Intersector::PROJECTION;
  osg::ref_ptr osgUtil::LineSegmentIntersector  picker = new
  osgUtil::LineSegmentIntersector(cf, x, y);
 
  //osgUtil

Re: [osg-users] multi camera rendering and pick issues

[Emmanuel Roche]

Oh, and by the way, the results seem to be exactly the same when I use the
osgUtil::IntersectVisitor instead of the new version... so, someone has a
clue ?

regards,
Manu.


2008/9/23 Emmanuel Roche [EMAIL PROTECTED]

 Okay...

  I think I tried everything I could think about, unsuccessfully...
 unfortunately, I'm currently on WinXP with Visual Studio and for some
 obscure reason, I just cannot get/use the debug symbols from some of the OSG
 libraries (maybe beacuse I'm accessing those functions introspectively
 though a Lua release binary ? not sure about all that...) an as a result I
 cannot go deeper into those tests :-(

 But I've just discovered a new fact: this is at least partially linked to
 the scale of my object, I tried the following scene graph:

 - the main View camera
   - my root group
 - a sub camera
   - a PositionAttitudeTransform (with a scale set)
 - an object

 --- then depending on the scale applied in the PositionAttitudeTransform I
 can pick parts of my object or not : the bigger the scale, the closer to the
 object I need to be to get some intersections (and I'm not even sure those
 intersections are correct...). So could there be a scale factor not applied
 somewhere ?? Or maybe, since my main camera renders no objects its near/far
 planes are set to minimal values and then those settings are not modified
 accordingly when going though a sub camera in an intersectionVisitor [this
 could explain why I cannot select objects if I'm not very very close to them
 (and depending on their scale)...] ?

 Is there an other way to render Univers scale + high precision scenes
 without using multiple cameras as children ??? I did a quick test using
 ClearNodes and setting the only camera left to DO_NOT_COMPUTE_NEAR_FAR,
 but the results are not good (it seems to me that the ClearNodes clear the
 color buffer even when I only set the DEPTH_BUFFER_BIT mask... I really
 don't get it...).

 regards,
 Manu.


 2008/9/23 Emmanuel Roche [EMAIL PROTECTED]

 Hi Robert,

 unfortunately I don't think this an available option in my current
 project: our software is already relying quite heavily on our current
 CompositteViewer / View structure  (a view per window [using wxWidgets], a
 camera manipulator, a single scene graph that should not be cut into pieces,
 etc... and any way, I think there is a real problem here (expect if there is
 still something I missed) so I think for me (in both cases) it's important
 to solve this issue instead of just bypassing it.

 I hope you will find some time to give a deeper look to this thread later
 ;-), meanwhile I'm not giving up: I checked the setSceneData(node) methods
 and it's basically the same just a camera-addChild(node) call... so I may
 have the finger on something [as I expected a noticable difference]. I'll
 keep you informed.

 regards,
 Manu.

 2008/9/23 Robert Osfield [EMAIL PROTECTED]

 Hi Manu,

 I don't have the head for complex emails or logic right now, so I
 won't five into the details of thread.  What does jump out from speed
 reading this email is why you don't use osgViewer::CompositeViewer
 with multipler Views as this would totally clear up an ambiguity about
 what camera each intersection test is made against.

 Robert.

 On Tue, Sep 23, 2008 at 5:42 PM, Emmanuel Roche
 [EMAIL PROTECTED] wrote:
  Hello again...
 
  I did other tests, my idea was:
 
  I have a single main camera displaying a root object [an osg::Group]
 and
  this root object contains 5 or 6 osg::Camera object as direct children.
 And
  those sub cameras contain pieces of the scene I want to display.
 Since (I
  don't know why, but) using an IntersectVisitor gives completely
 incorrect
  result on the main camera in that case, I decided to use my
  intersectionvisitor with each sub camera one by one... in that case
  everything should behave as if each of my sub camera was the root
 object
  when it's traversed, no ?... but the answer is: NO... :-( this case
 doesn't
  seem to be the same as using a single camera containing objects as the
  intersection results are still completely false
 
  So my big question is now : what's the difference (from a camera point
 of
  view when it comes to intersections) between view-setSceneData(node)
 and
  camera-addChild(node) ??? I keep investigating... :-) but any shortcut
  would really be appreciated :-).
 
  regards,
  Manu.
 
  PS: here is the main part of the code concerning the previous idea I
  mentioned if someone wants to have a look...
 
  osg::Camera* cam = view-getCamera();
  osg::Matrixd vm;
  osg::Matrixd pm;
  osg::ref_ptrosg::Viewport vp;
 
  osgUtil::LineSegmentIntersector::Intersections hits;
 
  vDisplay::DisplayManager::CameraDeq cams =
  vDisplay::DisplayManager::getRegisteredCameras(view);
  for(vDisplay::DisplayManager::CameraDeq::iterator it =
 cams.begin(); it
  != cams.end(); ++it) {
 
  osgUtil::LineSegmentIntersector::CoordinateFrame cf =
  osgUtil

[osg-users] Strange TriangleIntersect error

[Emmanuel Roche]

Hi everyone,

I've got a quite strange error here:

when I'm doing collision tests (using an osgUtil::IntersectVisitor object)
then I get the warning:

Warning: Picked up error in TriangleIntersect
  (-1 0 -1,  -1 0 1,  1 0 1 )
  (nan,  nan, nan)


I checked the code in InterectVisitor.cpp, and I real don't get how there
can be an error here... the strange think is, this error seems to only
happen when the start point of my segment ( saved in the _s variable in
the TriangleIntersect object apparently) is only on the Y axis... (ie:
something like (0.0, 673.328, 0.0 ). Could this be a known bug or do you
think I missed something ?

By the way, I'm still using OSG 2.2, and this error happens the same way on
both Windows and linux versions of my program. Any idea ?

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

Re: [osg-users] Test www.osgChina.org . Normal?

[Emmanuel Roche]

I'm in France, it doesn't work at all for me.

2008/2/12, [EMAIL PROTECTED] [EMAIL PROTECTED]:

 FreeSouth wrote:
 
  Hello all :
 Somebody found that He(at Singapore) cann't visit 
  www.osgChina.org(located HangZhou China.
 I don't know this site can be visited normally or not at other
 country. Thanks All.
  Yang ShiXing

 very slow but it works from europe

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


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

[osg-users] debug build of plugins and wrappers on linux

[Emmanuel Roche]

Hi everyone,

I tryed a debug built of OSG 2.2.0 on linux (gcc4 + cmake)

everything is already, no compilation issues, but still I end up with main
libraries correctly named (ie with the final d standing for debug)
whereas the plugins and wrappers don't have that final d... Is it normal ?
if yes, well, why ? and if not, what did I miss in the configuration ?

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

[osg-users] false memory leaks positive en winXP in replace_if_defined section in osgIntrospection::Refelction::getOrRegisterType()

[Emmanuel Roche]

Hi guys !!

I have a problem with  the replace_if_defined section in the following
introspection code :

74http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L74
Type
**Reflection::getOrRegisterType*(*const* std::type_info ti,
*bool*replace_if_defined)
75http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L75
{ 
76http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L76
  TypeMap tm = getOrCreateStaticData().typemap;
77http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L77
  *TypeMap*::iterator i = tm.find(ti);
78http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L78
79http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L79
  *if* (i != tm.end())
80http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L80
  { 
81http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L81
  *if* (replace_if_defined  i-second-isDefined())
82http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L82
  {
83http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L83
  *std*::string old_name = i-second-getName();
84http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L84
  *std*::string old_namespace =
i-second-getNamespace();
85http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L85
  *std*::vectorstd::string old_aliases =
i-second-aliases_;
86http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L86
87http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L87
  Type *newtype = *new* (i-second) Type(ti);
88http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L88
  newtype-name_ = old_name;
89http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L89
  newtype-namespace_ = old_namespace;
90http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L90
  newtype-aliases_.swap(old_aliases);
91http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L91
92http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L92
  *return* newtype;
93http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L93
  }
94http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L94
  *return* i-second;
95http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L95
  } 
96http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L96
97http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L97
  *return* registerType(ti);
98http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgIntrospection/Reflection.cpp?rev=3966#L98
}
In fact I've noticed that on windows, both Visual Studio 7.1 SP1 and AQTime
5 don't handle the new (address) Object syntax correctly : they seem to
bilieve that the newly created objects all need to be deleted... and that
create a lot of false positive memory leaks warnings... My suggestion would
be to do this in a more traditionnal way : create a reset function in the
osgIntrospection::Type class and, here, reset the i-second object... so we
don't need to create a new Type object in the very same address space...

I tried with the following functions and it works great (no more false
positives... :-) )... Yet, do you think there could be a very well hidden
issue I would miss this way ?


Type* Reflection::getOrRegisterType(const ExtendedTypeInfo ti, bool
replace_if_defined)
{
TypeMap tm = getOrCreateStaticData().typemap;
TypeMap::iterator i = tm.find(ti);

if (i != tm.end())
{
if (replace_if_defined  

[osg-users] osg::StateAttribute::ON / OFF for osg::StateAttribute or not ?

[Emmanuel Roche]

Hi again !


I'm working on some kind of editor in fact, and I've noticed that when you
have a StateSet, and a given StateAttribute, if you call
stateSet-setAttributeAndModes(attribute,osg::StateAttribute:ON|osg::StateAttribute::...etc,etc..
) then, (at least for a osg::Fog attribute for example) in the
RefAttributePair created, the osg::StateAttribute::ON  (or OFF) is not
added...

My theory is that this ON/OFF setting each time goes in a given assosiated
mode (as there is on trace of them in RefAttributePair constructors in
StateSet.cpp) : Am I right, or making a big mistake ??


By the way, on a completely different topic, I can now confirm that the
boost serialization for OSG files works pretty well :-) I followed your
advise Robert and used osgIntrospection to generate the sources... and this
generator is a single main.cpp file :-). As a result I have a single library
capable of writing text,xml or binary OSG files indifferently (yes, we can
even same image data in text and xml files !)

Yet the XML format is not easily readable :-( here is a simple stateset
section for example :

StateSet class_id=21 tracking_level=1
version=0 object_id=_5
Object
Referenced object_id=_6

ThreadSafeRefUnref1/ThreadSafeRefUnref
/Referenced
DataVariance1/DataVariance
Name/Name
UserData class_id=-1/UserData
/Object
AttributeList class_id=22
tracking_level=0 version=0
count1/count
item_version0/item_version
item class_id=23 tracking_level=0
version=0
first class_id=24
tracking_level=0 version=0
first8/first
second0/second
/first
second class_id=25
tracking_level=0 version=0
first class_id=26
tracking_level=0 version=0
StateAttribute
class_id=27 class_name=osg_Fog tracking_level=1 version=0
object_id=_7
StateAttribute
class_id=28 tracking_level=0 version=0
Object
Referenced
object_id=_8

ThreadSafeRefUnref1/ThreadSafeRefUnref
/Referenced

DataVariance2/DataVariance
Name/Name
UserData
class_id=-1/UserData
/Object
EventCallback
class_id=-1/EventCallback
UpdateCallback
class_id=-1/UpdateCallback
/StateAttribute
Color class_id=30
tracking_level=0 version=0
x0/x
y0/y
z0/z
w0/w
/Color
Density0.8001
/Density
End11.8/End

FogCoordinateSource33874/FogCoordinateSource
Mode2048/Mode
Start-10.1/Start
/StateAttribute
/first
second2/second
/second
/item
/AttributeList
BinName/BinName
BinNumber0/BinNumber
EventCallback
class_id=-1/EventCallback
ModeList class_id=32 tracking_level=0
version=0
count1/count
item_version0/item_version
item class_id=33 tracking_level=0
version=0
first2912/first
second3/second
/item
/ModeList
 

Re: [osg-users] osg::StateAttribute::ON / OFF for osg::StateAttributeor not ?

[Emmanuel Roche]

I mean that when settings ON on the Fog, then the fog is enabled but when
querying the corresponding RefAttributePair there is no ON. Rather, the
ON ends in the associated mode (GL_FOG only I guess) bit field.

this transfer of the ON from the attribute to the corresponding Mode
surprise me a bit since as a result, it is not simple to query the ON
state of a given attribute :

for(osg::StateSet::AttributeList::iterator it =
stateSet-getAttributeList().begin(); it !=
stateSet-getAttributeList().end(); ++it) {
if((*it).second.first.get() == attribute.get()) {
osg::StateAttribute::OverrideValue val = (*it).second.second;

if(val  osg::StateAttribute::ON)
onOffCheckB-SetValue(true);
if(val  osg::StateAttribute::OVERRIDE)
overrideCheckB-SetValue(true);
if(val  osg::StateAttribute::PROTECTED)
protectedCheckB-SetValue(true);
if(val  osg::StateAttribute::INHERIT)
inheritCheckB-SetValue(true);
break;
}
}

--- In this code sample, the onOffCheckB will never have its value set to
true... even when the attribute IS activated... of course we may query the
ModeList instead, but this doesn't hide the OpenGL layer (ie you have to
know which modes are used by such and such Atribute...)

Manu.




2008/1/31, Paul Martz [EMAIL PROTECTED]:

  It's not clear to me what you're saying. Are you saying that even when
 you specify ON, fog is not enabled? Or are you saying that when you query
 the StateSet's GL_FOG mode later, you're not getting what was set? Or are
 you saying that when you dump the scene graph out to an .osg file, GL_FOG
 ON doesn't appear in the output?

 Please clarify.
-Paul


  --
 *From:* [EMAIL PROTECTED] [mailto:
 [EMAIL PROTECTED] *On Behalf Of *Emmanuel Roche
 *Sent:* Thursday, January 31, 2008 2:55 AM
 *To:* OSG Users
 *Subject:* [osg-users] osg::StateAttribute::ON / OFF for
 osg::StateAttributeor not ?

 Hi again !


 I'm working on some kind of editor in fact, and I've noticed that when you
 have a StateSet, and a given StateAttribute, if you call
 stateSet-setAttributeAndModes(attribute,osg::StateAttribute:ON|osg::StateAttribute::...etc,etc..
 ) then, (at least for a osg::Fog attribute for example) in the
 RefAttributePair created, the osg::StateAttribute::ON  (or OFF) is not
 added...

 My theory is that this ON/OFF setting each time goes in a given assosiated
 mode (as there is on trace of them in RefAttributePair constructors in
 StateSet.cpp) : Am I right, or making a big mistake ??


 By the way, on a completely different topic, I can now confirm that the
 boost serialization for OSG files works pretty well :-) I followed your
 advise Robert and used osgIntrospection to generate the sources... and this
 generator is a single main.cpp file :-). As a result I have a single
 library capable of writing text,xml or binary OSG files indifferently (yes,
 we can even same image data in text and xml files !)

 Yet the XML format is not easily readable :-( here is a simple stateset
 section for example :

 StateSet class_id=21 tracking_level=1
 version=0 object_id=_5
 Object
 Referenced object_id=_6

 ThreadSafeRefUnref1/ThreadSafeRefUnref
 /Referenced
 DataVariance1/DataVariance
 Name/Name
 UserData class_id=-1/UserData
 /Object
 AttributeList class_id=22
 tracking_level=0 version=0
 count1/count
 item_version0/item_version
 item class_id=23 tracking_level=0
 version=0
 first class_id=24
 tracking_level=0 version=0
 first8/first
 second0/second
 /first
 second class_id=25
 tracking_level=0 version=0
 first class_id=26
 tracking_level=0 version=0
 StateAttribute
 class_id=27 class_name=osg_Fog tracking_level=1 version=0
 object_id=_7
 StateAttribute
 class_id=28 tracking_level=0 version=0
 Object
 Referenced
 object_id=_8

 ThreadSafeRefUnref1/ThreadSafeRefUnref
 /Referenced

 DataVariance2/DataVariance
 Name/Name

Re: [osg-users] osg::StateAttribute::ON / OFF for osg::StateAttributeor not ?

[Emmanuel Roche]

Still on the same subject, I've noticed something even more strange (well
maybe that's very well known but I've just discovered it...):

if the case of a Fog attribute, we can switch the attribute On and Off just
calling stateset-setAttributeAndMode(attribute,ON/OFF)

but, in the case of a Material attribute for example, this doesn't work
anymore ! (as the Material has no associated Mode and the ON/OFF value only
affects modes...)

So the only solution is to suppress the attribute in this case... and if you
care about the settings contained in that attribute, well, you have to same
it elsewhere, etc etc etc... things get a bit complecated...

-- Would it be difficult (or irrelevant ?) to add those ON/OFF bits in the
RefAttributePair and then use them to check if a given Attribute should be
applyed to a State or not ??

Manu.


2008/1/31, Emmanuel Roche [EMAIL PROTECTED]:

 I mean that when settings ON on the Fog, then the fog is enabled but when
 querying the corresponding RefAttributePair there is no ON. Rather, the
 ON ends in the associated mode (GL_FOG only I guess) bit field.

 this transfer of the ON from the attribute to the corresponding Mode
 surprise me a bit since as a result, it is not simple to query the ON
 state of a given attribute :

 for(osg::StateSet::AttributeList::iterator it =
 stateSet-getAttributeList().begin(); it !=
 stateSet-getAttributeList().end(); ++it) {
 if((*it).second.first.get() == attribute.get()) {
 osg::StateAttribute::OverrideValue val = (*it).second.second;

 if(val  osg::StateAttribute::ON)
 onOffCheckB-SetValue(true);
 if(val  osg::StateAttribute::OVERRIDE)
 overrideCheckB-SetValue(true);
 if(val  osg::StateAttribute::PROTECTED)
 protectedCheckB-SetValue(true);
 if(val  osg::StateAttribute::INHERIT)
 inheritCheckB-SetValue(true);
 break;
 }
 }

 --- In this code sample, the onOffCheckB will never have its value set to
 true... even when the attribute IS activated... of course we may query the
 ModeList instead, but this doesn't hide the OpenGL layer (ie you have to
 know which modes are used by such and such Atribute...)

 Manu.




 2008/1/31, Paul Martz [EMAIL PROTECTED]:
 
   It's not clear to me what you're saying. Are you saying that even when
  you specify ON, fog is not enabled? Or are you saying that when you query
  the StateSet's GL_FOG mode later, you're not getting what was set? Or are
  you saying that when you dump the scene graph out to an .osg file, GL_FOG
  ON doesn't appear in the output?
 
  Please clarify.
 -Paul
 
 
   --
  *From:* [EMAIL PROTECTED] [mailto:
  [EMAIL PROTECTED] *On Behalf Of *Emmanuel
  Roche
  *Sent:* Thursday, January 31, 2008 2:55 AM
  *To:* OSG Users
  *Subject:* [osg-users] osg::StateAttribute::ON / OFF for
  osg::StateAttributeor not ?
 
  Hi again !
 
 
  I'm working on some kind of editor in fact, and I've noticed that when
  you have a StateSet, and a given StateAttribute, if you call
  stateSet-setAttributeAndModes(attribute,osg::StateAttribute:ON|osg::StateAttribute::...etc,etc..
  ) then, (at least for a osg::Fog attribute for example) in the
  RefAttributePair created, the osg::StateAttribute::ON  (or OFF) is not
  added...
 
  My theory is that this ON/OFF setting each time goes in a given
  assosiated mode (as there is on trace of them in RefAttributePair
  constructors in StateSet.cpp) : Am I right, or making a big mistake ??
 
 
  By the way, on a completely different topic, I can now confirm that the
  boost serialization for OSG files works pretty well :-) I followed your
  advise Robert and used osgIntrospection to generate the sources... and this
  generator is a single main.cpp file :-). As a result I have a single
  library capable of writing text,xml or binary OSG files indifferently (yes,
  we can even same image data in text and xml files !)
 
  Yet the XML format is not easily readable :-( here is a simple stateset
  section for example :
 
  StateSet class_id=21 tracking_level=1
  version=0 object_id=_5
  Object
  Referenced object_id=_6
 
  ThreadSafeRefUnref1/ThreadSafeRefUnref
  /Referenced
  DataVariance1/DataVariance
  Name/Name
  UserData class_id=-1/UserData
  /Object
  AttributeList class_id=22
  tracking_level=0 version=0
  count1/count
  item_version0/item_version
  item class_id=23
  tracking_level=0 version=0
  first class_id=24
  tracking_level=0 version

Re: [osg-users] osg::StateAttribute::ON / OFF forosg::StateAttributeor not ?

[Emmanuel Roche]

Yes sure, I could disable lighting in that simple case (Yet I'm not even
sure of it, I have no real example in mind but suppose I have an other
sibling attribute also depending on GL_LIGHTING... ). But as a matter of
fact, I'm trying to write an OSG editor based on osgIntrospection, and my
real point is that such minor problems unfortunately break the whole
philosophy of the introspection framework (ie you cannot handle every
StateAttribute in an uniform way...).

Thanks for your replies!

Manu.

2008/1/31, Paul Martz [EMAIL PROTECTED]:

  Not all attributes have modes, as you've discovered with Material. The
 current OSG paradigm of being able to setAttributeAndModes for Material
 really doesn't make much sense. I'd be reluctant to rewrite any portions of
 OSG dealing with the fixed function pipe, though, in light of OpenGL 3.

 To disable use of Material, disable lighting: setMode( GL_LIGHTING, OFF ).
 It helps to know OpenGL when using OSG so that you can handle such
 situations.

  Paul Martz
 *Skew Matrix Software LLC*
 http://www.skew-matrix.com
 303 859 9466

  --
 *From:* [EMAIL PROTECTED] [mailto:
 [EMAIL PROTECTED] *On Behalf Of *Emmanuel Roche
 *Sent:* Thursday, January 31, 2008 8:01 AM
 *To:* OpenSceneGraph Users
 *Subject:* Re: [osg-users] osg::StateAttribute::ON / OFF
 forosg::StateAttributeor not ?

 I mean that when settings ON on the Fog, then the fog is enabled but when
 querying the corresponding RefAttributePair there is no ON. Rather, the
 ON ends in the associated mode (GL_FOG only I guess) bit field.

 this transfer of the ON from the attribute to the corresponding Mode
 surprise me a bit since as a result, it is not simple to query the ON
 state of a given attribute :

 for(osg::StateSet::AttributeList::iterator it =
 stateSet-getAttributeList().begin(); it !=
 stateSet-getAttributeList().end(); ++it) {
 if((*it).second.first.get() == attribute.get()) {
 osg::StateAttribute::OverrideValue val = (*it).second.second;

 if(val  osg::StateAttribute::ON)
 onOffCheckB-SetValue(true);
 if(val  osg::StateAttribute::OVERRIDE)
 overrideCheckB-SetValue(true);
 if(val  osg::StateAttribute::PROTECTED)
 protectedCheckB-SetValue(true);
 if(val  osg::StateAttribute::INHERIT)
 inheritCheckB-SetValue(true);
 break;
 }
 }

 --- In this code sample, the onOffCheckB will never have its value set to
 true... even when the attribute IS activated... of course we may query the
 ModeList instead, but this doesn't hide the OpenGL layer (ie you have to
 know which modes are used by such and such Atribute...)

 Manu.




 2008/1/31, Paul Martz [EMAIL PROTECTED]:
 
   It's not clear to me what you're saying. Are you saying that even when
  you specify ON, fog is not enabled? Or are you saying that when you query
  the StateSet's GL_FOG mode later, you're not getting what was set? Or are
  you saying that when you dump the scene graph out to an .osg file, GL_FOG
  ON doesn't appear in the output?
 
  Please clarify.
 -Paul
 
 
   --
  *From:* [EMAIL PROTECTED] [mailto:
  [EMAIL PROTECTED] *On Behalf Of *Emmanuel
  Roche
  *Sent:* Thursday, January 31, 2008 2:55 AM
  *To:* OSG Users
  *Subject:* [osg-users] osg::StateAttribute::ON / OFF for
  osg::StateAttributeor not ?
 
   Hi again !
 
 
  I'm working on some kind of editor in fact, and I've noticed that when
  you have a StateSet, and a given StateAttribute, if you call
  stateSet-setAttributeAndModes(attribute,osg::StateAttribute:ON|osg::StateAttribute::...etc,etc..
  ) then, (at least for a osg::Fog attribute for example) in the
  RefAttributePair created, the osg::StateAttribute::ON  (or OFF) is not
  added...
 
  My theory is that this ON/OFF setting each time goes in a given
  assosiated mode (as there is on trace of them in RefAttributePair
  constructors in StateSet.cpp) : Am I right, or making a big mistake ??
 
 
  By the way, on a completely different topic, I can now confirm that the
  boost serialization for OSG files works pretty well :-) I followed your
  advise Robert and used osgIntrospection to generate the sources... and this
  generator is a single main.cpp file :-). As a result I have a single
  library capable of writing text,xml or binary OSG files indifferently (yes,
  we can even same image data in text and xml files !)
 
  Yet the XML format is not easily readable :-( here is a simple stateset
  section for example :
 
  StateSet class_id=21 tracking_level=1
  version=0 object_id=_5
  Object
  Referenced object_id=_6
 
  ThreadSafeRefUnref1/ThreadSafeRefUnref
  /Referenced
  DataVariance1/DataVariance
  Name/Name

[osg-users] boost serialization

[Emmanuel Roche]

Hi every one,

I'm just wondering if any one as never think about using Boost serialization
framework to write/read OSG files ?

I'm working on this question, and until now I'm rather amazed:

- Sure, on one side you need to have a Boost dependency somewhere,
- And I haven't done any performance test yet but I'm pretty sure the io
operations will be slower than forIVE files.

But if read/write speed is not that critical to you this kind of framework
has very interesting feature:

1) You can use a single function to handle read and write process per class
2) This single function is used to write Text, Binary or even XML files (so
no duplication of code like for .osg vs .ive)
3) The code to do this become so simple it's almost frightening (cf example)
(in fact it hides all the reading/writing details...)
4) You can extend OSG with your own classes even more easily.

If someone already worked on this subject, did you end up with an unsolvable
problem ?


Here is an example of the code I use to serialize osg::Geometry:

#include osg/Geometry

#define TARGET osg::Geometry

BOOST_CLASS_EXPORT(TARGET)

namespace boost {
namespace serialization {

OSG_REF_TEMPLATE(TARGET);

template 
void access::destroy(const TARGET* t)
{
// Do nothing: protected destructor;
}

templateclass Archive
void serialize(Archive  ar, TARGET::ArrayData obj, const unsigned int
version)
{
NVP(Array,obj.array);
NVP(Indices,obj.indices);
NVP(Binding,obj.binding);
NVP(Normalize,obj.normalize);
};

templateclass Archive
void serialize(Archive  ar, TARGET obj, const unsigned int version)
{
SERIALIZE_BASE(osg::Drawable);

NVP(PrimitiveSetList,obj.getPrimitiveSetList());
NVP(VertexData,obj.getVertexData());
NVP(NormalData,obj.getNormalData());
NVP(ColorData,obj.getColorData());
NVP(SecondaryColorData,obj.getSecondaryColorData());
NVP(FogCoordData,obj.getFogCoordData());
NVP(TexCoordArrayList,obj.getTexCoordArrayList());
NVP(VertexAttribArrayList,obj.getVertexAttribArrayList());

SERIALIZE_MEMBER(bool,FastPathHint);
}

} // namespace serialization
} // namespace boost

#undef TARGET

With the following macros:

#define OSG_REF_TEMPLATE(name) templateclass Archive \
void serialize(Archive  ar, osg::ref_ptrname ref, const unsigned int
version) \
{ \
name* obj = ref.get(); \
ar  obj; \
ref = obj; \
}

#define SERIALIZE_MEMBER(type,name){ \
type member = obj.get ## name(); \
ar  boost::serialization::make_nvp( # name, member); \
if(Archive::is_loading()) \
obj.set ## name(member); \
}

#define NVP(t,o) ar  boost::serialization::make_nvp(t,o)

#define SERIALIZE_BASE(name) ar  boost::serialization::base_object
name (obj)


... Compare this with the content of Geometry.cpp in the osg or ive plugin
and you will probably be surprised... : the Boost serialization framework
handle automatically STL containers, derived classes, pointer references
etc...

Any way, I keep working on this project until I have a full
ReaderWriter... I'll tell you later if it's a so interesting feature or
not :-).

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

Re: [osg-users] osgIntrospection uninitialization

[Emmanuel Roche]

Hi Robert, I understand what you mean, in fact I think exactly the same : I
don't like those small tricks to workaround some minor problems. But still I
believe there is a memory management issue left here, (in fact both AQTime
and the integrated Visual Studio debugger [VS 7.1]) report the same
leaks... : it is not important because you can't see those leaks before
the end of your process, and the process destruction will clean everything
anyway, but I don't think relying on  such a final cleanup is a good final
solution.

As you said, a clear function is probably an  very bad choice: but as I
said, the most important is to be aware of the problem, and to try to find
the best solution.

By the way, I found two others small issues in this reflection framework :

1) [VERY MINOR] The PropertyInfo class doesn't have a virtual destructor...
its derived classes don't have data members, I'm not sure if it is important
to have a virtual destructor in this case, I guess it's not, but still, if
someone tries to build an extension from this it would surely cause a
problem.

2) [HIDDEN LEAK] The CustomAttributeProvider destructor doesn't free the
attribs_ vector... so there is a memory leak if you try to delete types
using StdVectorReflector for example.


regards,

Manu.


2007/12/15, Robert Osfield [EMAIL PROTECTED]:

 HI Manu,

 I generally cringe a hacks to get round bugs in other software, and
 this does look a case of this here, the profiler you are using is
 buggy and producing false positives.  Adding a clear method is
 potentially dangerous if called at the wrong time, so the naming of
 such a method would have to very clearly reflect its purpose, just
 calling it clear wouldn't cut it.  I not totally opposed to such a
 method it does allow you to workaround a problem.  W.r.t submissions
 see:


 http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol

 Robert.

 On Dec 15, 2007 12:07 AM, Emmanuel Roche [EMAIL PROTECTED] wrote:
  Hi everyone,
 
  just a simple request stil on the introspection framework:
 
  I have noticed that the Types and Converters are stored in a static
  structure in the Reflection class... and this structure is totally
  unaccessible. (Well we could still use Reflection::getTypes() to get the
  type map and delete every type one by one after a const cast,  but for
 the
  converters map that's not possible.
 
  The problem with this kind of static structure, is that they are
 destroyed
  only at the very end of your process, and when it comes to profiling
  questions this gives a big mess (at least on Windows...) : My profiler
  (AQTime 5) is simply considering all the reflection allocations as
 memory
  leaks !...
 
  I guess it would not be a bad idea to add a simple clear static
 function
  to the reflection class to simply delete the static_data member and set
 it
  to NULL. This could even prove useful in [I admit very specific and very
  strange] cases where people would want to stop reflecting every types
 and
  restart with new types...
 
  Could some one remind me how to process to submit a code change ?
 (except if
  someone else can add this clear or whatever function directly... it
 should
  only be two lines of code anyway:
 
  void clear() {
if(_static_data)
delete _static_data;
_static_data = 0;
  }
 
  regards,
 
  Manu.
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] osgIntrospection uninitialization

[Emmanuel Roche]

-- By the way, all those tests are done with OSG 2.2, so maybe the problems
I'm speaking about are already solved in th SVN version...

Manu.


2007/12/15, Emmanuel Roche [EMAIL PROTECTED]:

 Hi Robert, I understand what you mean, in fact I think exactly the same :
 I don't like those small tricks to workaround some minor problems. But still
 I believe there is a memory management issue left here, (in fact both AQTime
 and the integrated Visual Studio debugger [VS 7.1]) report the same
 leaks... : it is not important because you can't see those leaks before
 the end of your process, and the process destruction will clean everything
 anyway, but I don't think relying on  such a final cleanup is a good final
 solution.

 As you said, a clear function is probably an  very bad choice: but as I
 said, the most important is to be aware of the problem, and to try to find
 the best solution.

 By the way, I found two others small issues in this reflection framework :


 1) [VERY MINOR] The PropertyInfo class doesn't have a virtual
 destructor... its derived classes don't have data members, I'm not sure if
 it is important to have a virtual destructor in this case, I guess it's not,
 but still, if someone tries to build an extension from this it would surely
 cause a problem.

 2) [HIDDEN LEAK] The CustomAttributeProvider destructor doesn't free the
 attribs_ vector... so there is a memory leak if you try to delete types
 using StdVectorReflector for example.


 regards,

 Manu.


 2007/12/15, Robert Osfield [EMAIL PROTECTED]:
 
  HI Manu,
 
  I generally cringe a hacks to get round bugs in other software, and
  this does look a case of this here, the profiler you are using is
  buggy and producing false positives.  Adding a clear method is
  potentially dangerous if called at the wrong time, so the naming of
  such a method would have to very clearly reflect its purpose, just
  calling it clear wouldn't cut it.  I not totally opposed to such a
  method it does allow you to workaround a problem.   W.r.t submissions
  see:
 
 
  http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol
 
  Robert.
 
  On Dec 15, 2007 12:07 AM, Emmanuel Roche [EMAIL PROTECTED]
  wrote:
   Hi everyone,
  
   just a simple request stil on the introspection framework:
  
   I have noticed that the Types and Converters are stored in a static
   structure in the Reflection class... and this structure is totally
   unaccessible. (Well we could still use Reflection::getTypes() to get
  the
   type map and delete every type one by one after a const cast,  but for
  the
   converters map that's not possible.
  
   The problem with this kind of static structure, is that they are
  destroyed
   only at the very end of your process, and when it comes to profiling
   questions this gives a big mess (at least on Windows...) : My profiler
   (AQTime 5) is simply considering all the reflection allocations as
  memory
   leaks !...
  
   I guess it would not be a bad idea to add a simple clear static
  function
   to the reflection class to simply delete the static_data member and
  set it
   to NULL. This could even prove useful in [I admit very specific and
  very
   strange] cases where people would want to stop reflecting every types
  and
   restart with new types...
  
   Could some one remind me how to process to submit a code change ?
  (except if
   someone else can add this clear or whatever function directly... it
  should
   only be two lines of code anyway:
  
   void clear() {
 if(_static_data)
 delete _static_data;
 _static_data = 0;
   }
  
   regards,
  
   Manu.
  
  
   ___
   osg-users mailing list
   osg-users@lists.openscenegraph.org
  
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  
  
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


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

[osg-users] osgIntrospection uninitialization

[Emmanuel Roche]

Hi everyone,

just a simple request stil on the introspection framework:

I have noticed that the Types and Converters are stored in a static
structure in the Reflection class... and this structure is totally
unaccessible. (Well we could still use Reflection::getTypes() to get the
type map and delete every type one by one after a const cast,  but for the
converters map that's not possible.

The problem with this kind of static structure, is that they are destroyed
only at the very end of your process, and when it comes to profiling
questions this gives a big mess (at least on Windows...) : My profiler
(AQTime 5) is simply considering all the reflection allocations as memory
leaks !...

I guess it would not be a bad idea to add a simple clear static function
to the reflection class to simply delete the static_data member and set it
to NULL. This could even prove useful in [I admit very specific and very
strange] cases where people would want to stop reflecting every types and
restart with new types...

Could some one remind me how to process to submit a code change ? (except if
someone else can add this clear or whatever function directly... it should
only be two lines of code anyway:

void clear() {
  if(_static_data)
  delete _static_data;
  _static_data = 0;
}

regards,

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

[osg-users] osgIntrospection: help on genwrapper...

[Emmanuel Roche]

Hello everyone I've got a problem here with the result of genwrapper:

here is an example of what I get:

BEGIN_VALUE_REFLECTOR(vBase::RefPtr vXML::Attribute )
I_DeclaringFile(base/RefPtr.h);
I_Constructor0(RefPtr,
   ,
   );
I_Constructor1(IN, vXML::Attribute *, p,
   Properties::NON_EXPLICIT,
   RefPtr__T_P1,
   ,
   );
I_Constructor1(IN, const vBase::RefPtr vXML::Attribute 
vXML::Attribute  , rp,
   Properties::NON_EXPLICIT,
   RefPtr__C5_RefPtrT1_T__R1,
   ,
   );

etc etc...

The problem comes from the red section... as you can see, the templated
class is repeated !... If I correct this small problem, my wrappers compile
just fine... it would be a pity to renounce here, so I'm just about to check
where the problem may come from in GenWrapper sources... any indication
would be really appreciated if someone has an idea how to solve this.

regards,

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

Re: [osg-users] osgIntrospection: help on genwrapper...

[Emmanuel Roche]

It's okay, forget this, I found the source of the problem:

it's because in my RefPtr class definition I had:

RefPtr(const RefPtrT rp); as declaration of the copy constructor

I changed this to RefPtr(const RefPtr rp); and it did the trick !!

But still, I have an other question : is there a way to tell the genwrapper
not to take a given member function into account ? (maybe an option for the
genwrapper.conf file ?)

regards,

Manu.



2007/12/12, Emmanuel Roche [EMAIL PROTECTED]:

 Hello everyone I've got a problem here with the result of genwrapper:

 here is an example of what I get:

 BEGIN_VALUE_REFLECTOR(vBase::RefPtr vXML::Attribute )
 I_DeclaringFile(base/RefPtr.h);
 I_Constructor0(RefPtr,
,
);
 I_Constructor1(IN, vXML::Attribute *, p,
Properties::NON_EXPLICIT,
RefPtr__T_P1,
,
);
 I_Constructor1(IN, const vBase::RefPtr vXML::Attribute 
 vXML::Attribute  , rp,
Properties::NON_EXPLICIT,
RefPtr__C5_RefPtrT1_T__R1,
,
);

 etc etc...

 The problem comes from the red section... as you can see, the templated
 class is repeated !... If I correct this small problem, my wrappers compile
 just fine... it would be a pity to renounce here, so I'm just about to check
 where the problem may come from in GenWrapper sources... any indication
 would be really appreciated if someone has an idea how to solve this.

 regards,

 Manu.

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

Re: [osg-users] osgIntrospection: help on genwrapper...

[Emmanuel Roche]

Forget about this question too, I found the answer in the default
genwrapper.conf file:

configure reflector vLog::Source
configure method
__void__log__wxString__wxString__wxString__wxString__..._S
replace with 
end
end

;-)

Manu.


2007/12/12, Emmanuel Roche [EMAIL PROTECTED]:

 It's okay, forget this, I found the source of the problem:

 it's because in my RefPtr class definition I had:

 RefPtr(const RefPtrT rp); as declaration of the copy constructor

 I changed this to RefPtr(const RefPtr rp); and it did the trick !!

 But still, I have an other question : is there a way to tell the
 genwrapper not to take a given member function into account ? (maybe an
 option for the genwrapper.conf file ?)

 regards,

 Manu.



 2007/12/12, Emmanuel Roche [EMAIL PROTECTED]:
 
  Hello everyone I've got a problem here with the result of genwrapper:
 
  here is an example of what I get:
 
  BEGIN_VALUE_REFLECTOR(vBase::RefPtr vXML::Attribute )
  I_DeclaringFile(base/RefPtr.h);
  I_Constructor0(RefPtr,
 ,
 );
  I_Constructor1(IN, vXML::Attribute *, p,
 Properties::NON_EXPLICIT,
 RefPtr__T_P1,
 ,
 );
  I_Constructor1(IN, const vBase::RefPtr vXML::Attribute 
  vXML::Attribute  , rp,
 Properties::NON_EXPLICIT,
 RefPtr__C5_RefPtrT1_T__R1,
 ,
 );
 
  etc etc...
 
  The problem comes from the red section... as you can see, the templated
  class is repeated !... If I correct this small problem, my wrappers compile
  just fine... it would be a pity to renounce here, so I'm just about to check
  where the problem may come from in GenWrapper sources... any indication
  would be really appreciated if someone has an idea how to solve this.
 
  regards,
 
  Manu.
 


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

Re: [osg-users] using osgIntrospection for own library

[Emmanuel Roche]

Well, nobody has even a simple advise about this ??

Manu.

2007/12/5, Emmanuel Roche [EMAIL PROTECTED]:

 Helle there !!

 I'm currently testing the osg reflection framework, so I got GenWrapper,
 an now I'm using it to try to build wrappers for my own libraries... Here is
 the situation:

 I've got a file typedefs.h containing something like:

 #include osg/Node
 #include osg/ref_ptr

 typedef osg::ref_ptrosg::Node RefNode;

 And when I use genwrapper with such a file, just before the output * INFO:
 creating file `gen/src/osgWrappers/ogl/Typedefs.cpp'

 I get: * WARNING: could not write a reflector for undefined type
 `osg::ref_ptr osg::Node '

 I'm quite new to the introspection, so please correct me if I'm wrong:

 1) Am I right to assume that this warning is not important and everything
 will be all right as long as I load the osg wrapper library as this one
 would provide everything needed to access the reflector for this type ?

 2) And, if it's really the case, is this assumption dangerous because
 osg::ref_ptr osg::Node  is a particularly common type and the same
 assumption would not work for something more exotic (like using osg:ref_ptr
 MyObjectType  where MyObjectType is introspected in a first library
 (lib1) and this referenced type defined only in a second library... If
 someone sees what I mean...) ?

 Thanks for you help !!

 Manu.


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

Re: [osg-users] Still on osgintrospection...

[Emmanuel Roche]

Nobody has no idea about this either ? I thought the introspection was more
famous than that


2007/12/5, Emmanuel Roche [EMAIL PROTECTED]:

 Suppose I have a class MyClass introspected

 I also some kind of template class MyTemplaceclass T, which can be built
 with the type T=MyClass, BUT this construction is done nowhere in our base
 library... I guess if I try to generate wrappers, the type
 MyTemplateMyClass will not be defined (ie reflected). What is best way to
 solve this problem ?

 And by the way, I noticed that (with the SVN version of the genwrapper at
 least) it is not possible to use the option -p to generate VisualStudio
 project files. The option simply doesn't appear anywhere in the source code
 in fact, it that normal ?

 Manu.

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

Re: [osg-users] using osgIntrospection for own library

[Emmanuel Roche]

Hi David,

What I mean in my ponit 2 is:

- Suppose I have a library lib1 where I define my class Class1
- Suppose I build a wrapper for this library: lib1_wrapper

Now, I build another library, lib2 where I define a templated class
Class2T
In this second library, I define the typedef :
typedef Class2Class1 MyTypedef;

- And now I try to build a wrapper for this lib2, lib2_wrapper.

As Class1 is not in lib2, I guess the genwrapper will complain about no
reflector being built for Class2 Class1 , but since Class2 is defined only
in lib2, I don't see how it would be possible to use the type Class2Class1
in my wrappers in this case...

I also have a similar question on the same issue, more generally speaking:

Suppose in my lib1, I define Class1 and the template Class2T, but never
instantiating Class4Class1... Would there be a way to instanciate this
type with through the wrapper then ?

Manu.


2007/12/6, David Callu [EMAIL PROTECTED]:

 Hi Manu

 2007/12/5, Emmanuel Roche [EMAIL PROTECTED]:
 
  Helle there !!
 
  I'm currently testing the osg reflection framework, so I got GenWrapper,
  an now I'm using it to try to build wrappers for my own libraries... Here is
  the situation:
 
  I've got a file typedefs.h containing something like:
 
  #include osg/Node
  #include osg/ref_ptr
 
  typedef osg::ref_ptrosg::Node RefNode;
 
  And when I use genwrapper with such a file, just before the output *
  INFO: creating file `gen/src/osgWrappers/ogl/Typedefs.cpp'
 
  I get: * WARNING: could not write a reflector for undefined type
  `osg::ref_ptr osg::Node '
 
  I'm quite new to the introspection, so please correct me if I'm wrong:
 
  1) Am I right to assume that this warning is not important and
  everything will be all right as long as I load the osg wrapper library as
  this one would provide everything needed to access the reflector for this
  type ?

 You right




 2) And, if it's really the case, is this assumption dangerous because
  osg::ref_ptr osg::Node  is a particularly common type and the same
  assumption would not work for something more exotic (like using osg:ref_ptr
  MyObjectType  where MyObjectType is introspected in a first library
  (lib1) and this referenced type defined only in a second library... If
  someone sees what I mean...) ?

 I am not sure to see what you mean.
 can you explain this please

  David

 ___
 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] using osgIntrospection for own library

[Emmanuel Roche]

okay ! thanks a lot for your explanations !! I'm checking this...

Manu.

2007/12/6, David Callu [EMAIL PROTECTED]:

 oupss don't finish and google send it, arrr

 Take a look to osg/include/osgIntrospection/Reflector. Some template
 reflector is define for std::list, std::vector, ...
 This is the best way a found to generate a reflector for a instantiated
 template not instantiate in the code to reflect.

 David

 2007/12/6, David Callu [EMAIL PROTECTED]:
 
 
 
  2007/12/6, Emmanuel Roche [EMAIL PROTECTED]:
  
   Hi David,
  
   What I mean in my ponit 2 is:
  
   - Suppose I have a library lib1 where I define my class Class1
   - Suppose I build a wrapper for this library: lib1_wrapper
  
   Now, I build another library, lib2 where I define a templated class
   Class2T
   In this second library, I define the typedef :
   typedef Class2Class1 MyTypedef;
  
   - And now I try to build a wrapper for this lib2, lib2_wrapper.
  
   As Class1 is not in lib2, I guess the genwrapper will complain about
   no reflector being built for Class2 Class1 ,
 
 
 
  GenWrapper work on one Header at time. So if your  typedef
  Class2Class1 MyTypedef;
  is define in the same file of the template definition Class2T, It will
  create the Class2Class1 reflector.
 
 
 
 
  I also have a similar question on the same issue, more generally
   speaking:
  
   Suppose in my lib1, I define Class1 and the template Class2T, but
   never instantiating Class4Class1... Would there be a way to instanciate
   this type with through the wrapper then ?
 
 
  If you think to add  typedef Class4Class1 myClass; in the wrapper
  source with the optional genWrapper.conf file, this is theoretically
  possible (from the compiler and linker view). But genWrapper don't support
  this kind of operation.
 
  A solution is to create a template reflector for your template Class2
  and instanciate this template reflector in the wrapper source.
  Alre
 
 
  Manu.
  
  
   2007/12/6, David Callu [EMAIL PROTECTED]:
   
 Hi Manu
   
2007/12/5, Emmanuel Roche [EMAIL PROTECTED] :

 Helle there !!

 I'm currently testing the osg reflection framework, so I got
 GenWrapper, an now I'm using it to try to build wrappers for my own
 libraries... Here is the situation:

 I've got a file typedefs.h containing something like:

 #include osg/Node
 #include osg/ref_ptr

 typedef osg::ref_ptrosg::Node RefNode;

 And when I use genwrapper with such a file, just before the output
 * INFO: creating file `gen/src/osgWrappers/ogl/Typedefs.cpp'

 I get: * WARNING: could not write a reflector for undefined type
 `osg::ref_ptr osg::Node '

 I'm quite new to the introspection, so please correct me if I'm
 wrong:

 1) Am I right to assume that this warning is not important and
 everything will be all right as long as I load the osg wrapper 
 library as
 this one would provide everything needed to access the reflector for 
 this
 type ?
   
You right
   
   
   
   
2) And, if it's really the case, is this assumption dangerous
 because osg::ref_ptr osg::Node  is a particularly common type and 
 the same
 assumption would not work for something more exotic (like using 
 osg:ref_ptr
 MyObjectType  where MyObjectType is introspected in a first library
 (lib1) and this referenced type defined only in a second library... If
 someone sees what I mean...) ?
   
I am not sure to see what you mean.
can you explain this please
   
 David
   
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
   
   
   
  
   ___
   osg-users mailing list
   osg-users@lists.openscenegraph.org
   http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  
  
  
 

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


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

[osg-users] using osgIntrospection for own library

[Emmanuel Roche]

Helle there !!

I'm currently testing the osg reflection framework, so I got GenWrapper, an
now I'm using it to try to build wrappers for my own libraries... Here is
the situation:

I've got a file typedefs.h containing something like:

#include osg/Node
#include osg/ref_ptr

typedef osg::ref_ptrosg::Node RefNode;

And when I use genwrapper with such a file, just before the output * INFO:
creating file `gen/src/osgWrappers/ogl/Typedefs.cpp'

I get: * WARNING: could not write a reflector for undefined type
`osg::ref_ptr osg::Node '

I'm quite new to the introspection, so please correct me if I'm wrong:

1) Am I right to assume that this warning is not important and everything
will be all right as long as I load the osg wrapper library as this one
would provide everything needed to access the reflector for this type ?

2) And, if it's really the case, is this assumption dangerous because
osg::ref_ptr osg::Node  is a particularly common type and the same
assumption would not work for something more exotic (like using osg:ref_ptr
MyObjectType  where MyObjectType is introspected in a first library
(lib1) and this referenced type defined only in a second library... If
someone sees what I mean...) ?

Thanks for you help !!

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

[osg-users] osgIntrospection and operators ?

[Emmanuel Roche]

It's me again, sorry to ask so much, but I keep being surprised with this
introspection stuff:

Correct me if I'm missing something but since the operators of a class are
not reflected (why ?), how can you expect to do something as simple as the
addition of two osg::Vec3 introspectively ???

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

[osg-users] picking with wireframe...

[Emmanuel Roche]

Hi everyone...

just a few questions on the picking mechanism:

Imagine I want to pick objects in the scene, but some of them are in
wireframe mode... in this case I would like the object to be picked only if
I'm really on an edge (or maybe very close to an edge...). This doesn't seem
to be the default picking result obtained with something like
view-computeIntersections(...) as clicking in the middle of a wireframe
rendered face still give a collision.

Does anyany have any suggestion on how this would be best achieved ?
(Personaly I was thinking about making calculations using the local hit
point and the vertices of the colliding face to see how close the hit point
is from a given edge)

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

[osg-users] non-writable object....

[Emmanuel Roche]

It's me again :-)

Just a simple question again, concerning the plugins this time:

suppose I have a graph with some kind of nodes that should NOT be written to
file when I save the graph... I guess the only solution is to remove those
nodes before writing the file no ? I mean, there is no way to remove a
child in the writing process or to write an empty object in the file, I
guess ?

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

[osg-users] nodemask and traversals

[Emmanuel Roche]

hi again,


Just something about the nodemasks: suppose  i want to stop drawing an
object, all the examples I've seen say claeraly that I have to set
node-setNodeMask(0x0), but suppose now that I really want to change only
one bit in this mask: where should I look for the bit field against which
this mask is checked ? (and the overriding bit field I guess...)

I though only the first bit was checked, but it is not the case, as an
object with the mask 0x0010 is also drawn for instance...

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

Re: [osg-users] About the plugins...

[Emmanuel Roche]

okay Robert,

and concerning the UserData object in each object ? How would I process if I
wanted this data to be dumped to my .osg files too when I save a node ?

Manu.


2007/11/14, Robert Osfield [EMAIL PROTECTED]:

 Hi Manu,

 Extending the .osg format with your own
 callbacks/nodes/state/drawables is pretty easy - just look to see how
 all the NodeKits do it i.e. they have src/osgPlugins/osgParticle,
 src/osgPlugins/osgText.

 The .ive format isn't extensible in the same way though, to extend it
 you have to go in a add support directly for you data type.  The is a
 flaw with the .ive format, and makes it inappropriate for the type of
 work you have in mind.

 Longer term I'd like a native osg binary format that is extensible,
 but alas its quite a chunk of work so not possible to introduce any
 time soon.

 Robert.

 On Nov 13, 2007 9:26 PM, Emmanuel Roche [EMAIL PROTECTED] wrote:
  Hi every one...
 
  Suppose I want to construct a special NodeCallback, call it
 MyCallback,
  then I load a scene graph from an .ive file, find a given node, assign
 my
  famous callback to it and then want to write this graph back on the hard
  drive BUT writing the info in MyCallback also to be able to load it
 again
  the next time... How should I do this ??
 
  I mean, is there a way to improve the Osg and Ive plugins for them to
 be
  able to handle other chunk of data,  or do I have to write a full plugin
  even in this case ? Will I ever be able to write the file as a .ive file
 ??
  Or Am I bound to select an  other extension ?
 
  Sorry, I'm quite a beginner with the plugins writing... :-)
 
  regards,
  Manu.
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[osg-users] About the plugins...

[Emmanuel Roche]

Hi every one...

Suppose I want to construct a special NodeCallback, call it MyCallback,
then I load a scene graph from an .ive file, find a given node, assign my
famous callback to it and then want to write this graph back on the hard
drive BUT writing the info in MyCallback also to be able to load it again
the next time... How should I do this ??

I mean, is there a way to improve the Osg and Ive plugins for them to be
able to handle other chunk of data,  or do I have to write a full plugin
even in this case ? Will I ever be able to write the file as a .ive file ??
Or Am I bound to select an  other extension ?

Sorry, I'm quite a beginner with the plugins writing... :-)

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

Re: [osg-users] multiple windows

[Emmanuel Roche]

Hi again,

I check again the crash: in fact it comes from osgDB::readNodeFile(...) when
it's called the second time (so after a first View is created, added to the
main composite viewer, rendered correctly a few seconds, and then removed
from the composite viewer and destroyed...) : Would you have any clue on
this Robert ?

Manu.


2007/10/29, Emmanuel Roche [EMAIL PROTECTED]:

 By the way, guys, I've noticed a small bug in this wxOSG_tab application
 (at least in the version I compiled...):

 Has someone already noticed that, if you remove the start page [you then
 create the _auiNotebook the first time it is requested] and for example add
 a Menu with an Open... command to load osg models, then each time you do
 this sequence:

 1) Open an osg file,
 2) Close the only tab created
 3) Try to open an other file

 ... the application crashes...

 I put a zip file of the modified sources on my website: if someone wants
 to check this... http://utopianworld.ath.cx/web/osg/wxOSG_tab_modified.zip
 Or maybe it's a known issue and that's the very reason why you added the
 Start page and prevented its detruction ?

 I can't say if the problem comes from OSG or wxWidgets: sometimes I have a
 crash on osgViewer::View constructor but the debug version doesn't display
 anything useful, and sometines I have the bug in other dlls like ntdll for
 example... if it comes from wxWidgets, maybe that's the reason why you are
 using version 2.9 (I built the application with the version 2.8.4, and in
 non-unicode... so if you when to test this you may have to make small
 changed in the code I added [every thing is in MainFrame.cpp in fact])

 regards,
 Manu.


 2007/10/29, Thibault Genessay [EMAIL PROTECTED]:
 
  Hi Mario
 
 
  On 10/26/07, Mario Valle [EMAIL PROTECTED] wrote:
   I had to make some addition to have it compiling under VS 7.1 (and my
  wx and osg
   libraries). But beside this, I noticed a strange thing:
   load spaceship.osg (or fountain.osg) and you notice the motor plumes
  does not animate. If
   you make the model rotate, they start animate again.
 
  That is quite expected. The update traversal is not normally
  triggered, so no updatecallback-based animations can work if the view
  is not being updated. If you throw the model, the manipulator calls
  requestContinuousUpdate(true) so animations are updated.
  If you want to override this behavior, you can call
  Canvas::setUpdateWhenIdleOverride(true). You'll get the normal,
  real-time OSG loop.
 
  The rationale is that GUI based applications more often display static
  scenes (e.g. in a 3D modeler, the update is not continuous).
 
   It is something related to your OnIdle optimization. If you comment
  the if line, then
   everything animates as usual.
   Hope it helps.
 
  Glad to see if compiles under 7.1
  Thanks for testing
 
  Thibault
 
   Ciao!
   mario
  
  
   Thibault Genessay wrote:
Hi Emmanuel
   
I have made a sample that demonstrate the integration of the OSG in
wxWidgets. It is a simple frame with a wxAUINotebook containing OSG
views. You can download source and binaries at
http://ips-dil.unil.ch/osg
   
Could you have a look at these and see if this suits your needs ?
   
I am planning to release it as an official sample to
  OSG+wxWidgets,
so I'll need to test it on more systems (not tested on Linux as of
today) and more threading models.
   
It uses a modified version of the osgCompositeViewer::Viewer that
skips rendering if makeCurrent() returns false. Currently, the
composite viewer ignores the return value of makeCurrent(). We'll
  need
to address this issue with Robert as it is precisely the problem you
and him are discussing in the thread camera switching in composite
viewer.
   
Cheers
   
Thibault
   
   
On 10/26/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Okay, with this version joined, we have two tabs (not added
  dynamically,
sure, but it's a beginning...) with animation rendered correctly...
   
The only issue left is the mouse handling problem:
I added a trackballmanipulator on the view1 on each tab, assigned
  an
handling function to the corresponding wxGLCanvas each time, and
  this
function is indeed called when I drag on the view1 BUT nothing
  moves...
:-(...
   
I'm using view-getEventQueue()... could it be somehow
  disconnected ?
nothing happens either if I use the corresponding
graphicswindow-getEventQueue()... so what's left ??
   
Manu.
   
   
2007/10/26, Emmanuel Roche [EMAIL PROTECTED]:
Indeed, we are in a situation where the CompositeViewers don't
  share the
GraphicsWindows and everything happen in the same thread... yet,
  it's
currently not working for me:
as soon as I had a second tab only the last compositeviewer gets
  updated
and drawn, the others are frozen... :-(...
I keep investigating...
   
Manu.
   
   
2007/10/26, Robert Osfield  [EMAIL

Re: [osg-users] multiple windows

[Emmanuel Roche]

Hi !

thanks for testing Thibault, if it's working on your side, it's already a
good thing...
I compiled everything in multithreaded DLL, this should be ok... So, as you
suggest, maybe it's a good time to try VS 2005... :-)

Manu.

2007/10/29, Thibault Genessay [EMAIL PROTECTED]:

 Hi Emmanuel

 I've just compiled your mod, and got the sample running.

  Has someone already noticed that, if you remove the start page [you
 then
  create the _auiNotebook the first time it is requested] and for example
 add
  a Menu with an Open... command to load osg models, then each time you
 do
  this sequence:
 
  1) Open an osg file,
  2) Close the only tab created
  3) Try to open an other file
 
  ... the application crashes...

 I can't reproduce this crash on my machine (VS 2005 SP1), everything
 seems to work smoothly.

  Or maybe it's a known issue and that's the very reason why you added the
  Start page and prevented its detruction ?

 No, the only reason I did this in the first place is because we would
 have no way to spawn the startup page if we closed it - thus we would
 not be able to add anymore tabs.
 Also, it was a good way to check that we could add any window type as
 a tab - not only osg canvas.

 
  I can't say if the problem comes from OSG or wxWidgets: sometimes I have
 a
  crash on osgViewer::View constructor but the debug version doesn't
 display
  anything useful, and sometines I have the bug in other dlls like ntdll
 for
  example... if it comes from wxWidgets, maybe that's the reason why you
 are
  using version 2.9 (I built the application with the version 2.8.4, and
 in
  non-unicode... so if you when to test this you may have to make small
  changed in the code I added [every thing is in MainFrame.cpp in fact])
 

 I'd bet the problem is a CRT issue. The bugs in wxAUI I had in the
 past were always triggered inside wxWidgets when you would remove a
 tab, it does not seem to be the case here.
 Have you made sure you used the multithreaded DLL everywhere ? (osg
 does this by default, wxWidgets needs to be compiled in DLL [Unicode]
 mode), and your app must use the multithreaded DLL.
 Also make sure you use the correct preprocessor macros (WXUSINGDLL and
 such).

 Bugs that occur at various places are hard to track. One thing you can
 do is regularly check the heap to see if a corruption occurs at some
 point by using the _heapchk() function. If something goes wrong you
 can be notified before the crash occurs (at a random place because the
 memory layout changes from execution to execution).

 Finally, try to switch to VS 2005 as the compiler (and the C++
 runtime) contains much less bugs than VS 7.x series.

 Cheers

 Thibault


  regards,
  Manu.
 
 
  2007/10/29, Thibault Genessay [EMAIL PROTECTED]:
   Hi Mario
  
  
   On 10/26/07, Mario Valle [EMAIL PROTECTED] wrote:
I had to make some addition to have it compiling under VS 7.1 (and
 my wx
  and osg
libraries). But beside this, I noticed a strange thing:
load spaceship.osg (or fountain.osg) and you notice the motor plumes
  does not animate. If
you make the model rotate, they start animate again.
  
   That is quite expected. The update traversal is not normally
   triggered, so no updatecallback-based animations can work if the view
   is not being updated. If you throw the model, the manipulator calls
   requestContinuousUpdate(true) so animations are updated.
   If you want to override this behavior, you can call
   Canvas::setUpdateWhenIdleOverride(true). You'll get the
  normal,
   real-time OSG loop.
  
   The rationale is that GUI based applications more often display static
   scenes (e.g. in a 3D modeler, the update is not continuous).
  
It is something related to your OnIdle optimization. If you comment
 the
  if line, then
everything animates as usual.
Hope it helps.
  
   Glad to see if compiles under 7.1
   Thanks for testing
  
   Thibault
  
Ciao!
mario
   
   
Thibault Genessay wrote:
 Hi Emmanuel

 I have made a sample that demonstrate the integration of the OSG
 in
 wxWidgets. It is a simple frame with a wxAUINotebook containing
 OSG
 views. You can download source and binaries at
 http://ips-dil.unil.ch/osg

 Could you have a look at these and see if this suits your needs ?

 I am planning to release it as an official sample to
 OSG+wxWidgets,
 so I'll need to test it on more systems (not tested on Linux as of
 today) and more threading models.

 It uses a modified version of the osgCompositeViewer::Viewer that
 skips rendering if makeCurrent() returns false. Currently, the
 composite viewer ignores the return value of makeCurrent(). We'll
 need
 to address this issue with Robert as it is precisely the problem
 you
 and him are discussing in the thread camera switching in
 composite
 viewer.

 Cheers

 Thibault


 On 10/26/07, Emmanuel Roche [EMAIL PROTECTED] wrote

Re: [osg-users] multiple windows

[Emmanuel Roche]

Yes Alberto, you're right, and I noticed this also, that's why my
GraphicsWindowWX class inherits from both wxGLCanvas and
osgViewer::GraphicsWindow as you can see in the files I joined... [this
solution comes from the osgviewerWX example].

And in addition to this you will notice  that I'm not using OnPaint to draw
the GL canvas : because this function is called only when Wx thinks it is
needed... I had to use an Idle function instead to handle the
viewer-frame() call often enough.

Concerning the TrackballManipulator issue I noticed that things work well if
I use view-getEventQueue() instead of the corresponding
GraphicsWindow-getEventQueue()...

Manu.

PS: ... Writing this, I have an other idea... the very problem comes from
the fact that I'm using an Idle function... but why am I not keeping using
OnPaint and just adding a call o Refresh() at the end !!! ??? :-) I'm
testing this right now...


2007/10/26, Alberto Luaces [EMAIL PROTECTED]:

 Hi Manu,

 I have been investigating a bit the event issue an I found some
 interesting
 things:

 The mouse event is only proccessed when the mouse pointer is over a part
 of
 the wxPanel not owned by a wxGLCanvas, that is, mouse events on the
 wxGLCanvas aren't sent to its parents. According to the Wx documentation,
 only events that are derived from wxCommandEvent are passed to the
 parents.
 The rest (and here the documentation mentions wxMouseEvent explicitly)
 aren't. So we should have to subclass from wxGLCanvas to handle those
 events
 after all.

 I'll post further progress.

 Alberto

 El Thursday 25 October 2007 17:23:52 Emmanuel Roche escribió:
  Hi again guys !
 
  I've just tested your solution Alberto, and indeed it's working and I
 can
  see both pages with two View on each page :-)...
 
  Yet I think there is still something I'm missing about the
 CompositeViewer
  behavior : indeed, I set a trackballmanipulator for the view1 [
  view1-setCameraManipulator(new osgGA::TrackballManipulator); ] and
 created
  a Mouse handling function:
 
  void ventana::OnMouse(wxMouseEvent event)
  {
  if (event.ButtonDown()) {
  int button = event.GetButton();
  v1-getEventQueue()-mouseButtonPress(event.GetX(), event.GetY
 (),
  button);
  }
  else if (event.ButtonUp()) {
  int button = event.GetButton();
  v1-getEventQueue()-mouseButtonRelease(event.GetX(), event.GetY
 (),
  button);
  }
  else if (event.Dragging()) {
  v1-getEventQueue()-mouseMotion(event.GetX(), event.GetY());
  }
  }
 
  ... here v1 is the first GraphicsWindow on the tab, and, when I
 activate
  this function by dragging the mouse on the tab nothing moves :-(...
 I
  trying replacing v1 by cViewer and calling
  cViewer-setEventQueue(v1-getEventQueue()) in the initilialization
 process
  [ because the eventQueue seems to be NULL otherwise...] but this doesn't
  work either... Any clue about this ???
 
 
  regards,
  Manu.
 
  2007/10/25, Robert Osfield [EMAIL PROTECTED]:
   Hi Guys,
  
   I don't have any recommendations, or time right now to dive into this
   topic.  I'd certainly like to see osgViewer be able to cope with this
   type of usage, and its not one that its been coded for up to this
   point.  Might I suggest getting a tabbed WxWidget example together
   than could be included with the OSG distribution that illustrates the
   this issue and can be used as a test bed for a final recommend
   solution.
  
   Robert.
  
   On 10/25/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
Thanks a lot Alberto I guess I could not get anything more usefull
 :-)
!
   
I'm checking this right now
   
Regards,
Manu.
   
2007/10/25, Alberto Luaces  [EMAIL PROTECTED]:
 Hi Manu,

 I'm doing the very same thing, but with two views of a same scene
 on
  
   every
  
 tab. Currently it works well, but I suspect there are duplicated
   
resources, so
   
 I have to say that my code is not in its final version.

 I'm attaching it, it works for me on Linux and wx 2.6.3unmodified.

 Feel free to compare it with yours so we can learn together :)

 HTH,

 Alberto

 El Thursday 25 October 2007 12:37:45 Emmanuel Roche escribió:
  Hello everyone!
 
  I've got a simple question, but I can't find any practical
  solution:
 
  In my application, I have to display a notebook with a 3D window
 on
  
   each
  
  tab... and I want to be able to add/remove tabs dynamically...
 so,
  
   what
  
can
   
  I use to achieve this result ?
 
  I'm usig wxWidgets + OSG 2.2.0
  I'm on Win XP
 
  I tried with a CompositeViewer :
  - creating the conpositeViewer when requested (so everything
 should
  
   be
  
in
   
  the wx event handling thread...)
  - building my graphicswindowWX
  - creating a view
  - adding this view to the compositeview
  - relying on an Idle function to call viewer

Re: [osg-users] multiple windows

[Emmanuel Roche]

Indeed, we are in a situation where the CompositeViewers don't share the
GraphicsWindows and everything happen in the same thread... yet, it's
currently not working for me:

as soon as I had a second tab only the last compositeviewer gets updated and
drawn, the others are frozen... :-(...

I keep investigating...

Manu.

2007/10/26, Robert Osfield [EMAIL PROTECTED]:

 On 10/26/07, Alberto Luaces [EMAIL PROTECTED] wrote:
  If I recall correctly, you can have as many CompositeViewers as you
 like/need.

 If the different viewers don't share any GaphicsWindows then it should
 be fine to have multiple Viewer/CompositeViewers.

 However, If all the viewers run in different threads then sharing a
 single scene graph between them would be problematic.  Such usage
 would lead to one viewers update running in parallel with another
 viewer's cull/draw.

 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] multiple windows

[Emmanuel Roche]

Okay, with this version joined, we have two tabs (not added dynamically,
sure, but it's a beginning...) with animation rendered correctly...

The only issue left is the mouse handling problem:
I added a trackballmanipulator on the view1 on each tab, assigned an
handling function to the corresponding wxGLCanvas each time, and this
function is indeed called when I drag on the view1 BUT nothing moves...
:-(...

I'm using view-getEventQueue()... could it be somehow disconnected ?
nothing happens either if I use the corresponding
graphicswindow-getEventQueue()... so what's left ??

Manu.


2007/10/26, Emmanuel Roche [EMAIL PROTECTED]:

 Indeed, we are in a situation where the CompositeViewers don't share the
 GraphicsWindows and everything happen in the same thread... yet, it's
 currently not working for me:

 as soon as I had a second tab only the last compositeviewer gets updated
 and drawn, the others are frozen... :-(...

 I keep investigating...

 Manu.

 2007/10/26, Robert Osfield [EMAIL PROTECTED]:
 
  On 10/26/07, Alberto Luaces [EMAIL PROTECTED] wrote:
   If I recall correctly, you can have as many CompositeViewers as you
  like/need.
 
  If the different viewers don't share any GaphicsWindows then it should
  be fine to have multiple Viewer/CompositeViewers.
 
  However, If all the viewers run in different threads then sharing a
  single scene graph between them would be problematic.  Such usage
  would lead to one viewers update running in parallel with another
  viewer's cull/draw.
 
  Robert.
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 


#include wx/wx.h
#include wx/glcanvas.h
#include wx/notebook.h

#include osg/ref_ptr
#include osg/Vec3
#include osg/GraphicsContext
#include osgViewer/GraphicsWindow
#include osgViewer/CompositeViewer
#include osgViewer/Viewer
#include osgViewer/View
#include osgDB/ReadFile
#include osgGA/TrackballManipulator

#include iostream

osg::State *st2;
osg::State *st1;

//osgViewer::CompositeViewer* currentViewer;

class programa: public wxApp
{
public:
bool OnInit();
};

DECLARE_APP( programa)
IMPLEMENT_APP( programa)

class ventanaOSGWX: public osgViewer::GraphicsWindow
{
public:
ventanaOSGWX( wxGLCanvas *wx): wxGL( wx)
{
}
bool makeCurrentImplementation()
{
if(!wxGL-GetParent()-IsShown())
return false;

wxGL-SetCurrent();
return true;
}
void swapBuffersImplementation()
{
wxGL-SwapBuffers();
}
bool realizeImplementation()
{
return true;
}
bool valid() const
{
return true;
}
bool isRealizedImplementation() const
{
return true;
}
void closeImplementation()
{
}
bool releaseContextImplementation()
{
return true;
}
void grabFocus()
{
wxGL-SetFocus();
}
void grabFocusIfPointerInWindow()
{
wxGL-SetFocus();
}
private:
wxGLCanvas *wxGL;
};

class ventana: public wxPanel
{
public:
ventana( wxWindow *p, const std::string objeto);

void OnPaint( wxPaintEvent e);

osgViewer::CompositeViewer* getViewer() { return cViewer; }
private:
osg::ref_ptrventanaOSGWX v1, v2;
osgViewer::CompositeViewer *cViewer;
osgViewer::View *view1, *view2;
DECLARE_EVENT_TABLE()
};

BEGIN_EVENT_TABLE( ventana, wxPanel)
EVT_PAINT( ventana::OnPaint)

END_EVENT_TABLE()

class MouseHandler : public wxEvtHandler
{
private:
DECLARE_EVENT_TABLE();
osgViewer::View* view;
ventanaOSGWX* gw;

public:
MouseHandler(osgViewer::View* v, ventanaOSGWX* graphicswindow) : 
view(v), gw(graphicswindow) {};

void OnMouse(wxMouseEvent event);
};

BEGIN_EVENT_TABLE(MouseHandler,wxEvtHandler)
EVT_MOUSE_EVENTS(MouseHandler::OnMouse)
END_EVENT_TABLE()

bool programa::OnInit()
{
//currentViewer = NULL;
wxFrame *v = new wxFrame(0, wxID_ANY, wxT(Dos vistas con OSG), 
wxDefaultPosition, wxSize( 540,305)); /* No vale con el ctor por defecto */
wxNotebook *nb = new wxNotebook(v,wxID_ANY);
ventana *panel1 = new ventana( nb, cow.osg);
ventana *panel2 = new ventana( nb

Re: [osg-users] multiple windows

[Emmanuel Roche]

Great !!
Indeed using the return value of makeCurrent() is exactly what I was looking
for :-D...
I'm testing your application right now !

cheers,
Emmanuel.

2007/10/26, Thibault Genessay [EMAIL PROTECTED]:

 Hi Emmanuel

 I have made a sample that demonstrate the integration of the OSG in
 wxWidgets. It is a simple frame with a wxAUINotebook containing OSG
 views. You can download source and binaries at
 http://ips-dil.unil.ch/osg

 Could you have a look at these and see if this suits your needs ?

 I am planning to release it as an official sample to OSG+wxWidgets,
 so I'll need to test it on more systems (not tested on Linux as of
 today) and more threading models.

 It uses a modified version of the osgCompositeViewer::Viewer that
 skips rendering if makeCurrent() returns false. Currently, the
 composite viewer ignores the return value of makeCurrent(). We'll need
 to address this issue with Robert as it is precisely the problem you
 and him are discussing in the thread camera switching in composite
 viewer.

 Cheers

 Thibault


 On 10/26/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
  Okay, with this version joined, we have two tabs (not added dynamically,
  sure, but it's a beginning...) with animation rendered correctly...
 
  The only issue left is the mouse handling problem:
  I added a trackballmanipulator on the view1 on each tab, assigned an
  handling function to the corresponding wxGLCanvas each time, and this
  function is indeed called when I drag on the view1 BUT nothing moves...
  :-(...
 
  I'm using view-getEventQueue()... could it be somehow disconnected ?
  nothing happens either if I use the corresponding
  graphicswindow-getEventQueue()... so what's left ??
 
  Manu.
 
 
  2007/10/26, Emmanuel Roche [EMAIL PROTECTED]:
   Indeed, we are in a situation where the CompositeViewers don't share
 the
  GraphicsWindows and everything happen in the same thread... yet, it's
  currently not working for me:
  
   as soon as I had a second tab only the last compositeviewer gets
 updated
  and drawn, the others are frozen... :-(...
  
   I keep investigating...
  
   Manu.
  
  
   2007/10/26, Robert Osfield  [EMAIL PROTECTED]:
  
On 10/26/07, Alberto Luaces [EMAIL PROTECTED] wrote:
 If I recall correctly, you can have as many CompositeViewers as
 you
  like/need.
   
If the different viewers don't share any GaphicsWindows then it
 should
be fine to have multiple Viewer/CompositeViewers.
   
However, If all the viewers run in different threads then sharing a
single scene graph between them would be problematic.  Such usage
would lead to one viewers update running in parallel with another
viewer's cull/draw.
   
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
 
 
 
 ___
 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] multiple windows

[Emmanuel Roche]

Whaooo !

Thanks ! thanks ! thanks !...
That's exactly what I was looking for... it's really great ! :-)

just a small point : you're binary distribution is not working : at least
osg24-osgUtil.dll is missing for me :-)

I have osg25-*** on my computer Could someone tell me what this means by
the way ? why this prefix on the dll files ?

But I successfully rebuild your application from the sources with OSG
2.2and wxWidgets
2.8.4 on winXP (with Visual Studio .NET 2003)...
Sorry I don't have a valid linux dev station for the moment.

thanks again... Now I finally have a working example :-)

Manu.


2007/10/26, Emmanuel Roche [EMAIL PROTECTED]:

 Great !!
 Indeed using the return value of makeCurrent() is exactly what I was
 looking for :-D...
 I'm testing your application right now !

 cheers,
 Emmanuel.

 2007/10/26, Thibault Genessay  [EMAIL PROTECTED]:
 
  Hi Emmanuel
 
  I have made a sample that demonstrate the integration of the OSG in
  wxWidgets. It is a simple frame with a wxAUINotebook containing OSG
  views. You can download source and binaries at
  http://ips-dil.unil.ch/osg
 
  Could you have a look at these and see if this suits your needs ?
 
  I am planning to release it as an official sample to OSG+wxWidgets,
  so I'll need to test it on more systems (not tested on Linux as of
  today) and more threading models.
 
  It uses a modified version of the osgCompositeViewer::Viewer that
  skips rendering if makeCurrent() returns false. Currently, the
  composite viewer ignores the return value of makeCurrent(). We'll need
  to address this issue with Robert as it is precisely the problem you
  and him are discussing in the thread camera switching in composite
  viewer.
 
  Cheers
 
  Thibault
 
 
  On 10/26/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
   Okay, with this version joined, we have two tabs (not added
  dynamically,
   sure, but it's a beginning...) with animation rendered correctly...
  
   The only issue left is the mouse handling problem:
   I added a trackballmanipulator on the view1 on each tab, assigned an
   handling function to the corresponding wxGLCanvas each time, and this
   function is indeed called when I drag on the view1 BUT nothing
  moves...
   :-(...
  
   I'm using view-getEventQueue()... could it be somehow disconnected
  ?
   nothing happens either if I use the corresponding
   graphicswindow-getEventQueue()... so what's left ??
  
   Manu.
  
  
   2007/10/26, Emmanuel Roche  [EMAIL PROTECTED]:
Indeed, we are in a situation where the CompositeViewers don't share
  the
   GraphicsWindows and everything happen in the same thread... yet, it's
   currently not working for me:
   
as soon as I had a second tab only the last compositeviewer gets
  updated
   and drawn, the others are frozen... :-(...
   
I keep investigating...
   
Manu.
   
   
2007/10/26, Robert Osfield  [EMAIL PROTECTED]:
   
 On 10/26/07, Alberto Luaces  [EMAIL PROTECTED] wrote:
  If I recall correctly, you can have as many CompositeViewers as
  you
   like/need.

 If the different viewers don't share any GaphicsWindows then it
  should
 be fine to have multiple Viewer/CompositeViewers.

 However, If all the viewers run in different threads then sharing
  a
 single scene graph between them would be problematic.  Such usage
 would lead to one viewers update running in parallel with another
 viewer's cull/draw.

 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
 
  
  
  
  ___
  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] multiple windows

[Emmanuel Roche]

Okay :-) this seems fair enough :-)

2007/10/26, Robert Osfield [EMAIL PROTECTED]:

 On 10/26/07, Emmanuel Roche [EMAIL PROTECTED] wrote:
  just a small point : you're binary distribution is not working : at
 least
  osg24-osgUtil.dll is missing for me :-)
 
  I have osg25-*** on my computer Could someone tell me what this
 means by
  the way ? why this prefix on the dll files ?

 Versioning of the dlls is now done by default for the OSG, this is to
 prevent you from mixing the wrong version of the OSG at compile time
 and runtime.

 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

[osg-users] multiple windows

[Emmanuel Roche]

Hello everyone!

I've got a simple question, but I can't find any practical solution:

In my application, I have to display a notebook with a 3D window on each
tab... and I want to be able to add/remove tabs dynamically... so, what can
I use to achieve this result ?

I'm usig wxWidgets + OSG 2.2.0
I'm on Win XP

I tried with a CompositeViewer :
- creating the conpositeViewer when requested (so everything should be in
the wx event handling thread...)
- building my graphicswindowWX
- creating a view
- adding this view to the compositeview
- relying on an Idle function to call viewer-frame()...

... this works as long as there is a single tab...  but when I had others,
then only the last tab added display something : the others only display the
blue background with no model anymore... ? why that ??

by the way I had to make a small change in the
GraphicsWindowWx::makeCurrentImplementation() :

bool GraphicsWindowWX::makeCurrentImplementation() {
  // Bouml preserved body begin 0001FE83
if(!GetParent()-IsShown())
return false;

SetCurrent();
return true;
  // Bouml preserved body end 0001FE83
}

-- So the hidden tabs should return false here... could this be the source
of the problem ?? (anyway wxWidgets doesn't accept SetCurrent() when the
corresponding tab is not visible... :-S )

regards !

Thanks for your help !
Manu.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org