Re: [osg-users] How to make the change of a dynamic node in another thread

2015-03-27 Thread Xia Baobao
My Code
---


Code:
int times = 0;
int times_on_rendering = 0;
osg::ref_ptrosg::Geode new_geode = NULL;

class ReplaceGeode : public osg::NodeCallback
{
virtual void operator()( osg::Node* node, osg::NodeVisitor* nv )
{
/*
if times_on_rendering = times, it means 
new_geode has not been changed since last frame.
Thus I do not replace the geode.
*/
if( times_on_rendering = times )
{
traverse( node, nv );
return;
}
times_on_rendering = times;
osg::ref_ptrosg::Group group= dynamic_castosg::Group*(node);
if( NULL != new_geode )
{
group-replaceChild( group-getChild(0), new_geode );
}
traverse( node, nv );
}
};

void change_dem_data( LDEMGrid::DEM_DATA *dem_data )
{
/*details of this function has nothing to do with the problem. so I 
omit it here.*/
}

osg::ref_ptrosg::Geode make_geode_from_dem_data( LDEMGrid::DEM_DATA *dem_data 
)
{
const double elevation_scale = 1.0 ;
osg::ref_ptrosg::Geode geode = new osg::Geode;
osg::ref_ptrosg::Geometry geometry = new osg::Geometry;
geode-addDrawable( geometry );
osg::ref_ptrosg::Vec3Array vertex_array = new osg::Vec3Array;
geometry-setVertexArray( vertex_array );
for( int n = 0; n  dem_data-parameter.height ; n++ )
{ 
for(int m = 0; m  dem_data-parameter.width ; m++ )
{
double x = dem_data-parameter.origin_x + 
dem_data-parameter.cellsize_x * m;
double y = dem_data-parameter.origin_y + 
dem_data-parameter.cellsize_y * n;
int id = n * dem_data-parameter.width + m;
vertex_array-push_back( osg::Vec3( x ,y 
,elevation_scale * dem_data-elevation[id] ) );
}
}
osg::DrawElementsUInt* draw_element = 
new osg::DrawElementsUInt(osg::PrimitiveSet::QUADS, 0);
for( int n = 0; n  dem_data-parameter.height - 1 ; n++ )
{ 
for(int m = 0; m  dem_data-parameter.width - 1; m++ )
{
int bottom_left = n* dem_data-parameter.width + m; 
//bottom left
int top_left = (n+1) * dem_data-parameter.width + m; 
// top left
int bottom_right = n * dem_data-parameter.width 
+(m+1); // bottom right
int top_right = (n+1) * dem_data-parameter.width + 
(m+1); // top right
draw_element-push_back( bottom_left );
draw_element-push_back( top_left );
draw_element-push_back( top_right );
draw_element-push_back( bottom_right );
}
}
geometry-addPrimitiveSet( draw_element );
/*
geode-getBound() does not make any difference to me.
It is always about 10 fps.
*/
geode-getBound();
return geode;
}

osg::ref_ptrosg::Node setup_group( LDEMGrid::DEM_DATA *dem_data )
{
osg::ref_ptrosg::Group group = new osg::Group;
osg::ref_ptrosg::Geode geode = make_geode_from_dem_data(dem_data);
group-setDataVariance( osg::Object::DYNAMIC );
group-setUpdateCallback( new ReplaceGeode );
group-addChild( geode );
return group;
}

void *make_new_geode(void *arg)
{
LDEMGrid::DEM_DATA* dem_data = (LDEMGrid::DEM_DATA*)arg;
while(1)
{
change_dem_data(dem_data);
new_geode = make_geode_from_dem_data(dem_data);
times ++;
}
return NULL;
}

int main()
{
/*This is my own class, just reads a 400x400 dem data.*/
LDEMGrid *dem = new LDEMGrid(DEM_DATA/Ele_B3.tif,400,400);
LDEMGrid::DEM_DATA dem_data = dem-GetDEMData();

osg::Group* root = new osg::Group;
osg::ref_ptrosg::Node group = setup_group( dem_data );
root-addChild(group);

osgViewer::Viewer viewer;
viewer.setUpViewInWindow( 50, 50, 1280, 960);
viewer.setSceneData( root );
viewer.addEventHandler(new osgViewer::StatsHandler);
viewer.setCameraManipulator(new osgGA::TrackballManipulator());

pthread_t pid[2];
pthread_create( pid[0], NULL, make_new_geode, dem_data );

viewer.run();
return 0;

}



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





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


Re: [osg-users] How to make the change of a dynamic node in another thread

2015-03-27 Thread Xia Baobao
Thank you. I didn't expect such detailed answer.
( It has been 2 months since the post. Sorry about replying such late. I have 
to do some other things for a while. )
I have tried getBound(), but it doesn't work for me.
From your description, it seems getBound() is what I am looking for. I will 
paste my code in the following reply, maybe you can help me find where my 
mistake is.
I have read osgterrain, but I don't see things about multi-thread.
Reading osgDB::DatabasePager is hard for me.
I am not very familiar with OSG, so sometimes I may not truly understand your 
meaning. I will try to learn more. And I need more help here ^_^. 


