Hi Sukender, I'm not clear on why you wanting to encapsulate everything so tightly. Why can't you just load your data and process how you want to keeping in mind whether you've deliberately switched off the normal loading of images and are instead relying upon a proxy image scheme. I would have thought if you load you data, and then want to write it out you just do your own traversal and for the loads. This custom traversal code do all the optimization work/writing out to disk you want as well.
Robert. In terms of the write image plugins coping with an empty image, On Wed, Jan 13, 2010 at 10:38 PM, Sukender <[email protected]> wrote: > Hi Robert, > > I really like your solution... But I still got a problem! > I'm sorry for wasting you so much time for this, but I must miss many hours > of sleep(*) because I still don't know how to make > writeFileNode(readFileNode(X)) work without getting a std::bad_alloc in my > face (with many images). Worse case: > writeFileNode(modifyMyScene(readFileNode(X))). Say modifyMyScene() is a call > to the atlas builder in osgUtil::Optimizer for our example. > 1. I can easily set "empty" images instead of loading them and add a node > callback somewhere, but > 2. I don't know how to make modifyMyScene() work with images without > crashing, and > 3. I don't know how to make writers work correctly with empty images, as > they'll never call any node callback. > Any idea? > > (*) Kids should rather sleep at *NIGHT*. Or maybe I'm simply dumb... > > Sukender > PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ > > ----- "Robert Osfield" <[email protected]> a écrit : > >> Hi Sukender, >> >> On Wed, Jan 13, 2010 at 2:57 PM, Sukender <[email protected]> wrote: >> > 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? >> >> My thought is that one could use either an update or a cull callback >> depending upon what ones goals are. One could have one or more of >> these callbacks assigned to loaded subgraphs, for instance it could >> be >> as fine grained as being attached to a node above a geode through to >> the topmost node of the subgraph being loaded by a plugin. The later >> is probably how I'd expect it to be used most often. >> >> In the callback I would expect to have a list of osg::Image that need >> filling in, or a list of osg::Texture and the filenames of the files >> that need to be attached to them. In the case of the a synchronous >> load approach the callback would be invoked during traversal and load >> all the required images and assign them to Textures if required, once >> all the loads are done the list of images to load would be cleared >> and >> the traversal of the subgraph then done as usual. >> >> If one wanted to attach this callback to the cull traversal then >> you'd >> need to be mindful of the possibility of multiple cull traversals >> running in a parallel so you'd want to mutex lock access to it to >> serialize the various threads going through while the loading is >> underway. If you want to make the constant frame rate callback then >> you'd need to think about having a background thread to do the >> loading >> and until the items are loaded you'd disable the traversal of the >> subgraph. >> >> Another variation on this theme would be to use a custom group node >> that override the traverse() method and then is able to control >> traversal of it's subgraph for all NodeVisitor types and possible >> handle the different types of traversal differently depending upon >> the >> mode of operation that has been requested. >> >> As well as writing of this callback/node you'd also want to construct >> them and attach them to loaded scene graphs. The ReadFileCallback >> callback that you wrote for intercepting readImage calls could be >> adapted to fill in the required images, and attach the >> nodecallback/node by intercepting the readNode call. >> >> I don't think the basic callback would need to be very complicated, >> should be easily doable in a hundred lines of code. The >> multi-threaded versions will be be complex, but one could leave the >> door open to such implementations as a later add-on. >> >> Robert. >> _______________________________________________ >> osg-submissions mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
