hi Jp, unfortunately that method is easy but very slow. I think it also uses glGetTexImage.
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" >>> <[email protected]> >>> To: "OpenSceneGraph Users" <[email protected]> >>> 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 <[email protected]> >>> 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 >>>> [email protected] >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>> >>>> >>>> >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >>> >> >> > -- Tugkan Calapoglu ------------------------------------- VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone +49.8031.463641 fax +49.8031.463645 email [email protected] internet www.vires.com ------------------------------------- Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl ------------------------------------- _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