robertosfield wrote:
 Hi Xia,
 
 It's a bit late in the evening for me to go into the topic deeply.  
 
 
 It's not possible for us to know what is specifically going amiss in your 
 case as the details are too scant, the best we can do is provide some general 
 pointers:
 
 
 For datasets with a large number of nodes and vertices the cost of computing 
 the bounding volumes of the geometries and nodes can be expensive enough to 
 take up time in the update traversal if you just add the new subgraph into 
 the main scene graph without computing the bounding volumes in the separate 
 thread.  Calling subgraph-getBound() in your compute thread prior to move 
 the node into the merge queue is one way to avoid this issue.  This is what 
 the osgDB::DatabasePager does, so have a look at src/osgDB/DatabasePager.cpp 
 if you want to see how a full blown mutli-threaded database works (it's 
 probably overkill for your specific needs though).
 
 
 The osgterrain example has some multi-threaded scene generation built into 
 for testing purpose, so have a look at this for inspiration.
 
 
 Make sure you do all performance tests with a release build.
 
 
 Consider your approach - does it need to be done on the CPU, any chance you 
 could defer much of the work to the GPU?  These days GPU's are extremely 
 powerful and many tasks that used to be done on CPU to avoid overloading the 
 GPU can now be done on the GPU.  Often the throughput of the GPU allows you 
 to process data in quite a raw way and brute force solve the problem rather 
 than try to be clever with CPU side optimizations.  
 
 One example of this the osgTerrain::DisplacementMappingTechnique that I've 
 been working over the last couple of months, this is available in svn/trunk 
 and gains efficiency by sharing a set of osg::Geometry containing grid 
 meshes, these shared meshes then read height fields from textures on the GPU 
 to displacement them to their intended position for each tile in the terrain. 
  The vertex shader also computes normals.  This approach of sharing geometry 
 and sending just height fields as textures dramatically reduces the CPU and 
 GPU memory consumption and with it bandwidth load and cache misses.  It ends 
 up being faster than the old GeometryTechnique even though the GPU processing 
 load is far higher - as it address the actual bottlenecks that see on modern 
 computer systems, rather than ones we might have seen a decade or two ago.
 
 
 
 Finally, you'll just need to profile your own application if you can't spot 
 bottleneck from just a review of the design and code.  We can't help this I'm 
 afraid as you're the only one with your code and your data.
 
 
 Robert.
 
 


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





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


Re: [osg-users] Problem with clearing the stencil buffer

2015-03-27 Thread Şan Güneş
This issue is solved. To anyone who is wondering, it was because the quad
one was rendered before the quad two(duh). This means the stencil test of
quad one was made before quad two managed to set the stencil buffer.

The solution was to set the quad two to be rendered before anything else in
the scene

 ss_two-setRenderBinDetails(-1, RenderBin);
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Stencil buffer to texture

2015-03-27 Thread Nicolas Baillard
Hello everyone.

I'm trying to use an RTT camera to write both the color buffer and the stencil 
buffer into textures. I tried this:


Code:
// Create texture the color buffer will be written to
osg::Texture2D* buffer = new osg::Texture2D();
buffer-setTextureSize(_w, _h);
buffer-setInternalFormat(GL_RGB);

// Create texture the stencil buffer will be written to
osg::Texture2D* stencil = new osg::Texture2D();
stencil-setTextureSize(_w, _h);
stencil-setInternalFormat(GL_DEPTH_STENCIL_EXT);

// Attach both textures to camera
camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
camera-attach(osg::Camera::COLOR_BUFFER, buffer, 0, 0, false, 0, 0);
camera-attach(osg::Camera::PACKED_DEPTH_STENCIL_BUFFER, stencil, 0, 0, false, 
0, 0);



It produces an error RenderStage::runCameraSetUp(), FBO setup failed, FBO 
status= 0x8cd6.

I took a look at the osgpackeddepthstencil example. It does this:

Code:
camera-attach(osg::Camera::PACKED_DEPTH_STENCIL_BUFFER, GL_DEPTH_STENCIL_EXT);



instead of this:

Code:
camera-attach(osg::Camera::PACKED_DEPTH_STENCIL_BUFFER, stencil, 0, 0, false, 
0, 0);



So I tried it and it didn't produce any error. But then I have no idea what my 
stencil buffer is attached to. How do I read it ? How do I use it ?

Regards,
Nicolas

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





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


Re: [osg-users] The OSG SIGGRAPH BOF train is leaving the station

2015-03-27 Thread John Richardson
However, his spirit will be there...:-)

Shining brightly.

John

