Hello Carsten,

unfortunately, I have a problem that I don't understand. I have a window 
which has multiple viewports. One of the viewports plays the game of 
FBOGrabForeground/FBOBackground like in the example dyndrawing2.cpp. 
That does not work for me.

In order to track down the origin of that problem I have modified the 
dyndrawing2.cpp example a little bit. Here I can also show the problem 
with just one viewport. What I see is that if I define the viewport not 
just matching the window dimensions, then the resulting default 
framebuffer is not completely updated in the region of the viewport in 
case of the FBOBackground drawing cycle.

That sounds complicated but is quite easy to check. Insert the the 
following line into the example at line position 530:

     viewport->setSize(0.4, 0.4, 0.9, 0.9);

Additionally, I do have added the following block of code into the 
reshape function after the resize call to allow proper window resizing 
in the non static render cycle of the example. It would be fine to add 
that to the dyndrawing2.cpp on the master.

     if (!static_render_mode) {
         static_render_mode = true;
         applyRenderMode();
         mgr->redraw();

         static_render_mode = false;
         applyRenderMode();
         mgr->redraw();
     }


Would you be so kind to take a look. Something I do miss but I can't 
tell what it is.

Thanks,
Johannes

P.S.: With respect to the +1 missing pixel, I think that this also 
belongs into the FBOBackground.



On 03.12.2015 18:06, Carsten Neumann wrote:
> [Back from travel]
>
>       Hello Johannes,
>
> On 2015-12-01 07:18, Johannes wrote:
>> what is the state of affairs?
>> Are you waiting for me to proceed or on a response from Gerrit?
>
> I had hoped for an opinion/reason to go one way or the other :) Thinking
> some more about this now the most convenient default behavior should
> perhaps be:
>
> // Fill FBO but only up to size of viewport. This will not scale the
> // captured image unless it is larger than the destination.
> w = osgMin(
>       static_cast<Int32>(_sfFrameBufferObject.getValue()->getWidth ()),
>       pEnv->getPixelWidth ());
> h = osgMin(
>       static_cast<Int32>(_sfFrameBufferObject.getValue()->getHeight()),
>       pEnv->getPixelHeight());
>
> osgGlBlitFramebuffer(
>       pEnv->getPixelLeft  (),
>       pEnv->getPixelBottom(),
>       pEnv->getPixelRight ()+1,
>       pEnv->getPixelTop   ()+1,
>
>       0, 0, w, h,
>
> Which is what I'm going to commit for now. If I've overlooked a use-case
> where this behavior is problematic/not helpful let me know and I'm happy
> to adjust it.
> Thank you for your contribution,
>
>       Cheers,
>               Carsten
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
>



------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to