Hi Robert, you are right. ViewerBase::setRealizeCallback is one solution. Unfortunately, there are two problems with it. The easier one - "multiple realize callbacks": Several components of my application would like to register realize callback (rendering component, OpenCL component, and maybe one or two more). I very like NodeCallback approach for Node class that you can register any number of update, event or cull callbacks. Would you be ok with extending the realize callback with the similar functionality as NodeCallback provides, e.g. multiple called routines?
The second - "knowing your viewer": Viewer and CompositeViewer can not be queried for the instance (something like singleton approach). Thus, each module or application component that need to register realizeCallback have to somehow acquire the pointer to the Viewer. Such query functionality for Viewer/CompositeViewer instance is already missing in osgQt. osgQt needs to know Viewer and it is implemented using osgQt::setViewer() funtion. In my opinion (criticizing because I designed it) it is a hack and not a nice solution. The same would be for ShadowVolumes if they would ever be included in osgShadow. They need realizeCallback for OpenCL initialization and initialization of one or two *::Extensions needed for shadow rendering. I can create osgShadow::setViewer(ViewerBase*) function to pass Viewer in, but I have an impression that it is a hack. Anyway, I can live with it at the moment. But would you be against making ViewerBase* ViewerBase::instance() method that would return the Viewer/CompositeViewer that was constructed as f.ex. the first one? > 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. In the simplest case, the registry might be just a list of pointers to initialization routines. The initialization routines would just call *::Extensions::setupGLExtensions(). The initialization routines would register themselves to the registry (possibly std::list) by proxy objects. Just repeating what you wrote to make sure I understand you correctly. Correct me otherwise. The registry might be std::list or did you planned to put it into the container class? This would be very non-intrusive approach that would just initialize the existing *::Extensions classes (e.g. Drawable::Extensions,...) > One could then get the extension supported by calling the registry. This was not my initial intention as *::Extensions classes can be get by *::getExtensions(contextID) method (e.g. Drawable::getExtensions(contextID)). But we might design something if it would be useful. > 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. My plan was with proxies and std::list of pointers to initialization routines. We have about 18 *::Extensions classes, so it is eighteen pushes to std::list. If using inline constructors, the code will be very fast and time taken non- measurable. Calling of *::getExtensions(contextID, true) during realize for all 18 registered *::Extensions should not make any measurable impact. Creating of graphics context or making it current might take much more time. And we may make this *::Extensions initialization optional by some flag. Thanks, John On Thursday 19 of September 2013 15:20:15 Robert Osfield wrote: > 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
