[osg-users] Custom code in OSG core

Jean-Sébastien Guay jean-sebastien.guay at cm-labs.com
Thu Nov 26 06:09:46 PST 2009

Hi Robert, Sukender,

> 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.

I had also considered making a proxy image class eventually for this 
exact reason. If you search the archives for "proxy image", Sukender, 
you should find the discussion I and Robert had about this a while ago.

An additional benefit would be when doing runtime creation/destruction 
of contexts. Right now, if you do that, you need to turn off 
unrefImageAfterApply, or else in the new contexts the textures will be 
missing. But this completely removes the benefit of unrefImageAfterApply 
of course, so you have duplicate image data on the CPU memory and GPU 
memory even if you never (or seldom) create new contexts.

So with a proxy image class, you could run a visitor on your models at 
load time which would replace all images with this proxy image, and then 
keep unrefImageAfterApply turned on. Then, the image data would only be 
on the GPU, and at the time when you create a new context, the image 
would be reloaded by the proxy image, applied to the Texture in the new 
context, and unreffed again. Since creating new contexts is done seldom, 
the cost of reloading the image is small and you'd gain the CPU memory 
back afterwards.

Anyways, that's to say that a proxy image was on my to do list (my "free 
time" to do list of course, so it will take some time to get to it :-( ) 
but if you get to it first it could help you and help others at the same 

Jean-Sebastien Guay    jean-sebastien.guay at cm-labs.com

More information about the osg-users mailing list