Re: [osg-users] Texture Caching Problem with 3.6.3/4

[OpenSceneGraph Users]

On Tue, 31 Mar 2020 at 15:20, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Do you  have hangouts
>
Whom are asking this question of?  There are thousands of people in the OSG
community.

If you are referring to me then, not for general public OSG support, if I
did I'd spend my whole life inundated with OSG users want free help with
every little problem.  Support via the public user group at least helps
others with similar problems and is of beneficial to everyone.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[OpenSceneGraph Users]

Do you  have hangouts

On Mar 31, 2020 14:42, "OpenSceneGraph Users" <
osg-users@lists.openscenegraph.org> wrote:

> Hi Robert,
> I stumbled upon this topic while I was looking for a similar problem that
> I am having using osgEarth in an osgQt viewer. I am posting this message
> here because I think that the two problems might be related and I hope that
> you could help me. I am using OpenSceneGraph-3.6.5 and osgearth-2.10.1.
>
> I noticed it while I was coding my application but recently I saw that the
> same error messages are displayed by osgviewerQt as well.
> I am using a demo.earth file that uses local geotiff files stacked in a
> composite image and, above that, I placed the following cache configuration:
>
> 
>   
> /home/emanuele/mapsCache
>   
> 
>
> If I run "osgviewer demo.earth", the globe is shown without any error
> messages but if I run "osgviewerQt demo.earth", it happens something
> similar to what Greg described in his post: if I run osgviewerQt with an
> empty cache folder, no messages are printed but when I run osgviewerQt
> again, a few error messages are printed... and I am not sure if the program
> is loading images from the cache folder or from the specified files. The
> messages disappear if I remove the cache section from the earth file.
> They are the following:
>
> [osgEarth]* JSON decoding error: * Line 1, Column 67
>   Missing '}' or object member name
>
> [osgEarth]* [TerrainLayer] Layer "image" Metadata appears to be corrupt.
> [osgEarth]* JSON decoding error: * Line 1, Column 67
>   Missing '}' or object member name
>
> [osgEarth]* [TerrainLayer] Layer "Elevation2" Metadata appears to be
> corrupt.
> [osgEarth]* JSON decoding error: * Line 1, Column 67
>   Missing '}' or object member name
>
> [osgEarth]* [TerrainLayer] Layer "Elevation1" Metadata appears to be
> corrupt.
> [osgEarth]* JSON decoding error: * Line 1, Column 67
>   Missing '}' or object member name
>
> [osgEarth]* [TerrainLayer] Layer "world-tiff" Metadata appears to be
> corrupt.
> [osgEarth]* JSON decoding error: * Line 1, Column 67
>   Missing '}' or object member name
>
> [osgEarth]* [TerrainLayer] Layer "SermonetaWide" Metadata appears to be
> corrupt.
> [osgEarth]* JSON decoding error: * Line 1, Column 67
>   Missing '}' or object member name
>
> The first error messages are printed as soon as I run the program, the
> following appear when I zoom on the map.
> I have already talked with Glenn Waldron (osgEarth) about this messages
> and he thinks that, since osgviewer is working fine, they might be related
> to some threading issues in osgQt.
>
> I'd really appreciate your help. Thank you,
>  Emanuele
>
> Il giorno lunedì 16 dicembre 2019 18:08:34 UTC+1, Robert Osfield ha
> scritto:
>>
>> Hi Greg,
>>
>> Today I worked on improving the ObectCache::releaseGLObjects()
>> implementation so that it removes objects in the scene that are Texture or
>> contain Textures in their subgraph, where the Texture no longer have any
>> associated osg::Image. I believe this resolves the usage case :
>>
>>   1.  Load the scene graph, with the Texture UnRefImageAfterApply
>> setiings are set to UnrefImageAfterApply, with the loaded textures/scene
>> graphs being cached in the osgDB::ObjectCache.
>>   2. Render the scene graph, resulting the in the scene graph images
>> being unref'd from their Textures.
>>   3. Close the Window, which cleans up the scene graph GL obects by
>> calling releaseGLObjects()
>>   4. Load a new scene graph with textures/objects loaded from disk and
>> where possible from the ObjectCache if previously loaded and cache,  Got
>> back to 2. (Rendering etc.)
>>
>> I created an example that follows all these steps and it reproduced the
>> problem with the textures appearing black on the second time around when
>> loading an OpenFlight database.  With the fixes to
>> ObjectCache::releaseGLObjects() the unref'd images are automatically
>> removed from the cache as part of step 3. above, so that they aren't shared
>> any more, instead new copies are loaded from disk with their image in place.
>>
>> This fix is checked into the OpenSceneGraph-3.6 branch.  The commit is:
>>
>> https://github.com/openscenegraph/OpenSceneGraph/commit/9ae4
>> 7b921b2184788e6efe85692908bd0ba900a2
>>
>> Could you please test this out.  You should be able to remove your own
>> manually clearing of the ObjectCache now, as it will be done automatically
>> when required.
>>
>> Cheers,
>> Robert.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenSceneGraph Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osg-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/osg-users/93b6ffd8-b2e6-43c0-a6c8-3ef11949bbaf%40googlegroups.com
> 
> .
>
> 

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[OpenSceneGraph Users]

