[osg-users] [forum] DXT texture compression

Robert Osfield robert.osfield at gmail.com
Fri May 18 01:18:54 PDT 2018


Could you please sign with a proper human name, "urbanchaos" really
doesn't convey positive perception of you, instead it suggest one is
trying to hard to be "cool" and ends up looking a infantile. This may
be not be what you intend, but this is what such names conveys to
others.  It's better to dispense with the fascade and just be
yourself, a coder that wants to write interesting graphics apps. use
of a proper human name really helps with encouraging everyone to treat
other respectfully - the virtual and real-world are the same in that

> I got a segmentation fault during a texture compression when I moved to OSG 3.4.1 / OSG 3.6.0.
> With OSG 3.2.1 no problem encountered.
> Code:
> osg::ref_ptr <'osg::Image'> image = osgDB::readImageFile("building.rgb");
> // if valid
> osg::ref_ptr <'osg::State'> state = new osg::State;
> osg::ref_ptr <'osg::Texture2D'> texture = new osg::Texture2D;
> texture->setInternalFormatMode (osg::Texture::USE_S3TC_DXT5_COMPRESSION);
> texture->setImage(image.get());
> texture->apply(*state.get());
> image->readImageFromCurrentTexture(0, true);
> osgDB::writeImageFile(*image, "building.dds");
> The backtrace (gdb) shows an error on osg::Texture::computeRequiredTextureDimensions after the osg::Texture2D::apply.
> Any suggestions or any other solution?

If it's a bug I'd like to get it fixed.  The big unknown in your code
snippet is how you ensure that the code snippet is called from a valid
graphics context.  If the code isn't called from a valid graphics
context then it's likely to crash.

Could you create a small example that illustrates the crash.  This
will allow us to recreate the problem locally and suggest a way to
resolve it, itf it's an OSG bug we can try and resolve it for the up
coming 3.6.1


More information about the osg-users mailing list