Texture Caching Problem with 3.6.3/4

Greg D

unread,

Dec 6, 2019, 2:35:45 PM12/6/19

to OpenSceneGraph Users

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<osg::Group*>(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<osg::ClipPlane> clipPlane = new osg::ClipPlane;

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

clipPlane->setClipPlaneNum(0);

osg::ref_ptr<osg::ClipNode> 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 m_nhiCompositeViewer;

m_nhiCompositeViewer = nullptr;

}

Robert Osfield

unread,

Dec 7, 2019, 6:58:05 AM12/7/19

to OpenSceneGraph Users

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<osg::Group*>(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<T>(..) method i.e.

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

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<Group> which rather than just do the sensible thing and call m_Root = nullptr and let the smart pointer do it's job in clean up you release the pointer and then manually delete it.

It's painful to see such a combination a misuse of the OSG. I don't know where you have picked up this coding style, but it's never been part of the OSG usage, none of the OSG examples, none of books, never in it's near 20 year history has abusing ref_ptr<> in this way been advocated.

I don't know the history of your application, it could be that you've inherited bad code and have been thrown in the deepened trying to learn and fix stuff at the same time. From this point, I am pretty sure that the regression you see in going from 3.6.0 to 3.6.4 is likely to mis-use of the OSG in your application code that make it's so fragile and dependent on accidental behaviors to function. Fixing bugs on the OSG then can easily break your application as it was relying on buggy behavior.

From the little snippets I've picked up a number of problems, fixing these might work around the problems, but my guess is that there are major problem throughout the code. The good news is that if you learn to use the OSG a bit more appropriately your codebase will become smaller, cleaner, easier to maintain, more robust, more fun to work with.

Spending a bit of time learning about how smart pointers work and how to use them will really help you. You have accesses to the full OSG source code so if you aren't sure about something just have a look at the code, put break points into the code, see what happens when smart pointers do there thing. Have a look through the examples, discussions online, have a look at the OSG books. This investment in learning more about the how thing work will make you much more productive.

Best of luck,

Robert.

}

Greg D

unread,

Dec 9, 2019, 12:48:48 PM12/9/19

to OpenSceneGraph Users

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.

Greg D

unread,

Dec 9, 2019, 2:57:27 PM12/9/19

to OpenSceneGraph Users

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<<std::endl<<"CompositeViewer::frame()"<<std::endl<<std::endl;

if (_firstFrame)

{

viewerInit();

if (!isRealized())

{

realize();

}

_firstFrame = false;

}

advance(simulationTime);

eventTraversal();

updateTraversal();

renderingTraversals();

osgDB::Registry::instance()->clearObjectCache(); // ADDED TO CLEAR CACHE AFTER RENDER SINCE IT BECOMES CORRUPTED

}

Robert Osfield

unread,

Dec 10, 2019, 8:41:37 AM12/10/19

to OpenSceneGraph Users

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<Texture> 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.

Greg D

unread,

Dec 11, 2019, 8:04:14 AM12/11/19

to OpenSceneGraph Users

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<osgDB::Options> dbOptions = new osgDB::Options();

dbOptions->setObjectCacheHint(osgDB::Options::CACHE_NONE);

osgDB::readNodeFile(fileName, dbOptions);

Is this not the correct way to disable caching?

Thanks.

Robert Osfield

unread,

Dec 11, 2019, 9:13:51 AM12/11/19

to OpenSceneGraph Users, OpenSceneGraph Users

On Wed, 11 Dec 2019 at 13:04, Greg D <g.da...@networkharbor.com> 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<osgDB::Options> 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.

Robert Osfield

unread,

Dec 16, 2019, 12:08:34 PM12/16/19

to OpenSceneGraph Users

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.

Greg D

unread,

Dec 18, 2019, 4:13:41 PM12/18/19

to OpenSceneGraph Users

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

Angelo Emanuele Fiorilla

unread,

Mar 31, 2020, 9:42:22 AM3/31/20

to 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:

<path>/home/emanuele/mapsCache</path>

</cache>

</options>

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: