error: TextureObjectManager is not a member of osg::Texture && osg::Texture::getTextureObjectManager() #1213
-
Hi, It looks like calls to the TextureObjectManager changed between 3.4.0 (it is there) and 3.6.3 (it is not). The osg code is from inside Omegalib https://github.com/uic-evl/omegalib. Essentially this:
The compile error is:
The TextureObjectManager is named in this News post, but there doesn't seem to be any news about it moving or changing? https://github.com/openscenegraph/OpenSceneGraph/blob/master/NEWS.txt Running nm on one of the libs built suggests it is still there. Looks like ./omegalib/build.230323/bin/libosg.so knows about TextureObjectManager
Does it still exist in OSG? https://weber.itn.liu.se/~karlu20/tmp/OpenSceneGraph/classosg_1_1Texture_1_1TextureObjectManager.html Any suggestions? (thx) |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
I don't recall coming across Omegalib so thanks to providing the link. The Omegalib dev community will need to update their codebase to work with OpenSceneGraph-3.6. The TextureObjectManager still exists, but it's meant to be an internal implementation detail rather than something that end user applications should be getting/setting. The code snippet from Omegalib looks a bit odd and hints that the code base might be very old OSG 1,x era features like SceneView rather than using more modern ones in osgViewer that was introduced in OSG-2.0. My recommendation would be to look at why there SceneView::draw() is being overridden and to look at the SceneView::draw() implementation that is in OpenSceneGraph-3.6 as a reference for what SceneView::draw() should be doing: What are you trying to use Omegalib for? it might be that it's not the best tool for the job these days. |
Beta Was this translation helpful? Give feedback.
I don't recall coming across Omegalib so thanks to providing the link. The Omegalib dev community will need to update their codebase to work with OpenSceneGraph-3.6.
The TextureObjectManager still exists, but it's meant to be an internal implementation detail rather than something that end user applications should be getting/setting.
The code snippet from Omegalib looks a bit odd and hints that the code base might be very old OSG 1,x era features like SceneView rather than using more modern ones in osgViewer that was introduced in OSG-2.0.
My recommendation would be to look at why there SceneView::draw() is being overridden and to look at the SceneView::draw() implementation that is in Op…