Hi Sukender, I feel that just adding an flag into osg::Image or a callback to do the loading, would be better than requiring a whole new osg::Image subclass. This way osg::ImageStream would also benefit from the capability.
The real question is how do to wire it all up? Do we just rely on user code to invoke the loading or do we do it automatically? If we did it automatically do we the load in the thread that requires the concrete osg::Image data or do we have it do in the osgDB::ImagePager a bit like the way that PagedLOD/ProxyNode work? I guess the first step would be to do the load manually. Then take it from there. Robert. On Thu, Nov 26, 2009 at 2:49 PM, Sukender <suky0...@free.fr> wrote: > Hi Robert, hi all, > > Glad to see there's a half-solution. But I must admit I got more questions > than before! > > I guess UnrefImageAfterApply won't be called if I don't even display the > scene, so how will writers behave? If they try to read image data, that won't > work of course. > But will they simply write the image filename, and will writeImageFile() > simply do nothing with an Image having no data? > > Do you think it would be useful that we (or "I") create an osg::ImageProxy > class? Derivated from osg::Image? Or is there something that already does it? > This ImageProxy may be handled by image reader/writers by simply copying or > ignoring the file (if there is no change in the file extension). > > And about the texture, should it call something like "bool > Image::onApplied()" in UnrefImageAfterApply()? > - For Images, it would simply return true, meaning the texture should unref > the image, > - For ProxyImages, it would unload the data and return false, meaning the > texture must not unref. > > If you got better ideas, I'm all ears! > Cheers, > > Sukender > PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ > > ----- "Robert Osfield" <robert.osfi...@gmail.com> a écrit : > >> Hi Sukender, >> >> So what you are after is a proxy Image class :-) >> >> One possible tweak would be to enable th OSG to carry osg::Image >> which >> have their FileName field set, but have their data set to null so >> they >> contain no data. This is the easy part as you can do this right now >> - >> the next bit is getting the OSG to handle these osg::Image objects >> gracefully. >> >> The issue of proxy image is something that the osg::Texture's >> UnrefImageAfterApply could do with as it currently discards the whole >> osg::Image, so later on when you try to save the model there is no >> Image to provide the FileName to use to write to file you want to >> write out. >> >> So... this type of feature I can see having multiple uses beyond this >> particular plugin and worthy of support into the core OSG. >> >> Robert. >> >> On Wed, Nov 25, 2009 at 10:26 PM, Sukender <suky0...@free.fr> wrote: >> > Hi Robert and Paul, >> > >> > Oh, I'm sorry I shouldn't have written "core OSG": it's maybe more >> in osg plugins I guess... >> > I have to load huge models. By huge I mean a few thouthands >> triangles but GB of textures. Of course loading such a model simply >> leads to a std::bad_alloc. This is why I posted something about lazy >> textures/images on the mailing list: I must load the model but I don't >> want all the textures to be loaded at the same time. Depending on what >> I want to acheive I may need: >> > 1. To leave textures unloaded, but I want writers plugins to do as >> if the texture was loaded (= the writer simply says "the texture is >> abcd.jpg"). >> > 2. To load low-res textures (or maybe not loaded at all), but I want >> hi-res ones to be switched when needed, especially when writing. >> > >> > I don't expect solutions to be suited for "realtime" rendering. I >> only need those huge models to be loaded, then processed (= modifiy >> geometry without touching the texture or vice-versa, modify only a >> part of the scene...) and written to disk for future rendering. >> > >> > I got a few ideas for these needs: >> > - Add a "noTexture" option to readers that stores somewhere the path >> of the texture file, and add an option to writers to do "as if" the >> texture was loaded (but only write to the file the path of the image). >> This is why I have custom code in reader/writers. But this is clearly >> an ugly solution as I need to modify each reader/writer. >> > - Create a "lazy image", which is loaded only when accessing pixel >> data. But I don't know if it's easy, and how to do it (as discussed in >> the corresponding post). >> > >> > And a final note: all my code is given to osg-submissions once >> stable... I won't violate the OSGPL/LGPL :) >> > >> > So... any idea? If I can acheive this without modifying OSG source >> code, then I'd be very happpy... >> > >> > Thank you. >> > >> > Sukender >> > PVLE - Lightweight cross-platform game engine - >> http://pvle.sourceforge.net/ >> > >> > ----- Robert Osfield <robert.osfi...@gmail.com> a écrit : >> >> Hi Sukender, >> >> >> >> On Wed, Nov 25, 2009 at 2:26 PM, Sukender <suky0...@free.fr> >> wrote: >> >> > I'm trying to add custom code in some osg plugins (especially 3DS >> and FBX). I often have to write things like: >> >> > ADD_DEFINITIONS(-DMY_CUSTOM_CODE) in CMakeLists.txt (or #define >> MY_CUSTOM_CODE) >> >> > >> >> > #ifdef MY_CUSTOM_CODE >> >> > ... >> >> > #endif >> >> > >> >> > - Can I submit such code (without the #define of course)? >> >> > - Do you think there could be a nicer way to isolate custom >> code? >> >> > - And finally, do you think this could be a good idea to have a >> CMake option such as "USER_DEFINES"? And then: >> >> > FOREACH(CUR_DEFINE ${USER_DEFINES}) >> >> > ADD_DEFINITIONS(-D${CUR_DEFINE}) >> >> > ENDFOREACH() >> >> >> >> The OSG isn't the place for custom code, both for a licensing >> issues, >> >> build issues and maintenance issues. The question really should >> be >> >> how to avoid need for custom code in the core OSG. The use of >> custom >> >> code embedded in the OSG code would suggest that the OSG doesn't >> >> support particular features, or isn't extensible enough, or just >> the >> >> that code is tackled in the wrong way. >> >> >> >> Could you enumerate what custom code you are wanting to put it and >> >> why? Perhaps we can figure a way to avoid the need for it >> completely. >> >> >> >> Robert. >> >> _______________________________________________ >> >> osg-users mailing list >> >> osg-users@lists.openscenegraph.org >> >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > >> > _______________________________________________ >> > osg-users mailing list >> > osg-users@lists.openscenegraph.org >> > >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org