Hi Carsten, do you know if and how I can get the currently bound frame buffer object id from OpenGL?
Thanks, Michael -------- Original-Nachricht -------- > Datum: Mon, 28 Nov 2011 10:38:34 -0600 > Von: Carsten Neumann <carsten_neum...@gmx.net> > An: opensg-users@lists.sourceforge.net > Betreff: Re: [Opensg-users] FBO Window > Hello Michael, > > On 11/28/2011 09:52 AM, Michael Raab wrote: > >> I think from a practical standpoint this can work. The only issue I see > >> is that a Window in OpenSG is representing an OpenGL context, so in > that > >> sense a FBOWindow does not fit well into the picture. The FBOWindow > >> would probably need to contain a pointer to the "real" Window and > >> forward certain calls to it to make it work in places where OpenSG > >> accepts windows. > >> An alternative could be to separate the FBO and the FBOViewport by > >> creating a FrameBufferObject class that represents the FBO and can be > >> shared by multiple FBOViewports. > > > > Hmm, ok. What I'm searching for is a solution that would both fit for me > but as well for the OpenSG community in general. > > thanks, it's appreciated! > > > For me both solutions would be ok, but in my opinion creating a > 'FBOWindow' class may require less programming work as the current FBOViewport > implementation (which is huge) can be left untouched. > > you are probably right, although a large portion of code in FBOViewport > is dealing with emulating FBO functionality if it is not supported by > the hardware, the hardware accelerated code path is actually not that > much code. Splitting some of that functionality into more helper > functions instead of ~1k line monsters would be a great cleanup :) > > > Regarding cleanness of the approach I would rely on your knowledge of > the overall OpenSG approach. > > So what do think about the direction to go? > > Well, we are talking about 1.x here, and this is a part that has changed > significantly in 2.0 to address the shortcomings you are running into. > To me backporting all that to 1.x does not seem like the best use of > time here and is quite a bit of work. So, if you like to do something > that improves the situation for 1.x users, splitting out the FBO from > the FBOViewport seems like a reasonable compromise to me [1]. > If that exceeds the amount of time you can commit to, I'd say pick > whatever solves your immediate needs, which may well be the FBOWindow > solution, although IMHO it does not fit well into the overall system [2]. > > Cheers, > Carsten > > [1] Keeping existing code from breaking may make this more tricky > unfortunately :-/ > > [2] We can still add it to the repository, although I'd probably put a > big warning sticker on it ;) > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Opensg-users mailing list > Opensg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensg-users -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
