Hi,
Tugkan Calapoglu wrote:
hi Jp,
unfortunately that method is easy but very slow. I think it also uses
glGetTexImage.
You might be surprised. Have you read the threads I linked to? Attach
uses glReadPixels (while doing the FBO rendering, so you don't have to
bind anything yourself later) and in many cases this is the fastest. If
you want something more elaborate, such as async PBO use, see the
osgscreencapture example. Also, test whatever you use for your setup,
all sorts of things can change the efficiency of reading data back to
CPU. YMMV.
Like Robert said tho, not reading anything back to CPU if you can help
it is the best.
rgds
jp
cheers,
tugkan
Hi Tugkan,
Tugkan Calapoglu wrote:
Hi Robert, Wojciech
my initial guess was that the lengthy draw dispatch of the master view
and failing cull & draw parallelism was the result of the same problem.
However, they actually seem to be different problems and I'll focus
first on the draw dispatch.
The master camera draws only a screen aligned quad and nothing else
(scene with shadows is rendered by the slave camera). Also no dynamic
geometry. But, I indeed have a read buffer operation: a glGetTexImage
call in the postdraw callback of the master camera. This call takes
~12 ms.
I read back a small texture that is rendered by a camera in the current
frame. The camera uses FRAME_BUFFER_OBJECT as render target
implementation.
It looks like using glReadPixels to read directly from the FBO is the
advised method for getting data back to the system memory. How do I get
the FBO that the camera is rendering to? Or, is there a better method to
get the texture data back to the sysmem?
Simplest is to just attach an osg::Image to the RTT (to FBO) camera. See
the attach method of osg::Camera. Think there is an example in
osgprerender.
Also see here:
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/52651
and
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/53432
rgds
jp
cheers,
tugkan
Hi Tugkan,
Robert mentioned lengthy read operation. It may be related to read
buffer operation thats used to compute shadow volume in
LightSpacePerpspectiveShadowMapDB. If your slave view uses
osgShadow::LightSpacePerpspectiveShadowMapDB then you may check if
osgShadow::LightSpacePerpspectiveShadowMapCB (cull bounds flavour) has
the same problem.
I am aware of LightSpacePerpspectiveShadowMapDB glReadBuffer limitation
but I could not find quick and easy to implement workaround that would
do this without scanning the image by CPU. I allocate small 64x64
texture and render the scene there, then read it into CPU memory and use
CPU to scan pixels to optimzie shadow volume from depths and pixel
locations strored in this prerender image.
Wojtek
----- Original Message ----- From: "Robert Osfield"
<robert.osfi...@gmail.com>
To: "OpenSceneGraph Users" <osg-users@lists.openscenegraph.org>
Sent: Wednesday, January 13, 2010 1:04 PM
Subject: Re: [osg-users] RTT slave views and multi-threading
Hi Tugkan,
The osgdistortion example works a bit like what you are describing,
could you try this to see what performance it's getting.
As for general notes about threading, if you are working on the same
graphics context as you are then all the draw dispatch and the draw
GPU can only be done by a single graphics thread so there is little
opportunity to make it more parallel without using another graphics
card/graphics context and interleaving of frames.
As for why the second camera is very expensive on draw dispatch, this
suggest to me that it's blocking either due to the OpenGL fifo being
full or that it contains a GL read back operation of some kind.
Robert.
On Wed, Jan 13, 2010 at 11:34 AM, Tugkan Calapoglu <tug...@vires.com>
wrote:
Hi All,
I am using a slave view for rendering the scene to a texture. Initially
I tried with a camera node, however, this did not work well due to a
problem in LiSPSM shadows and I was suggested to use RTT slave views.
My setup is as follows: There is a single main view and I attach a
slave
view to it. This slave view is attached with addSlave( slave , false );
so that it does *not* automatically use the master scene.
I attach a texture to the slave view and make my scene child of this
view. I attach a screen aligned quad to the main view. This quad
visualizes the RTT texture from the slave view.
Now I have a threading problem which can be seen on the snapshot I
attached. There are two issues:
1- The main view (cam1) has a very large draw time even though it only
renders the screen aligned quad. I double checked to see whether it
also
renders the actual scene but this is not the case.
2- Slave view does not run cull and draw in parallel. Cull and draw do
run in parallel if they are not rendered with the slave view. Moreover,
if I change the render order of the slave camera from PRE_RENDER to
POST_RENDER it is ok.
I could simply use POST_RENDER but I am afraid it introduces an extra
one frame latency. If I render the screen aligned quad first and the
scene later than what I see on the quad is the texture from previous
frame (right?).
Any ideas?
cheers,
tugkan
_______________________________________________
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
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