HI Emanuele,

I'm not the author or maintainer of osgQt, and don't have Qt expertise.  If
there is an issue with interaction with Qt integration I'm really not the
best person to look at it.

My only guess given the parsing error, any chance that it a locale issue
with parsing ascii files in one system but then reading with another.  This
isn't a Qt specific issue, but perhaps Qt is changing the locale.

Robert.

On Tue, 31 Mar 2020 at 14:42, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Hi Robert,
> I stumbled upon this topic while I was looking for a similar problem that
> I am having using osgEarth in an osgQt viewer. I am posting this message
> here because I think that the two problems might be related and I hope that
> you could help me. I am using OpenSceneGraph-3.6.5 and osgearth-2.10.1.
>
> I noticed it while I was coding my application but recently I saw that the
> same error messages are displayed by osgviewerQt as well.
> I am using a demo.earth file that uses local geotiff files stacked in a
> composite image and, above that, I placed the following cache configuration:
>
> 
>   
> /home/emanuele/mapsCache
>   
> 
>
> If I run "osgviewer demo.earth", the globe is shown without any error
> messages but if I run "osgviewerQt demo.earth", it happens something
> similar to what Greg described in his post: if I run osgviewerQt with an
> empty cache folder, no messages are printed but when I run osgviewerQt
> again, a few error messages are printed... and I am not sure if the program
> is loading images from the cache folder or from the specified files. The
> messages disappear if I remove the cache section from the earth file.
> They are the following:
>
> [osgEarth]* JSON decoding error: * Line 1, Column 67
>   Missing '}' or object member name
>
> [osgEarth]* [TerrainLayer] Layer "image" Metadata appears to be corrupt.
> [osgEarth]* JSON decoding error: * Line 1, Column 67
>   Missing '}' or object member name
>
> [osgEarth]* [TerrainLayer] Layer "Elevation2" Metadata appears to be
> corrupt.
> [osgEarth]* JSON decoding error: * Line 1, Column 67
>   Missing '}' or object member name
>
> [osgEarth]* [TerrainLayer] Layer "Elevation1" Metadata appears to be
> corrupt.
> [osgEarth]* JSON decoding error: * Line 1, Column 67
>   Missing '}' or object member name
>
> [osgEarth]* [TerrainLayer] Layer "world-tiff" Metadata appears to be
> corrupt.
> [osgEarth]* JSON decoding error: * Line 1, Column 67
>   Missing '}' or object member name
>
> [osgEarth]* [TerrainLayer] Layer "SermonetaWide" Metadata appears to be
> corrupt.
> [osgEarth]* JSON decoding error: * Line 1, Column 67
>   Missing '}' or object member name
>
> The first error messages are printed as soon as I run the program, the
> following appear when I zoom on the map.
> I have already talked with Glenn Waldron (osgEarth) about this messages
> and he thinks that, since osgviewer is working fine, they might be related
> to some threading issues in osgQt.
>
> I'd really appreciate your help. Thank you,
>  Emanuele
>
> Il giorno lunedì 16 dicembre 2019 18:08:34 UTC+1, Robert Osfield ha
> scritto:
>>
>> Hi Greg,
>>
>> Today I worked on improving the ObectCache::releaseGLObjects()
>> implementation so that it removes objects in the scene that are Texture or
>> contain Textures in their subgraph, where the Texture no longer have any
>> associated osg::Image. I believe this resolves the usage case :
>>
>>   1.  Load the scene graph, with the Texture UnRefImageAfterApply
>> setiings are set to UnrefImageAfterApply, with the loaded textures/scene
>> graphs being cached in the osgDB::ObjectCache.
>>   2. Render the scene graph, resulting the in the scene graph images
>> being unref'd from their Textures.
>>   3. Close the Window, which cleans up the scene graph GL obects by
>> calling releaseGLObjects()
>>   4. Load a new scene graph with textures/objects loaded from disk and
>> where possible from the ObjectCache if previously loaded and cache,  Got
>> back to 2. (Rendering etc.)
>>
>> I created an example that follows all these steps and it reproduced the
>> problem with the textures appearing black on the second time around when
>> loading an OpenFlight database.  With the fixes to
>> ObjectCache::releaseGLObjects() the unref'd images are automatically
>> removed from the cache as part of step 3. above, so that they aren't shared
>> any more, instead new copies are loaded from disk with their image in place.
>>
>> This fix is checked into the OpenSceneGraph-3.6 branch.  The commit is:
>>
>>
>> https://github.com/openscenegraph/OpenSceneGraph/commit/9ae47b921b2184788e6efe85692908bd0ba900a2
>>
>> Could you please test this out.  You should be able to remove your own
>> manually clearing of the ObjectCache now, as it will be done automatically
>> when required.
>>
>> Cheers,
>> Robert.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenSceneGraph Users" group.
> To unsubscribe from this 

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[OpenSceneGraph Users]

