[osg-users] OSG_TEXTURE_POOL_SIZE issue

[Wojciech Lewandowski]

Hi, Robert,

I believe we encountered an issue (bug?) related to maxTexturePoolSize
handling. Our application is osgEarth + few high res overlays. We set
OSG_TEXTURE_POOL_SIZE = 350 MB. It was recommended to us as one of env vars
to let osgEarth perform optimally. Overlays are rendered as RTT cameras
(FBO + 4K x4K texture2D attachments).  Overlay textures are not refreshed
every frame. They are refreshed when some inputs change but this does not
happen every frame.  And apparently thats the problem with
maxTexturePoolSize. When we pass the texture limit and create new overlay
texture, one of currently used overlay texture GL objects gets stolen.
Suddenly new overlay uses that old GL texture object but old overlay
texture is reset, its texture object is gone and scene looks bad.

I have isolated this issue to handling of maxTexturePoolSize limit in
TextureObjectSet::takeOrGenerate(Texture* texture). I believe I understand
that this policy may work with Textures which have Images attached. Even if
such texture has its GL object reset it may allocate or reuse new one and
reload the data from Image when its applied again. But there is no such
chance for texture which was dynamically rendered in FBO (and in fact still
attached to that FBO). In our app there is a multitude of textures with
images associated. Their GL objects can be safely "borrowed" if  memory
limit is passed. But non of them is taken and unfortunately we are hit
exactly where it hurts the most: in our FBO overlays.

So my question is: Is this a bug or we missed some flag to prevent texture
from scraping in TextureObjectSet::takeOrGenerate ?

Cheers,
Wojtek Lewandowski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20161009/54856271/attachment-0001.htm>