I had the same issue in this thread
[osg-users] multi threaded with slave camera and fbo
I dont know how to get the link of this thread so this is the date of the post 06/24/08 02:09

Changing the threading model resolve my problem.
Maybe be it could interest you to read it in the archive

Cedric

Robert Osfield wrote:
Hi David,

For best performance see if you can do all the image process down on
the GPU this way there won't be any need for readback.

Robert.

On Mon, Jul 21, 2008 at 8:50 PM, David Rubel <[EMAIL PROTECTED]> wrote:
Robert,

I'm trying to access the images immediately after calling
renderingTraversals(), so it looks like threading was my issue.  I changed
the threading mode to CullDrawThreadPerContext, and everything works great
(although it's a bit slower).

As for my application, I'm building a model-based tracker for an augmented
reality system.  I'm rendering a 3D model of a real world object and
comparing with live camera input, which allows me to estimate the pose of
the camera in real time.  I was wrapping the image data from the osg::Images
in IplImages and using OpenCV to do some image processing.  While testing, I
removed all of the OpenCV code and was just checking the central pixel
color, to ensure that OpenCV wasn't causing the problem.

Thanks for the help!

- David

On Mon, Jul 21, 2008 at 3:07 PM, Robert Osfield <[EMAIL PROTECTED]>
wrote:
Hi David,

What makes you say that you've got some kind of view matrix update
problem?

What are the images for?  You didn't say what they were for or how you
used them, you just jammed the code in their, which given the context
you gave suggested this was just a distraction.

Having to double guess you logic, and what missing code you haven't
told us about, could it be that you are calling renderinTraversals()
and then immediatlely trying to read the Images attached to the
Cameras?

If so... then perhaps you have a threading synchronization issue...
if the osgViewer::Viewer is running with DrawThreadPerContext or
CullThreadPerCameraDrawThreadPerContext then renderingTraversals()
will return before all rendering is complete.

If this is the issue, then you are best to stick to SingleThreaded or
CullDrawThreadPerContext as these threading models don't return before
all rendering is complete.

Robert.


On Mon, Jul 21, 2008 at 7:52 PM, David Rubel <[EMAIL PROTECTED]> wrote:
Robert,

Thanks for the quick response.  I'm definitely not attaching any
manipulators to the viewer, so I don't think that's the problem; just to
be
sure, I set the manipulator to NULL, and it's still rendering one frame
behind.

How would double buffering work with an attached osg::Image?  Do I need
to
attach two images to separate buffers?  Right now I have one set to the
depth buffer and one to the color buffer, and I expect that after
calling
renderingTraversal() the rendered scene is available in the image.  Is
there
something wrong with that logic?

Thanks again,

- David

On Mon, Jul 21, 2008 at 2:30 PM, Robert Osfield
<[EMAIL PROTECTED]>
wrote:
Hi David,

I can't guess what is up with your setup, but if you do things
correctly the viewer->getCamera()->setViewMatrix() will apply to the
next renderingTraversal().  Is there a chance that you have a camera
manipulator attached to your viewer?

Could it be that OpenGL double buffering is confusing you?

Robert.

On Mon, Jul 21, 2008 at 6:34 PM, David Rubel <[EMAIL PROTECTED]> wrote:
Hi,

I'm writing an OSG application which uses the Viewer class to
setup/display
the SceneGraph.  I'm manually updating the camera location each frame
using
the setViewMatrix() function on my camera, and this seems to be
introducing
a 1 frame delay into the loop (which is bad for my application).  The
first
time I call frame() on camera, the old camera pose is used; the
second
time
I call frame, it is correct again.  I tried calling frame() twice in
each
frame, and this solves the problem, but drawing the entire scene
twice
is
hardly an efficient solution.  I have two osg::Image instances
attached
to
the camera (one reading color and the other reading the depth buffer,
which
I need for my application).

I'm using OSG 2.4.0 and Visual C++ Express.

I've been searching online for this problem, but I can't find
anything
that
looks similar.  Here is an example of the problem:

// setup viewer
viewer = new osgViewer::Viewer;
viewer->setUpViewInWindow(100,100,width,height);
viewer->setSceneData(osgModel);
viewer->getCamera()->setClearColor(osg::Vec4(1, 1, 1, 1));
viewer->getCamera()->setRenderOrder(osg::CameraNode::POST_RENDER);


viewer->getCamera()->setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR);

// attach an image to the camera to be rendered each frame
osg::Image osg_image = new osg::Image;
osg_image->allocateImage(width, height, 1, GL_RGBA,
GL_UNSIGNED_BYTE);
viewer->getCamera()->attach(osg::Camera::COLOR_BUFFER, osg_image);

// attach a depth image to the camera to be rendered each frame
osg::Image osg_depth = new osg::Image;
osg_depth->allocateImage(width, height, 1, GL_DEPTH_COMPONENT,
GL_FLOAT);
viewer->getCamera()->attach(osg::Camera::DEPTH_BUFFER, osg_depth);

Main Loop
{

  ...

  // update camera pose
  osg::Matrixd mat = viewer->getCamera()->getViewMatrix();
  mat.set(newMatrix.getArray());
  viewer->getCamera()->setViewMatrix(mat);

  // render the scene
  viewer->frame();

  // here the images are rendered using the old camera pose

  viewer->frame();

  // here they are correct
}

I've done some research into what the frame() function actually does,
and I
divided it into separate functions and found out that
renderingTraversals()
is the function that needs to be called twice.  For example, this
code
works
as well:

...

  // update camera pose
  osg::Matrixd mat = viewer->getCamera()->getViewMatrix();
  mat.set(newMatrix.getArray());
  viewer->getCamera()->setViewMatrix(mat);

  // render the scene
  viewer->advance();
  viewer->eventTraversal();
  viewer->updateTraversal();
  viewer->renderingTraversals();

  // here the images are rendered using the old camera pose

  viewer->renderingTraversals();

  // here they are correct
}

Thanks in advance!

- 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

--
David Rubel
6th Year BS/MS Computer Science Student
Rochester Institute of Technology
[EMAIL PROTECTED]
703.409.3464
_______________________________________________
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

--
David Rubel
6th Year BS/MS Computer Science Student
Rochester Institute of Technology
[EMAIL PROTECTED]
703.409.3464
_______________________________________________
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

--
+33 (0) 6 63 20 03 56  Cedric Pinson mailto:[EMAIL PROTECTED] 
http://www.plopbyte.net


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

Reply via email to