<div dir="ltr">Hi, Robert,<div><br></div><div><div>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. </div><div><br></div><div>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.</div></div><div><br></div><div>So my question is: Is this a bug or we missed some flag to prevent texture from scraping in TextureObjectSet::takeOrGenerate ?</div><div><br></div><div>Cheers,</div><div>Wojtek Lewandowski</div></div>