Hi Robert, > 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.
You're certainly right. > 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. Of course. Merging when having doubts wouldn't be a good idea. Unfortunately I absolutely don't see how to reach my goals with such a method. Have you got any hint or clue that might help me to start? > > 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. Well, I don't want to change osgconv goals. It's far better to keep it reasonably small, IMO. I was just saying my app is a bit like osgconv, handling big data in addition. However, to be able to do it in a "nice" (term is subject to discussion!) way, I found it better to go inside OSG (hence the submission). My code works as expected, and can (for those who want) be integrated in osgconv with very few lines of code, but of course it doesn't necessarily fit. > 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. Maybe... maybe not! As said above, I sincerely don't know how to do without the callbacks. Maybe can I/we find a better design while keeping them? > FYI, > osgconv does an optimization traversals before writing out the loaded > model. > > Robert. Yes, I know that. My app doesn't call Optimizer to avoid changing too much the original structures. Anyway, thanks for reviewing, and thanks for your opinion on all of this. Sukender _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
