Hi Jp, my initial implementation used osg:Image attached to a camera and it was just as slow.
I will see what I can do with PBO's. regards, tugkan > 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" >>>>> <[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
