Hi Robert, thanks for looking into the submission. The motivation behind is following:
High level classes (such as those of osgShadows) often maintain two sets of StateSets. One is used when particular feature is not available on the graphics context while the second is used when all the required features are available. Examples: - two sided stencil support (if available, let's use StencilTwoSided, if not fall back to Stencil and two pass solution) - tesselation shaders (if available, let's use them in cull traversal, otherwise, use "compatibility" stateSet with legacy shaders). - StatsHandler needs to know whether TimerQuery extension is supported or not. If supported, it shows GPU time, otherwise no. For the first frame the information is not available, often forcing StatsHandler to rebuild scene for the second frame. (This makes even the code difficult to read and maintain.) - much more feature dependent examples Currently, the programmer usually starts to think how to get OpenGL context feature set at cull time. He usually finish by: - waiting to draw phase, determining the feature support in particular GraphicsContext, and doing "feature aware" cull afterwards. So, there is one frame rendered without using particular OpenGL feature, possibly causing artifacts or FPS spikes. - querying all required extensions on window realize. This has one big disadvantage that there are circumstances when we do not know the required feature set beforehand, such as when whole scene is going to be loaded from a file. My approach resolves the whole problem just on the beginning by giving the programmer possibility to query supported extensions in cull phase. In my opinion, it does not break OSG design as cull traversal is always bound to particular GraphicsContext and I just added functionality to retrieve the extensions from GraphicsContext. > he approach involves too much similar code and function being spread out > over more classes. Yes. Actually, I was considering to remove the functionality that is going be redundant / obsolete. I just decided to wait until you accept the submission. It is definitely not a good idea to maintain similar functionality two times. Cheers, John > ------------ Original message ------------ > From: Robert Osfield <[email protected]> > Subject: Re: [osg-submissions] New GLExtension architecture > Date: 2. 11. 2010 13:38:33 > ---------------------------------------- > Hi John, > > I've just done a review of your changes for getting extensions from > GraphicsContext. For now I'm not going to merge as I believe the > approach involves too much similar code and function being spread out > over more classes. This will lead to more difficult to maintain code, > larger footprint in memory and potential for user confusion of how and > where to query extension. > > I would very much like to see a better extension setup and querying > system for the OSG, I don't believe you changes are quite that yet. > Hopefully in the next week I'll have a chance to look at this issue > again. To help me in this process could you please explain what > specific problem you were trying to address in your changes - for > instance what on the OSG users side is difficult right now that you > were trying to address, or what problem in the OSG internal > implementation that you were trying to address. > > Thanks, > Robert. > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph > .org _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