Hi Robert,
I stumbled upon this topic while I was looking for a similar problem that I 
am having using osgEarth in an osgQt viewer. I am posting this message here 
because I think that the two problems might be related and I hope that you 
could help me. I am using OpenSceneGraph-3.6.5 and osgearth-2.10.1.

I noticed it while I was coding my application but recently I saw that the 
same error messages are displayed by osgviewerQt as well.
I am using a demo.earth file that uses local geotiff files stacked in a 
composite image and, above that, I placed the following cache configuration:


  
/home/emanuele/mapsCache
  


If I run "osgviewer demo.earth", the globe is shown without any error 
messages but if I run "osgviewerQt demo.earth", it happens something 
similar to what Greg described in his post: if I run osgviewerQt with an 
empty cache folder, no messages are printed but when I run osgviewerQt 
again, a few error messages are printed... and I am not sure if the program 
is loading images from the cache folder or from the specified files. The 
messages disappear if I remove the cache section from the earth file.
They are the following:

[osgEarth]* JSON decoding error: * Line 1, Column 67
  Missing '}' or object member name

[osgEarth]* [TerrainLayer] Layer "image" Metadata appears to be corrupt.
[osgEarth]* JSON decoding error: * Line 1, Column 67
  Missing '}' or object member name

[osgEarth]* [TerrainLayer] Layer "Elevation2" Metadata appears to be 
corrupt.
[osgEarth]* JSON decoding error: * Line 1, Column 67
  Missing '}' or object member name

[osgEarth]* [TerrainLayer] Layer "Elevation1" Metadata appears to be 
corrupt.
[osgEarth]* JSON decoding error: * Line 1, Column 67
  Missing '}' or object member name

[osgEarth]* [TerrainLayer] Layer "world-tiff" Metadata appears to be 
corrupt.
[osgEarth]* JSON decoding error: * Line 1, Column 67
  Missing '}' or object member name

[osgEarth]* [TerrainLayer] Layer "SermonetaWide" Metadata appears to be 
corrupt.
[osgEarth]* JSON decoding error: * Line 1, Column 67
  Missing '}' or object member name

The first error messages are printed as soon as I run the program, the 
following appear when I zoom on the map.
I have already talked with Glenn Waldron (osgEarth) about this messages and 
he thinks that, since osgviewer is working fine, they might be related to 
some threading issues in osgQt.

I'd really appreciate your help. Thank you,
 Emanuele

