osgEarth 2.10 osgDB::readImageFile Issue

classic Classic list List threaded Threaded
5 messages Options
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

osgEarth 2.10 osgDB::readImageFile Issue

Hey,

So after upgrading from 2.9 to 2.10, I noticed some strange behavior with 2D images loaded in from the osgDB::readImageFile(const String& path) function. On a projected map it's fine, but on any geocentric map the image loads as a white blank square with no data. There's no error in the console, like if you were to put an incorrect path (which would return a nullptr). I noticed it happened with .svg, .png, and .jpeg (these are all we had for testing). Anyone have an idea why that may be happening on 3D specifically, but not the 2D Projected map?

P.S. We didn't change any of our code that did work and used the example from: http://docs.osgearth.org/en/latest/developer/utilities.html as a reference and it worked fine in the past. Also .osgb files are still fine when loading 3D models on either map type.

Thanks for any assistance.

- Blanky
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth 2.10 osgDB::readImageFile Issue

So this issue still hasn't been addressed...

This image shows how images always looked on a 2D map from osgEarth 2.9 and 2.10 is the same:
2D map with a correct SVG image

And after upgrading from osgEarth 2.9 to 2.10 on a 3D map the same exact osg::Image inside an osg::Node looks like the following (which did previously look correctly without any code or dependency changes):

3D map with an incorrect SVG image

And two more examples of both behaviors on a 2D and 3D map in 2.10:

2D Projected working:
2D working second time

3D Geodetic not working:
3D not working

Thanks for any help.
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth 2.10 osgDB::readImageFile Issue

Blanky,
You'll need to open a GitHub issue and provide either an earth file or a .cpp file that will reproduce the issue. Thanks.
Glenn Waldron / Pelican Mapping
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth 2.10 osgDB::readImageFile Issue

I opened an issue as requested and actually narrowed it down to the osgEarth::Annotation::AnnotationUtils::createImageGeometry(osg::Image* img) function.

I will attach my two earthfiles for a projected and geodetic map along with the main.cpp that can be used to test. you just need to set the paths for the earthfile and either some .svg or .png file for the actual icons to place on the map. Unfortunately I do not have the ability to upload files with the correct format from my work place, but can do so later today afterwards.

Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth 2.10 osgDB::readImageFile Issue

Upon further investigation, I noticed a difference between 2.9 and 2.10. Specifically with the use of the osgEarth::GLUtils file in that previously mentioned osgEarth::Annotations::Annotationsutil::CreateImageGeometry function.

In 2.10 you do the following:

    // set up the decoration.
    osg::StateSet* dstate = new osg::StateSet;
    dstate->setDataVariance(osg::Object::DYNAMIC);
    dstate->setMode(GL_CULL_FACE,osg::StateAttribute::OFF);
    GLUtils::setLighting(dstate, osg::StateAttribute::OFF);
    dstate->setTextureAttributeAndModes(0, texture, osg::StateAttribute::ON);

However, in 2.9, which was working you did this:

    // set up the decoration.
    osg::StateSet* dstate = new osg::StateSet;
    dstate->setMode(GL_CULL_FACE,osg::StateAttribute::OFF);
    dstate->setMode(GL_LIGHTING,osg::StateAttribute::OFF);
    dstate->setTextureAttributeAndModes(0, texture,osg::StateAttribute::ON);

I have a feeling that the GLUtils::setLighting function is not doing something correctly and the reason why this isn't apparent with the osgEarth::Annotations::PlaceNode is the following code in its .cpp:

    _imageDrawable = AnnotationUtils::createImageGeometry(_image.get(), offset, 0, heading, scale);
    if (_imageDrawable)
    {
        // todo: optimize this better:
        _imageDrawable->getOrCreateStateSet()->merge(*_imageStateSet.get());
        _geode->addChild(_imageDrawable);
        imageBox = _imageDrawable->getBoundingBox();
    }    

It looks like the lighting may be overridden when the line:

_imageDrawable->getOrCreateStateSet()->merge(*_imageStateSet.get());

is being called, overriding whatever the static GLUtils function is doing. If I'd have to guess, this is the issue and I'm not sure if it's correct behavior or not since both 2D and 3D seem to have a different appearance.