Hi Sukender, I currently feel the runtime flexibility and encapsulation associated with a node callback approach is far more compelling a solution than the intrusive changes to osg::Image. So I'm going not merge your changes to osg::Image as is. I believe it's appropriate to have a bash at developing a node callback and see how well it fairs.
> However, I use an "osgconv"-style app: it reads and then writes scenes, > without rendering anything. I thus don't have any particular traversal, so I > don't know how to do it with your idea. > The goal of such an app (and osgconv too!?) is to be able to convert a scene > with several GB of textures (in hundreds/thousands files). The way it works > right now (with this Proxy image implementation) is roughly: > - Load the scene without textures (textures are proxies) > - Write the scene: if the texture name haven't changed (hence the requirement > of two filenames!), simply copy the original file. Else load the image, write > the loaded image with the appropriate writer, and unload the image. I don't think it is osgconv role to handle all possible types of usages that end users might want to throw at it. The OSG application set are are much examples of what the OSG coding as they are utilities. If end users push osgconv beyond it's normal limits then I don't have a problem with users just writing their own custom conversion applications, in fact this has been my expectation over the years. It's not a difficult task to read, traverse and write our scene graphs, but.. trying to handle all different types of conversion tasks that end users might want is not an easy or reasonable task. This is not to say the a node callback approach needn't be able to handle what you are after w.r.t osgconv or similar tools. FYI, osgconv does an optimization traversals before writing out the loaded model. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
