Re: [osg-users] Correct creation of the terrain

[Nickolai Medvedev]

Hi, Robert!

Where in VirtualPlanetBuilder i can get float array of the heights to process 
it in the BoxFilter?

Thank you!

Cheers,
Nickolai

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68925#68925





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG_TEXTURE_POOL_SIZE issue

[Wojciech Lewandowski]

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
textures, but will initially fill the memory with other textures (with
images of different resolution or format). Once memory size of these
initial textures + newly added RTT passes TEXTURE_POOL_SIZE, the problem
will show up when one of the RTTs is added later...

Cheers,
Wojtek

2016-10-09 20:17 GMT+02:00 Wojciech Lewandowski :

> 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 images to FBO but empty textures. And those textures are
> scraped. I wrote 'I believe' because its not all my code, maybe someone
> attached images somewhere to debug. I will double check  and include this
> case in repro if its true.
>
> Wojtek
>
> 2016-10-09 14:47 GMT+02:00 Robert Osfield :
>
>> 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 this flag would be equivalent
>> to
>> > checking if (image != NULL) in current 3.5.5 OSG code base context. I
>> don't
>> > see how already assigned and active image-less texture coud survive such
>> > Take operation without a callback (or similar mechanism) to let texture
>> > owner refresh it before apply.
>>
>> In design of the texture pool assumes that if the image is NULL then
>> the texture can't be taken.  If this isn't being upheld then it looks
>> like a bug.
>>
>> > Considering need for supporting multiple
>> > contexts and fact that such refresh callback would require action in
>> draw
>> > stage, I see this postulate (for a refresh callback) as hard to
>> implement
>> > and probably not used by users in practice. So I conclude that (image !=
>> > NULL) is probably a sufficient check for now ;-). Did I skip some use
>> case ?
>>
>> One case would be people assigning an osg::Image to textures that are
>> assigned to an FBO.
>>
>> FYI, I'm just quickly checking posts, I'm not working at a dev
>> computer so I can't review code or spend long things deeply about a
>> topic. so my response are really preliminary :-)
>>
>> 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.
>>
>> Robert.
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
#include 
#include 
#include 
#include 

osg::ref_ptr< osg::Group > BuildRTTQuad( osg::Vec4 clearColor, float posx = 0.f, float posy = 0.f, float size = 0.3f, int texture_size = 1024)
{
osg::ref_ptr< osg::Group > group = new osg::Group;

osg::ref_ptr< osg::Texture2D > texture = new osg::Texture2D;
texture->setTextureSize(texture_size, texture_size);
texture->setInternalFormat(GL_RGBA);

osg::ref_ptr< osg::Camera > camera = new osg::Camera;
camera->setClearColor(clearColor);
camera->setViewport(0, 0, texture_size, texture_size);

// Interesting observation: removing next line "makes" the view correct 
// probably attching texture to FBO before drawing with it somehow affects the problem
camera->setRenderOrder(osg::Camera::PRE_RENDER);

camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
camera->attach(osg::Camera::COLOR_BUFFER, texture);

group->addChild(camera);

osg::ref_ptr geode = new osg::Geode;
geode->addDrawable(osg::createTexturedQuadGeometry(osg::Vec3(posx, posy, 0), osg::Vec3(size, 0, 0), osg::Vec3(0, size, 0)));
geode->getOrCreateStateSet()->setTextureAttributeAndModes(0, texture);

group->addChild(geode);
return group;
}

// Run without setting OSG_TEXTURE_POOL_SIZE to see how it should look
// ( correct view shows red, green, blue quad on typical osg background )
// 
// To see the bug in action: run with OSG_TEXTURE_POOL_SIZE = 1000 
// or set the limit in code with this line 
// osg::DisplaySettings::instance()->setMaxTexturePoolSize(1000);
// ( incorrect view on my machine shows white, red, green quad
//   but I believe your incorrects results may vary because I cannot explain 
//   where white quad comes from. It may be some other undefined color... )

int main(int argc, char** 

Re: [osg-users] OSG_TEXTURE_POOL_SIZE issue

[Wojciech Lewandowski]

>
> 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 images to FBO but empty textures. And those textures are
scraped. I wrote 'I believe' because its not all my code, maybe someone
attached images somewhere to debug. I will double check  and include this
case in repro if its true.

Wojtek

2016-10-09 14:47 GMT+02:00 Robert Osfield :

> 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 this flag would be equivalent
> to
> > checking if (image != NULL) in current 3.5.5 OSG code base context. I
> don't
> > see how already assigned and active image-less texture coud survive such
> > Take operation without a callback (or similar mechanism) to let texture
> > owner refresh it before apply.
>
> In design of the texture pool assumes that if the image is NULL then
> the texture can't be taken.  If this isn't being upheld then it looks
> like a bug.
>
> > Considering need for supporting multiple
> > contexts and fact that such refresh callback would require action in draw
> > stage, I see this postulate (for a refresh callback) as hard to implement
> > and probably not used by users in practice. So I conclude that (image !=
> > NULL) is probably a sufficient check for now ;-). Did I skip some use
> case ?
>
> One case would be people assigning an osg::Image to textures that are
> assigned to an FBO.
>
> FYI, I'm just quickly checking posts, I'm not working at a dev
> computer so I can't review code or spend long things deeply about a
> topic. so my response are really preliminary :-)
>
> 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.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG_TEXTURE_POOL_SIZE issue

[Robert Osfield]

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 this flag would be equivalent to
> checking if (image != NULL) in current 3.5.5 OSG code base context. I don't
> see how already assigned and active image-less texture coud survive such
> Take operation without a callback (or similar mechanism) to let texture
> owner refresh it before apply.

In design of the texture pool assumes that if the image is NULL then
the texture can't be taken.  If this isn't being upheld then it looks
like a bug.

> Considering need for supporting multiple
> contexts and fact that such refresh callback would require action in draw
> stage, I see this postulate (for a refresh callback) as hard to implement
> and probably not used by users in practice. So I conclude that (image !=
> NULL) is probably a sufficient check for now ;-). Did I skip some use case ?

One case would be people assigning an osg::Image to textures that are
assigned to an FBO.

FYI, I'm just quickly checking posts, I'm not working at a dev
computer so I can't review code or spend long things deeply about a
topic. so my response are really preliminary :-)

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.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG_TEXTURE_POOL_SIZE issue

[Wojciech Lewandowski]

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 context. I don't
see how already assigned and active image-less texture coud survive such
Take operation without a callback (or similar mechanism) to let texture
owner refresh it before apply. Considering need for supporting multiple
contexts and fact that such refresh callback would require action in draw
stage, I see this postulate (for a refresh callback) as hard to implement
and probably not used by users in practice. So I conclude that (image !=
NULL) is probably a sufficient check for now ;-). Did I skip some use case ?

Cheers,
Wojtek


2016-10-09 9:31 GMT+02:00 Robert Osfield :

> 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 texture's assigned with FBO's into the pool, or
> at least mark them as unsuitable for reuse.  Perhaps a flag in
> osg::Texture might be appropriate to declare whether this Texture is
> suitable for reuse or not.
>
> Robert.
>
>
>
> On 8 October 2016 at 23:16, Wojciech Lewandowski
>  wrote:
> > 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
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG_TEXTURE_POOL_SIZE issue

[Robert Osfield]

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 texture's assigned with FBO's into the pool, or
at least mark them as unsuitable for reuse.  Perhaps a flag in
osg::Texture might be appropriate to declare whether this Texture is
suitable for reuse or not.

Robert.



On 8 October 2016 at 23:16, Wojciech Lewandowski
 wrote:
> 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
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org