Il giorno lunedì 16 dicembre 2019 18:08:34 UTC+1, Robert Osfield ha scritto:
>
> Hi Greg,
>
> Today I worked on improving the ObectCache::releaseGLObjects() 
> implementation so that it removes objects in the scene that are Texture or 
> contain Textures in their subgraph, where the Texture no longer have any 
> associated osg::Image. I believe this resolves the usage case :
>
>   1.  Load the scene graph, with the Texture UnRefImageAfterApply setiings 
> are set to UnrefImageAfterApply, with the loaded textures/scene graphs 
> being cached in the osgDB::ObjectCache.
>   2. Render the scene graph, resulting the in the scene graph images being 
> unref'd from their Textures.
>   3. Close the Window, which cleans up the scene graph GL obects by 
> calling releaseGLObjects()
>   4. Load a new scene graph with textures/objects loaded from disk and 
> where possible from the ObjectCache if previously loaded and cache,  Got 
> back to 2. (Rendering etc.)
>
> I created an example that follows all these steps and it reproduced the 
> problem with the textures appearing black on the second time around when 
> loading an OpenFlight database.  With the fixes to 
> ObjectCache::releaseGLObjects() the unref'd images are automatically 
> removed from the cache as part of step 3. above, so that they aren't shared 
> any more, instead new copies are loaded from disk with their image in place.
>
> This fix is checked into the OpenSceneGraph-3.6 branch.  The commit is:
>
> 
> https://github.com/openscenegraph/OpenSceneGraph/commit/9ae47b921b2184788e6efe85692908bd0ba900a2
>
> Could you please test this out.  You should be able to remove your own 
> manually clearing of the ObjectCache now, as it will be done automatically 
> when required.
>
> Cheers,
> Robert.
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/93b6ffd8-b2e6-43c0-a6c8-3ef11949bbaf%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[Greg D]

Robert,

Thanks for the fix.  That solved the problem.  I had previously worked 
around it with your suggestion to disable texture caching.

unsigned int options = osgUtil::Optimizer::ALL_OPTIMIZATIONS;
options ^= osgUtil::Optimizer::OPTIMIZE_TEXTURE_SETTINGS;
optimizer.optimize(model, options);

But this is a better fix.

Greg


-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/2ace79a0-1141-465a-80ab-a0ba90bc8f5c%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[Robert Osfield]

Hi Greg,

Today I worked on improving the ObectCache::releaseGLObjects() 
implementation so that it removes objects in the scene that are Texture or 
contain Textures in their subgraph, where the Texture no longer have any 
associated osg::Image. I believe this resolves the usage case :

  1.  Load the scene graph, with the Texture UnRefImageAfterApply setiings 
are set to UnrefImageAfterApply, with the loaded textures/scene graphs 
being cached in the osgDB::ObjectCache.
  2. Render the scene graph, resulting the in the scene graph images being 
unref'd from their Textures.
  3. Close the Window, which cleans up the scene graph GL obects by calling 
releaseGLObjects()
  4. Load a new scene graph with textures/objects loaded from disk and 
where possible from the ObjectCache if previously loaded and cache,  Got 
back to 2. (Rendering etc.)

I created an example that follows all these steps and it reproduced the 
problem with the textures appearing black on the second time around when 
loading an OpenFlight database.  With the fixes to 
ObjectCache::releaseGLObjects() the unref'd images are automatically 
removed from the cache as part of step 3. above, so that they aren't shared 
any more, instead new copies are loaded from disk with their image in place.

This fix is checked into the OpenSceneGraph-3.6 branch.  The commit is:


https://github.com/openscenegraph/OpenSceneGraph/commit/9ae47b921b2184788e6efe85692908bd0ba900a2

Could you please test this out.  You should be able to remove your own 
manually clearing of the ObjectCache now, as it will be done automatically 
when required.

Cheers,
Robert.

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/f779a1bf-e231-4317-8600-565dca7f4670%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[Robert Osfield]

On Wed, 11 Dec 2019 at 13:04, Greg D  wrote:

> I don't understand exactly what the cache does.
>

The clue is in the name, ObjectCache is cache of Objects so they can be
reused.

The cache is useful for avoid objects being loaded multiple ties,
especially important for textures as they consume a large amount of GPU
memory so maintaining duplicates can cripple performance.


>   If it has an expiration time and objects are removed after a minute or
> so (which seems to happen) it would appear it is a short-term cache,
> perhaps to increase efficiency when the model is loading,
>

The amount of time objects in cache are retained for is controlled by the
osgDB::Registry::setExpiryDelay(double), it defaults to 10 seconds, you can
set it programmatically or set the default via OSG_EXPIRY_DELAY env var.



> before it is rendered, such as re-using already loaded texture images and
> so forth.  If it is for long-term caching (keeping models in memory even
> after another model is loaded) that would be counter productive in our
> application, since the user might load several different large model files
> in a minute in some situations, and keeping all those models in memory
> would be problematic.  My preference would be to disable caching
> altogether, unless it is a short-term cache to make loading more efficient,
> in which case clearing the cache after the first render solves my problem.
>
> I have set the osgDB::Options to CACHE_NONE but it does not appear to have
> any effect on caching.  The OpenFlight model and its textures are always
> loaded from the cache if the cache contains objects.
>
> osg::ref_ptr dbOptions = new osgDB::Options();
> dbOptions->setObjectCacheHint(osgDB::Options::CACHE_NONE);
>
> osgDB::readNodeFile(fileName, dbOptions);
>
> Is this not the correct way to disable caching?
>

