Hi Robert, > 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.
Well your choice of focusing on maintenability and performance is a wise one, and I agree with you. Do you think there may be a solution (such as splitting/inlining calls) in my current implementation to make the proxy loading an acceptable overhead? And/or do you want me to propose another submission with #if directives to make this option available only to those who want? This could be a "solution", don't you think? I can't bu sure of how users could use it, but I think some users may find purely rendering-oriented applications to such a code. Maybe that may help some. > 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. I actually do some processing with big models, and AFTER that I handle them as "usual". But having "nodes callbacks + chunks" sounds fine. I'll keep all your advice for further reference! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ > 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 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