-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of webmaster
Sent: Tuesday, March 24, 2015 7:24 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] The OSG SIGGRAPH BOF train is leaving the station

hi John,
  I think robert will not come to SIGGRAPH this year!
  Regards
  zhuwan
   03,24,2015 

在2015-3-24 5:18:30,John Richardson richa...@spawar.navy.mil 写道: 
-原始邮件-
发件人: John Richardson richa...@spawar.navy.mil
发送时间: 2015-3-24 5:18:30
收件人: osg-users@lists.openscenegraph.org
主题: [osg-users] The OSG SIGGRAPH BOF train is leaving the station



AND WILL ARRIVE AT SIGGRAPH…

 

Birds of a Feather Session Title: OpenScenegraph BOF

Date: Wednesday August 12

Location: Los Angeles Convention Center

Time: 10:00 - 11:00 am

 

Note: and yes, I still am on the hook for pictures of past BOF’s and materials….

EXCUSE

   INSERT EXCUSE HERE

/EXCUSE

 

EXCUSE, the only XML tag you will ever need.

 

Last note:

TRIP OVER YOURSELF RUSHING TO MAKE OSG BOF PRESENTATIONS

/ TRIP OVER YOURSELF RUSHING TO MAKE OSG BOF PRESENTATIONS 

 

TRIP OVER YOURSELF RUSHING TO MAKE OSG BOF PRESENTATIONS. Not the only 
necessary and sufficient XML tag, but occasionally useful as a supplemental and 
vicarious standards based enumeration…

 

John

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


Re: [osg-users] Properties in osg::Camera and values of gl_ModelViewMatrix seem out of sync.

2015-03-27 Thread Robin Wu
Hi Robert, 

Have you got a chance to look into this? 

Thank you.


Robin.


robertosfield wrote:
 Hi Robin,
 
 
 I'm a bit perplexed by the issue, as the uniform should be tracking the 
 modelview matrix directly as osg::State does a substitution.
 
 
 Could you create a small code example that reproduces the problem?
 
 
 Robert.
 
 
 On 25 March 2015 at 01:28, Robin Wu  () wrote:
 
  Hi all,
  
  Recently, I discovered a weird issue that the view/Proj matrix in the main 
  camera updated by the default cameramanipulator of osgViewer does not sync 
  with the one I got in the shader, e.g gl_ModelViewMatrix, 
  gl_ProjectionMatrix.
  
  The following two code snippets produce different results.
  The first one is using the built in gl_ModelViewProjectionMatrix uniform 
  passed in during renderingTraversals()
  
  The second one is using the properties from _viewer-getCamera() as 
  uniforms, e.g mainCamera-getViewMatrix().
  
  
  Code:
  
  void main()
  {
   gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
  }
  
  
  
  
  
  Code:
  
  uniform mat4 u_modelMatrix;
  uniform mat4 u_viewMatrix;
  uniform mat4 u_projMatrix;
  
  mat4 getModelToWorldMatrix()
  {
   return osg_ViewMatrixInverse * gl_ModelViewMatrix;
  }
  
  void main()
  {
   gl_Position = u_projMatrix * u_viewMatrix * getModelToWorldMatrix() * 
  gl_Vertex;
  }
  
  
  
  
  When overlapping the rendering results of the two shaders into one buffer, 
  the second shader is approximately one frame slower than the first one, 
  making me doubt that the view/proj matrix managed by the main camera is not 
  synced with the one managed by the renderingTraversals().
  
  This out of sync problem is also pronounced in Wang Rui's effectcompositor. 
  In the ssao.xml demo, if you turn on the analysis mode, you'll see that in 
  the linearDepth buffer view, the depth is unstable (flickering) when you 
  zoom in and out quickly.
  
  The following is the code snippet from Rui's ssao.xml
  
  Code:
  
  void main(void)
  {
   vec4 vecInEye = gl_ModelViewMatrix * gl_Vertex;
   depthValue = (-vecInEye.z - nearPlaneValue) / (farPlaneValue - 
  nearPlaneValue);
   gl_Position = ftransform();
  }
  
  
  
  
  I suspect that the nearPlaneValue and farPlaneValue form the built-in 
  projection matrix's uniforms are somehow not synced with the corresponding 
  ones in gl_ProjectionMatrix ( from ftransfrom() );
  
  This problem bugs me for a long time. My current workaround is just using 
  the manually supplied uniforms from the main camera. But the extra 
  computation of the modelviewprojecionmatrix is definitely a waste in the 
  vertex shader.
  
  Any ideas?
  
  Thank you.
  
  ...
  
  Robin[/code]
  
  --
  Read this topic online here:
  http://forum.openscenegraph.org/viewtopic.php?p=63199#63199 
  (http://forum.openscenegraph.org/viewtopic.php?p=63199#63199)
  
  
  
  
  
  ___
  osg-users mailing list
   ()
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
  (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
  
 
 
  --
 Post generated by Mail2Forum


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





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