It's a ObjectCacheHint so plugns can be free to ignore the hint if they
want to use the cache for their own requirements.

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

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[Greg D]

Thanks Robert.  I moved the line to clear the cache into my calling code 
and out of OSG.  

I don't understand exactly what the cache does.  If it has an expiration 
time and objects are removed after a minute or so (which seems to happen) 
it would appear it is a short-term cache, perhaps to increase efficiency 
when the model is loading, before it is rendered, such as re-using already 
loaded texture images and so forth.  If it is for long-term caching 
(keeping models in memory even after another model is loaded) that would be 
counter productive in our application, since the user might load several 
different large model files in a minute in some situations, and keeping all 
those models in memory would be problematic.  My preference would be to 
disable caching altogether, unless it is a short-term cache to make loading 
more efficient, in which case clearing the cache after the first render 
solves my problem.

I have set the osgDB::Options to CACHE_NONE but it does not appear to have 
any effect on caching.  The OpenFlight model and its textures are always 
loaded from the cache if the cache contains objects.

osg::ref_ptr dbOptions = new osgDB::Options();
dbOptions->setObjectCacheHint(osgDB::Options::CACHE_NONE);

osgDB::readNodeFile(fileName, dbOptions);

Is this not the correct way to disable caching?

Thanks.


-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/de89e01e-20e4-461c-9b51-dc9dddecd09b%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[Robert Osfield]

On Monday, 9 December 2019 19:57:27 UTC, Greg D wrote:
>
> My quick fix is to clear the cache on the first render (and call clear 
> thereafter).  OpenFlight files open and render fine now.  Is this a safe 
> fix?
>
> void ViewerBase::frame(double simulationTime)
> {
> 
> osgDB::Registry::instance()->clearObjectCache();  // ADDED TO CLEAR CACHE 
> AFTER RENDER SINCE IT BECOMES CORRUPTED
> }
>
>
Adding this line to ViewerBase is a point of information about the problem 
rather than a fix.  FYI, you can override Viewer::frame() by just 
subclassing Viewer there is no need to modify the OSG itself.  You can also 
call the clear after the frame() in your own frame loop.  However, all of 
these clearObjectCache() changes are hacks around a different problem.

>From your previous post that the change to OpenFlight's use of local cache 
vs ObjectCache indicates to me that the memory optimization of unrefering 
the osg::Image after the image data has been applied to the Textures 
texture object.  If an Texture is in the cache and could be reused *and* 
the texture object data is released between the first use but before that 
Texture is later reused.

The potential fixes are :

Nt enable Texture::UnrefImageAfterApply  - this is set to true by the 
osgUtil::Optimizer's TextureVisitor.  Is you app call the Optimizer on 
loaded databases?
Don't delete the graphics contexts, instead just close the window and 
reopen it when you need it.
Don't enable the object cache usage.

A fix at the OSG would be for the OjbectCache to automatically detect the 
usage case where a Texture is in the case, it's been compiled and the image 
unreferred, the context deleted, then the Texture requested from the 
cache.   The place to do this would probably be 
ObjectCache::releaseGLObjects(osg::State* state).  It'd need to 
dynamic_cast the Objects in the cache to find the textures then 
remove the Texture from the cache if it's got UnrefImageAfter enabled and 
no osg::Image still attached to it.

Robert.




-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/d726cd31-ce28-43ce-814c-1e293da836b8%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[Greg D]

My quick fix is to clear the cache on the first render (and call clear 
thereafter).  OpenFlight files open and render fine now.  Is this a safe 
fix?

