Hi Adrian, On 7/31/07, Adrian Egli <[EMAIL PROTECTED]> wrote: > that's what i was thinking of for a while. i am still not found the best > solution as you mentioned. May other software design specialist have > quite good ideas how we should define best solution for configuration > behaviour. > > the mixture would be powerful, but i am still not sure how it sould look > like. i will review again. also how we can configure others "packages" > is not yet clear (for me) how we should solve it.
I'm in the process of writing an osgViewer::Renderer class that will be automatically attached to Camera's when they attached to View's, this Renderer is GraphicsOperation that will replace those currently created and managed internally by Viewer.cpp and CompositeViewer.cpp. When I get it working and check it should at least provide a bit of the jigsaw in terms of being able to get the SceneView/CullVisitor that is being used. The other part of the jigsaw is the provision of the default CullVisitor and DatabasePager classes, allowing the application developer to provide their own versions of these. The most straight forward approach to this would be to use a singleton ref_ptr<> for each of these classes, and when one wants to create a new CullVisitor etc one just clones the prototype. The default prototype would be the default constructed CullVisitor etc. The prototype approach is one already used by RenderBin, albeit in a slightly different way. The DatabasePager already has its own singleton, but this was previous used by osgProducer to ensure that all OsgSceneHandlers all shared the same DatabasePager. This is actually a broken usage of DatabasePager, something that osgViewer doesn't mimic. The prototype instance could be parallel to this, or just reuse it for its new purpose. The other approach is to provide a factor class in osgViewer for setting up the various default classes to use as you have done. Putting the prototypes into individual classes would actually be less intrusive than this approach, but using a factor could possible allow for a bit more flexibility. Would a prototype system be sufficient? If so then simplicity should win out. Finally there is the Viewer configuration itself, such as being able to create a configuration from a ascii input file and then pass this to the Viewer to set up. However, might it be just simpler to serialize the classes in and out instead? For instance we could serialize in and out osgViewer::View. Serializing in and out would be simpler in terms of class count in osgViewer. I don't have any definitive answers to what way is best, which is best is likely to be governed by the type of app you are working on, and there is no ideal solution. The extreme programming approach is to write it simple for the problem you have in hand and then refactor later if it turns out to not be sufficient... Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
