Hi John, I don't believe it's necessary to initialize all extensions together as if you do have code paths/scene graph subgraph selection that is dependent on extension/version presence it'll be for specific extensions/versions, as you could initialize the ones of interest for you application within a Viewer Realizer operation, see osgvolume for an example of this. So without any changes to the OSG can achieve what you want with a little bit of coding.
Initializing all extension on realize is no bad thing though, one would need to have a registry of extension objects and have a proxy object for each one to register itself with the extension registry. One could then get the extension supported by calling the registry. However, this type of scheme would add extra complexity, and increase the footprint of the OSG in memory and the speed of initialize as you'd need to register all extensions even the ones that you application doesn't need. Robert. On 19 September 2013 14:43, PCJohn <[email protected]> wrote: > Hi Robert, > > I noticed one missing feature in OSG and I would be glad to discuss the > solution with you before making further steps. > > The problem: > > - In cull phase, it would be useful to be able to find out which OpenGL > extensions are supported and GLSL version available in the graphics > context. > Why anybody might need it? The programmer might want to cull different > scene > graphs for contexts with different capabilities. For example, if target > platform supports two sided stencil, it might cull one scene graph (faster > and > simpler graph), while providing another scene graph if only single side > stenciling is available. The same for geometry shaders - they might be > supported through GL_ARB_geometry_shader4 extension - requiring their own > shader code, through OpenGL 3.2 with different shader code, or programmer > might > provide still different graph for OpenGL 4.0 geometry shader, profiting > from > multiple invocations capability introduced in GLSL 4.0. However, to make > this > work, we need to get graphics context capabilities in cull phase. > > Proposed solutions (for you to judge and possibly suggest the best > approach): > > - To avoid extensive changes to OSG, I think, we can use the existing > approach > of "Extensions" nested class, like Drawable::Extensions, > Stencil::Extensions, > etc. The advantage of the approach is that the user may detect whatever he > may > want or think of inside Extensions::setupGLExtensions() while the users are > already familiar with this concept. The problem with the Extensions class > is > that it is not initialized until the first getExtensions() call inside draw > phase. Usually it means that we can not get valid Extensions instance in > the > first frame cull phase. And it is still not guaranteed to be initialized > for > the second frame. > > - My idea, and I ask your counsel, was to auto-initialize all *::Extensions > instances for any new graphics context that is realized in the > application. If > this might me overkill for some reason, we might provide some per-graphics- > context flag for the user and he might choose which context should use this > functionality and which should not. > > - To implement such functionality, we might use proxy approach and register > all *::Extensions classes in some global list. Then, we might, for > instance, > go through the list and call setupGLExtensions() for all registered > *::Extensions classes. Such procedure would be done whenever a context is > realized. > > - Another approach might be to give the user the possiblity to register > GraphicsContext::realizeCallback (something like swapCallback but for > realize). This way, the user may initialize required *::Extensions classes > himself. The disadvantage of this approach is that the user would be > required > to write some code (the initialization code and callback registration). The > proxy approach mentioned above would do the job for him automatically. > > Before discussing implementation details, do you think that the proposal is > reasonable or would you prefer different approach for the problem? > Essentially, > it is about ability to know graphics context capabilities during cull > phase to > be able to cull the scene graph that is the best suitable for the graphics > context. > > Thanks for the answer and keeping OSG growing. > John > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
