Re: [osg-users] How to make the change of a dynamic node in another thread
My Code
---
Code:
int times = 0;
int times_on_rendering = 0;
osg::ref_ptr 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_ptr group= dynamic_cast(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_ptr make_geode_from_dem_data( LDEMGrid::DEM_DATA *dem_data
)
{
const double elevation_scale = 1.0 ;
osg::ref_ptr geode = new osg::Geode;
osg::ref_ptr geometry = new osg::Geometry;
geode->addDrawable( geometry );
osg::ref_ptr 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_ptr setup_group( LDEMGrid::DEM_DATA *dem_data )
{
osg::ref_ptr group = new osg::Group;
osg::ref_ptr 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_ptr 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
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
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
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
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" 写道: -原始邮件- 发件人: "John Richardson" 发送时间: 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, the only XML tag you will ever need. Last note: 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.
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
