Hi Dirk, we still use it as the core of our VR System, its perfect when working with distributed systems. We even recently worked on synchronizing parts of the scenegraph by filtering the changelist thus enabling collaborative applications.
hehe, I tried to add such an ID, it does work partially, at least the scene is rendered to the widget, but the resulting texture is flickering, I'd say 50% of the time it renders properly to the texture, 50% is just a gray image. .. and it felt a bit too hacky. I found the registerLeaveFunction and got to override the stage renderLeave, but setting the fbo there didn't help, widget stays black. best regards, Victor On Fri, Dec 11, 2020 at 5:42 PM Dirk Reiners <dirk.rein...@gmail.com> wrote: > Hi Victor, > > Wow, this must be the first time in 15 years or so that I look at OpenSG > code... ;) Thanks to Carsten and Gerrit for keeping it alive, and you and > the others for still using it! > > Yes, subclassing is tricky, that was always a weakness of OpenSG. What may > be easier is extension. How about adding a 'baseFramebufferID' field to > indicate which FBO to use instead of 0? > > Just my $.02... > > Yours > > Dirk > > > On Fri, Dec 11, 2020 at 10:54 AM Victor Haefner <victor.haef...@gmail.com> > wrote: > >> Hello Carsten, >> >> thanks for the quick reply! >> ..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. >> >> 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.. >> >> best regards, >> Victor >> >> 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
