Hi Robert,

thanks for your suggestion.

The reason I went for a slave camera is that it makes it easier to add the
FBO path at a later point, without touching the scenegraph,
as it inherits the viewer's scene data by default.

Besides inserting the cameras subgraph into the main graph,
do you think it's reasonable to attach the FBO cameras group as the
subgraph of a "fake" slave camera,
and attach the main scene also as FBO camera child?
I draw a little graph below for clarity.

Thank you,
Ricky


        VIEWER
       /      \
MAIN CAM     SLAVE_CAM
 |               |
 |               |
 |            switch
 |               |
 |             / | \
  |            /  |  \
 |         fbo1 fbo2 fbo3
 |         /   /   /
  \       /   /   /
   \     /   /   /
    \   /   /   /
     | |  /   /
     | | /   /
      SCENE



On Tue, Dec 18, 2012 at 9:25 PM, Robert Osfield <robert.osfi...@gmail.com>wrote:

> Hi Riccardo,
>
> Setting up the camera's rendering backend on each frame will be
> expensive.  Personally I'd just using multiple RTT Camera each with their
> own FBO and Textures associated with them.  Using a Switch, Sequence or
> NodeMask's you can select which of the Camera you want to render to on each
> frame.
>
> Robert.
>
> On 18 December 2012 17:24, Riccardo Corsi <riccardo.co...@kairos3d.it>wrote:
>
>> Hi All,
>>
>> in my application I need an FBO camera to render different frames into
>> different textures, because they will be used by an encoder and thus need
>> to persist for some time.
>>
>> I haven't found an easy way to copy the contents of a texture or of an
>> FBO into another texture.
>> So during the update traversal I change the camera texture attachment
>> with a new texture and call Renderer::SetCameraRequiresSetUp(true).
>>
>> Eveything works fine, but I'm wondering if there's a better/cleaner
>> approach to achieve the same result, as I don't know whether requesting
>> the camera setup every frame has a huge impact on perfomances.
>>
>> Thank you,
>> Ricky
>>
>>
>> _______________________________________________
>> 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

Reply via email to