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

Quote:

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.

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

Since 3.2.1, the RGB plugin shows a warning "RGB plugin does not supporting writing compressed imagery" and the DDS output was not flipped.

FYI, I've quietened down the RGB plugin warning so it's only emitted
when you try to write a compressed image to a .rgb file. This change
now checked into the 3.6 branch, so the warning won't appear once
3.6.1 comes out.

Quote:

Since 3.4.1, I got a segmentation fault.

The code has been extracted from the "osgconv" applications (CompressTextureVisitor).

Any suggestions?

This morning I had a bash at recreating the crash on my system so
cobbled together a test application the uses a bit of your code
snippet and some code for creating the graphics context.

The code works fine for me using the 3.6 branch head on my Kubuntu
system. I have just built against 3.6.0 and it works fine as well.

Could you test the test program and let me know what happens.

For future reference, the best way for myself and others to be able to
investigate issues is to have a complete compilable example like the
attached one, otherwise it's a lot more work and far more likely to
not recreate issues that you see, we basically have to take a best
guess what we think you have, write it and hope for the best. Copy
and pasting snippets is very poor second to having a compilable
application.

For future reference, the best way for myself and others to be able to
investigate issues is to have a complete compilable example like the
attached one, otherwise it's a lot more work and far more likely to
not recreate issues that you see, we basically have to take a best
guess what we think you have, write it and hope for the best. Copy
and pasting snippets is very poor second to having a compilable
application.

I've got it.

Robert,
the segmentation fault was due to a "new osg::State", instead of using the GraphicsContext ones.
See line 54 and line 58 of the code attached.

Now that the code works, the RGB texture was compressed to DDS but it is not flipped.

Could be that "osgDB::writeImageFile" use the RGB plugin to write the output instead of the DDS plugin?

With the same code, in the 3.0.1 version when compressing the RGB image to DDS, the image was flipped automatically according to DDS default.
To view in the correct way the DDS I always used " osgviewer --image lz.dds -O "dds_flip" "
With the newer version this is in reverse.

When running the applications with OSG_NOTIFY_LEVEL=DEBUG, I can see the message "Flipping dds image on write" but this is not true.
The image was not flipped.

The RGB and DDS file were identical.

To view the DDS now it is sufficient to use " osgviewer --image lz.dds "

The results are flipped, to make the lz.rgb and dds.dds flip you still
have to use:

osgviewer --image lz.dds -O "dds_flip"

Robert.

On 18 May 2018 at 17:46, Roby Urban Chaos <> wrote:

Quote:

I've understood.

With the same code, in the 3.0.1 version when compressing the RGB image to DDS, the image was flipped automatically according to DDS default.
To view in the correct way the DDS I always used " osgviewer --image lz.dds -O "dds_flip" "
With the newer version this is in reverse.

When running the applications with OSG_NOTIFY_LEVEL=DEBUG, I can see the message "Flipping dds image on write" but this is not true.
The image was not flipped.

The RGB and DDS file were identical.

To view the DDS now it is sufficient to use " osgviewer --image lz.dds "

I have already poured a lot of time into investigating issue,
everything looked OK to me, I did everything I could. If others want
to investigate further then they are welcome but for me I have plenty
other stuff on my plate to get on with.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou cannot download files in this forum