void ViewerBase::frame(double simulationTime)
{
if (_done) return;

// 
OSG_NOTICE

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[Greg D]

Robert,

Thanks for the information.  I cleaned up the references to allow smart 
pointers to work for the model and viewer as intended.  The explicit 
deletion and cleanup code was added years ago in an attempt to address a 
memory leak issue.  Unfortunately osgDB::readRefFile() wasn't available 
when the original code was written years ago, and the loading code was 
taken directly the first sample that loaded a model file - 
osganimationhardware.  We've never had an issue but I did make the changes 
you suggested.

After the changes I found the problem persisted.  It ended up being a 
change to the OpenFlight plugin.  The older version had its own caches for 
textures and external references (3.4.0).  The newer version (3.6.3/4) uses 
the osgDB ObjectCache class.  The problem with that is Texture2D.cpp 
deletes the texture image data on the first render (line 285) so the cached 
data is null right after the file is loaded, thus the black textures. In 
reality, the osgDB cache is useless since (at least) the texture data is 
overwritten almost immediately.  I found that after the cache expiration 
timed out all the cached data was deleted and the model will load correctly 
since it is not getting corrupted data from the cache but loading the files.

Will there be a fix coming for the cache issue or should I do a workaround 
(perhaps re-using the 3.4.0 OpenFlight cache code)?

Thanks.





On Friday, December 6, 2019 at 1:35:45 PM UTC-6, Greg D wrote:
>
> I have been using OSG for a number of years for a commercial product.  Our 
> product loads various models and earth views as the user requires them (for 
> security monitoring – buildings and campuses mostly).  I have a problem 
> with 3.6.3/4 that wasn't there in 3.4.0.
>
>  
>
> I have an OpenFlight model (sample/demo model) that uses textures for 
> terrain and on buildings.  The first time I load it all is fine.  However, 
> if I load another model (or another graphics file – the application 
> supports AutoCAD, raster, OSG Earth, and ArcGIS formats as well) then 
> reload the model the terrain is black and the textures are corrupted if 
> they are not black.  This worked fine with 3.4.0 and 3.4.1 but does not 
> work with 3.6.3 or 3.6.4.
>
>  
>
> I have debugged into the code and it appears that the model and textures 
> are always reloaded from the cache and I cannot override this (setting 
> Options::CACHE_NONE doesn’t affect it - in 3.4.0 the model always loaded 
> from files with Options set to CACHE_NONE).  If I look at the model graph 
> in memory (after the first load), the textures appear to be erased or 
> over-written during the traversals in one of the classes called in 
> ViewerBase::runOperations() (though it’s a little confusing to me at that 
> point, it appears to be when GlobalObjectVisitor::compile() calls 
> node.accept(*this)).  During the traversals where the textures appear to be 
> over-written, I noticed the context ID is always 0, so the textures appear 
> to be reloaded, over-writing the original data in the process (though I 
> could be quite confused as to what I am seeing and it may all be irrelevant 
> to the issue). 
>
>
> Below is a short snippet from my initialization and cleanup code between 
> model loads.  I load the model, add a clip node to peel down through the 
> models vertically.  I also add other nodes to hold embedded bitmaps 
> (Billboards) representing security devices – cameras, doors, alarm points, 
> etc.  Those details are omitted from the code below.  After the model is 
> loaded I set up the graphics context and render the image to an offscreen 
> window (which is then copied to a memory bitmap).  The application is a 
> Windows console app (with hidden window) that streams bitmap images to the 
> client app via named pipe on the same machine (I know, it’s complicated, 
> but it’s a complex environment, including live video windows).
>
>  
>
> As I said, it has worked fine with previous versions of OSG (back to 
> 3.0.1, if not earlier).  This may be specific to Open Flight models, as I 
> can load FBX models, OSG earth files, or the cessnafire.osg model and the 
> textures appear correct.
>
>
> Any help would be appreciated.  If the model would always be loaded from 
> the file when Options::CACHE_NONE were set it would solve my problem.
>
>
> OSGLoadResult OpenSceneGraphBitmap::LoadModel(std::string fileName, 
> osgDB::Options* dbOptions)
>
> {
>
>CleanupModel();
>
>  
>
>if (m_Root == nullptr)
>
>   m_Root = new osg::Group;  // Init the main Root 
> Node/Group
>
>  
>
>// Load the Model from the model name
>
>osg::Group* model = dynamic_cast(osgDB::readNodeFile(
> fileName, dbOptions));
>
>if (model != nullptr)
>
>{
>
>   // Optimize the model
>
>   osgUtil::Optimizer optimizer;
>
>   optimizer.optimize(model);
>
>   optimizer.reset();
>
>  
>
>   // Create the clip 

Re: [osg-users] Texture Caching Problem with 3.6.3/4

[Robert Osfield]

The explanation and code snippet doesn't tell us enough of what is going on 
in your app to be able to guess what might be wrong.

The best thing I can do at this point is flag up a couple of issues in the 
code that could be improved, or flag up stuff that seems odd.

First up a memory leak:

  osg::Group* model = dynamic_cast(osgDB::readNodeFile(
fileName, dbOptions));

   if (model != nullptr)

   {...


This code will only assign the loaded object the m_Root if the loaded model 
root node is a Group, if isn't then it'll just be leaked, never to be 
deleted.


The best way to do a read to a particular type in robust way is to use 
ref_ptr<> and the readFile(..) method i.e.


 auto model = osgDB::readRefFile(fileName, dbOptions));  // 
return a ref_ptr that internally uses an 
dynamic_cast



The next odditiyr is that you have a CleanupModel method that removes the 
whole Viewer, but you call it a View:


void OpenSceneGraphBitmap::CleanupModel()

{

   RemoveViews();

...


}


This seems like your application is conflating various different features 
together, which is a red flag by itself and makes me wonder if you have 
mis-understood the intent of the various osgViewer class available.


The new bit of related code is another sign of misuse of the how the OSG is 
intended to be used:


void OpenSceneGraphBitmap::RemoveViews()

{

   if (m_nhiCompositeViewer != nullptr)

   {

  m_nhiCompositeViewer->setDone(true);

 

  delete m_nhiCompositeViewer;

  m_nhiCompositeViewer = nullptr;

   }


The OSG has built in robust reference counting, it is almost never 
appropriate to directly delete a object, not in the scene graph, not in the 
viewer, not a whole viewer.  I suspect your application at a higher level 
is not ideally organized so the following suggestion might just gloss over 
wider problems, any I say it here as understanding ref_ptr<> usage is 
important regardless...


So your m_nhiCompositeViewer pointer should *always* be a ref_ptr<> and 
*never* a straight C pointer.  If you want to delete a viewer you just set 
the ref_ptr<> to nullptr and it'll be automatically deleted for you if no 
other references exist t it.  The above method could safely be replaced 
with a single line : m_nhiCompositeViewer = nullptr;


However, this doesn't fix the other problems in the code, it'd just fix a 
bad practice.


Next problem will need to look at is back to the 
OpenSceneGraphBitmap::CleanupModel() 
method:



void OpenSceneGraphBitmap::CleanupModel()

{

   RemoveViews();

 

   if (m_Root != nullptr) // if root already exists (already loaded 
previous scene) remove children to clean up

   {

  m_Root->releaseGLObjects();

  m_Root->removeChildren(0, m_Root->getNumChildren());

 

  void* ptr = m_Root.release();

  delete ptr;

  m_Root = nullptr;

   }

}


Here you call RemoveViews() which will delete the Viewer and all graphics 
contexts associated with it.  The you try and do some manual clean up:


   if (m_Root != nullptr) // if root already exists (already loaded 
previous scene) remove children to clean up

   {

  m_Root->releaseGLObjects();

  m_Root->removeChildren(0, m_Root->getNumChildren());


This suggest to me that you are keeping m_Root around as some form of 
global container and then trying to manage it's contents.  The code 
snippets don't say how the node and it's children.  Deleting a Viewer will 
delete all it's GraphicsContext and clean up all the scene graphs that are 
directly attached to it, but it you have scene graph elements that are 
detached from the scene graph then it can't clean up these.  If these 
detached elements contain GL objects will have already been deleted by the 
graphics context deletion, so the handles are orphaned but the OSG itself 
doesn't know about it, and calling releaseGLObjects() will release the 
handles into containers that the OSG uses to schedule deletion or reuse of 
the GL objects.  If the graphics contexts already deleted then you have to 
discard any GL handles via calling discardGLObjects() rather than 
releaseGLObjects().


The osgViewer and scene graph are design to do all the automatic clean up 
and management of GL objects behind the scenes for you, for most 
applications there should never be a need to explicitly call 
releaseGLObjects();  The OSG can't track what you detach from viewers and 
then manipulate, in these cases you really need to think whether what you 
are doing is necessary and sensible.  My strong recommendation is that 
users avoid doing this.  


Finally we have another instance of manually an object:


  void* ptr = m_Root.release();

  delete ptr;

  m_Root = nullptr;


The code tells me that m_Root is likely a ref_ptr which rather than 
just do the sensible thing and call m_Root = nullptr and 

[osg-users] Texture Caching Problem with 3.6.3/4

[Greg D]

I have been using OSG for a number of years for a commercial product.  Our 
product loads various models and earth views as the user requires them (for 
security monitoring – buildings and campuses mostly).  I have a problem 
with 3.6.3/4 that wasn't there in 3.4.0.

 

I have an OpenFlight model (sample/demo model) that uses textures for 
terrain and on buildings.  The first time I load it all is fine.  However, 
if I load another model (or another graphics file – the application 
supports AutoCAD, raster, OSG Earth, and ArcGIS formats as well) then 
reload the model the terrain is black and the textures are corrupted if 
they are not black.  This worked fine with 3.4.0 and 3.4.1 but does not 
work with 3.6.3 or 3.6.4.

 

I have debugged into the code and it appears that the model and textures 
are always reloaded from the cache and I cannot override this (setting 
Options::CACHE_NONE doesn’t affect it - in 3.4.0 the model always loaded 
from files with Options set to CACHE_NONE).  If I look at the model graph 
in memory (after the first load), the textures appear to be erased or 
over-written during the traversals in one of the classes called in 
ViewerBase::runOperations() (though it’s a little confusing to me at that 
point, it appears to be when GlobalObjectVisitor::compile() calls 
node.accept(*this)).  During the traversals where the textures appear to be 
over-written, I noticed the context ID is always 0, so the textures appear 
to be reloaded, over-writing the original data in the process (though I 
could be quite confused as to what I am seeing and it may all be irrelevant 
to the issue). 


Below is a short snippet from my initialization and cleanup code between 
model loads.  I load the model, add a clip node to peel down through the 
models vertically.  I also add other nodes to hold embedded bitmaps 
(Billboards) representing security devices – cameras, doors, alarm points, 
etc.  Those details are omitted from the code below.  After the model is 
loaded I set up the graphics context and render the image to an offscreen 
window (which is then copied to a memory bitmap).  The application is a 
Windows console app (with hidden window) that streams bitmap images to the 
client app via named pipe on the same machine (I know, it’s complicated, 
but it’s a complex environment, including live video windows).

 

As I said, it has worked fine with previous versions of OSG (back to 3.0.1, 
if not earlier).  This may be specific to Open Flight models, as I can load 
FBX models, OSG earth files, or the cessnafire.osg model and the textures 
appear correct.


Any help would be appreciated.  If the model would always be loaded from 
the file when Options::CACHE_NONE were set it would solve my problem.


OSGLoadResult OpenSceneGraphBitmap::LoadModel(std::string fileName, osgDB::
Options* dbOptions)

{

   CleanupModel();

 

   if (m_Root == nullptr)

  m_Root = new osg::Group;  // Init the main Root 
Node/Group

 

   // Load the Model from the model name

   osg::Group* model = dynamic_cast(osgDB::readNodeFile(
fileName, dbOptions));

   if (model != nullptr)

   {

  // Optimize the model

  osgUtil::Optimizer optimizer;

  optimizer.optimize(model);

  optimizer.reset();

 

  // Create the clip node and add to scene

  osg::ComputeBoundsVisitor cbbv;

  model->accept(cbbv);

  osg::BoundingBox bb = cbbv.getBoundingBox();

 

  osg::ref_ptr clipPlane = new osg::ClipPlane;

  clipPlane->setClipPlane(0.0, 0.0, -1.0, bb.zMin() + 
(bb.zMax() - bb.zMin()));

  clipPlane->setClipPlaneNum(0);

 

  osg::ref_ptr clipNode = new osg::ClipNode;

  clipNode->setName("CLIP_NODE");

  clipNode->addClipPlane(clipPlane.get());

 

  clipNode->setCullingActive(false);

 

  model->setStateSet(clipNode->getStateSet());

 

  m_Root->addChild(clipNode);

 

  m_Root->addChild(model);

 

  m_Root->setDataVariance(osg::Object::DYNAMIC);

 

 

  return OSGLoadResult::Sucess;

   }

 

   // since load failed, reset the wait event so the render thread 
resumes

   return OSGLoadResult::FileLoadError;

}

 

void OpenSceneGraphBitmap::CleanupModel()

{

   RemoveViews();

 

   if (m_Root != nullptr) // if root already exists (already loaded 
previous scene) remove children to clean up

   {

  m_Root->releaseGLObjects();

  m_Root->removeChildren(0, m_Root->getNumChildren());

 

  void* ptr = m_Root.release();

  delete ptr;

  m_Root = nullptr;

   }

}

 

void OpenSceneGraphBitmap::RemoveViews()

{

   if (m_nhiCompositeViewer != nullptr)

   {

  m_nhiCompositeViewer->setDone(true);

 

  delete