[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
time.
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-sebastien.guay at cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
More information about the osg-users
mailing list