Hi Robert, JS and all, Ok. So, I suggest: - Image::get/setProxyLoadCallback (but isn't it the same as subloadcallbacks??) - An option for readers to not load textures but define a callback instead - Calls to "if (!data && proxy) (*proxy)();" when accessing pixel data - Image::onApplied(), as described in my previous post
Does it sounds good to you? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ----- "Robert Osfield" <[email protected]> a écrit : > 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> > 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 <[email protected]> a écrit : > >> >> Hi Sukender, > >> >> > >> >> On Wed, Nov 25, 2009 at 2:26 PM, Sukender <[email protected]> > >> 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 > >> >> [email protected] > >> >> > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> > > >> > _______________________________________________ > >> > osg-users mailing list > >> > [email protected] > >> > > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> > > >> _______________________________________________ > >> osg-users mailing list > >> [email protected] > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
