Re: [osg-users] OSG_TEXTURE_POOL_SIZE issue

Here is the repro code. I made it as simple as I could. Please note that it only shows the core of the problem. One may argue that with this limit I set here in example, we have no room for last RTT texture anyway. But the problem will show up too if I increase the TEX_POOL limit to store 3 RTT

Re: [osg-users] OSG_TEXTURE_POOL_SIZE issue

> > Could you modify one to OSG examples to illustrate the problem so > others can reproduce it. I have paged databases to test against, but > not the particular FBO usage that you are using along with it. Ok. I'll try to make a repro. I do believe however that in our case we do not attach

Re: [osg-users] OSG_TEXTURE_POOL_SIZE issue

On 9 October 2016 at 11:27, Wojciech Lewandowski wrote: > Hi, Robert. Thanks for quick response. > >> Perhaps a flag in osg::Texture might be appropriate to declare whether >> this Texture is >> suitable for reuse or not. > > > Perhaps. However, I have the feeling that

Re: [osg-users] OSG_TEXTURE_POOL_SIZE issue

Hi, Robert. Thanks for quick response. Perhaps a flag in osg::Texture might be appropriate to declare whether this > Texture is > suitable for reuse or not. Perhaps. However, I have the feeling that this flag would be equivalent to checking if (image != NULL) in current 3.5.5 OSG code base

Re: [osg-users] OSG_TEXTURE_POOL_SIZE issue

Hi Wojtek, When I implemented the texture pool it never occurred to me that textures in the pool might be assigned to FBO's and not be suitable for reallocation. This is an oversight in it's design. >From the description it sounds like the texture pool scheme needs an ability to not place

[osg-users] OSG_TEXTURE_POOL_SIZE issue

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