Hi Sukender, Making intrusive changes to existing class or algorithms for a feature that it very niche isn't appropriate. You are the first user to really push the OSG in this direction, and while I want to support what you are trying to achieve it can't be at the detriment of maintainability or performance of existing code.
Given what you are doing is not something that most users will ever need to do then the fact that it might be more awkward for you to achieve is unfortunate but it's a reasonable tradeoff given the above. For me it really sounds like it's the database conversion that you are pushing and having problems with, it's not a rendering issue, the OSG's focus is rendering lib rather than a database process tool . For large databases I would normally recommend breaking the databases up it paged databases. In your case breaking the model up into manageable chucks might also be a good path forward. These chunks could simply by subgraphs of a large scene graph that you deal with one by one. These chunks could as coarse grained as the whole scene graph or as fine grained as dealing with single osg::Geode. In managing the chunks you could traverse the scene graphs and process them loading what is required, then deallocate them. Robert. On Thu, Jan 14, 2010 at 12:45 PM, Sukender <[email protected]> wrote: > Hi Robert, > > Well my goal was to avoid modifying existing algorithms. Say I want to > generate an atlas of textures on a scene with proxy images: > 1. If I don't traverse the graph, the atlas builder will fail, or crash when > accessing images' data. > 2. If I traverse the graph and load all the images, then I'll run out of > memory. > 3. If I traverse and partially load images befaore calling the atlas builder, > then it'll be as the first case. > > What should be done, IMHO, is to allow the algorithm to load necessary images > while unloading unnecessary data. But to make it work I found only two > methods: > 1. Change all functions using images to make them aware of proxies (which is > ugly) > 2. Change images to make them transparently behave like this. > I don't see how to call the "special traveral" to make it work. > > Thoughts? > > Sukender > PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ > > ----- "Robert Osfield" <[email protected]> a écrit : > >> 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 > _______________________________________________ > 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
