Good morning, just a final update on this issue, now its working: - added a baseFramebufferID in FrameBufferObject::deactivate - removed texBuf->setReadBack(true); when creating the fbo, this was messing with rendering to texture.
thanks for the help! best regards, Victor On Fri, Dec 11, 2020 at 7:51 PM Victor Haefner <victor.haef...@gmail.com> wrote: > Hmm, I realized the simplestage does also allow to register pre/post > render functors > In the pre render function the active fbo corresponds to the stage fbo > I the post render function too. > When changing the fbo in the pre render function the stage draws to the > widget as expected. > When changing it in the post rendering it does nothing. > In OSGRenderPartition.cpp, in doExecution, the postrender functions are > called before _pRenderTarget->deactivate > I guess the fbo gets deactivated then.. > > furthermore the active FBO during renderEnter and renderLeave corresponds > to the gtk fbo, > thus replacing them wont help. > > I may still try with a stage as you suggested, > > best regards, > Victor > > On Fri, Dec 11, 2020 at 5:48 PM Carsten Neumann < > carsten.p.neum...@gmail.com> wrote: > >> Hello Victor, >> >> On Fri, Dec 11, 2020 at 10:54 AM Victor Haefner <victor.haef...@gmail.com> >> wrote: >> >>> ..hmm, I think thats what glarea is already doing, and rendering most >>> scenes works perfectly. >>> It is only when using a stage that the gtk fbo get unbound. >>> >> >> right, I meant putting a Stage at the top of your scene graph so that >> OpenSG does not attempt to render anything into the default frame buffer >> and manually blit that image to the GtkGLArea. >> >> >>> I thought I could rebind them on renderLeave of the stage, but >>> subclassing it is tricky ;) >>> Any hints on how to do this without necessarly registering a new type in >>> OpenSG? >>> I just want to override the renderLeave function. >>> >>> Maybe is there another way by messing with the render action? >>> I'm not sure.. >>> >> >> I believe there is a CallbackStage (or similar name) that allows you to >> execute code before/after the subtree below that stage is rendered; that >> should allow you to bind the Gtk framebuffer object. >> >> Cheers, >> Carsten >> >> >> >>> On Thu, Dec 10, 2020 at 11:18 PM Carsten Neumann < >>> carsten.p.neum...@gmail.com> wrote: >>> >>>> Hello Victor, >>>> >>>> hmm, I can't really claim to have any understanding of how this works >>>> any longer, but a quick look at >>>> Source/System/Window/FrameBufferObjects/OSGFrameBufferObject.cpp:740 >>>> suggests that it always binds the default framebuffer (i.e. >>>> glBindFramebuffer(0)) when deactivating an FBO - it doesn't look like there >>>> is a customization point for this behaviour. >>>> Can you perform all your OpenSG rendering into an FBO and when it has >>>> completed manually blit to the GtkGLArea? It's a bit unnecessary work >>>> performing that extra copy, but may be the quickest way to get it running. >>>> >>>> Cheers, >>>> Carsten >>>> >>>> On Thu, Dec 10, 2020 at 3:24 PM Victor Haefner < >>>> victor.haef...@gmail.com> wrote: >>>> >>>>> Hello everyone, >>>>> >>>>> I just ported my application from Gtk2 to Gtk3. >>>>> Until now I used gtkglext to render with OpenSG into a widget. >>>>> There is a gtk3 port of gtkglext, but I had artifacts that I couldn't >>>>> get rid of. >>>>> So I tried GtkGLArea, it works, but I have a problem when using >>>>> framebuffers (for example for texture rendering). >>>>> GtkGLArea does not render directly to the window but instead to a >>>>> framebuffer and later cairo drawns the framebuffer to the widget vie a >>>>> shared GL context.. >>>>> When I use a framebuffer from OpenSG then once the rendering to it is >>>>> done, OpenSG resets the buffer with glBindFramebuffer(0) if I recall >>>>> correctly. >>>>> Normally this would be fine, but with the GtkGLArea it results in a >>>>> black window. >>>>> Instead It would need to bind to the framebuffers from the gtkglarea. >>>>> There is a convenience function to do this, how can I tell OpenSG to >>>>> call it after using a framebuffer? >>>>> >>>>> best regards, >>>>> Victor >>>>> _______________________________________________ >>>>> Opensg-users mailing list >>>>> Opensg-users@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/opensg-users >>>>> >>>> _______________________________________________ >>>> Opensg-users mailing list >>>> Opensg-users@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/opensg-users >>>> >>> _______________________________________________ >>> Opensg-users mailing list >>> Opensg-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/opensg-users >>> >> _______________________________________________ >> Opensg-users mailing list >> Opensg-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/opensg-users >> >
_______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
