OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

DXT texture compression


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General [forum]
View previous topic :: View next topic  
Author Message
urbanchaos
Newbie


Joined: 19 May 2009
Posts: 7

PostPosted: Tue May 08, 2018 12:13 pm    Post subject:
DXT texture compression
Reply with quote

Hi,

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?

Thank you!

Cheers,
urbanchaos
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Fri May 18, 2018 8:19 am    Post subject:
DXT texture compression
Reply with quote

Hi,

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.


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

Cheers,
Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
urbanchaos
Newbie


Joined: 19 May 2009
Posts: 7

PostPosted: Fri May 18, 2018 11:46 am    Post subject:
Reply with quote

Robert,

I'm sorry but the problem is that the post was automatically signed.

Now that I've changed the name, in according to the netiquette, the human name will appear.

Thanks for the information.



Going back to the code, below how I've realized a very small graphic context.

Code:

osg::ref_ptr traits = new osg::GraphicContext::Traits;

traits->x = 1;
traits->y = 1;
traits->width = 1;
traits->height = 1;
traits->alpha = 8;
traits->windowDecoration = false;
traits->doubleBuffer = true;
traits->sharedContext = 0;
traits->pbuffer = 0;

osg::ref_ptr gfx = new osg::GraphicContext::createGraphicsContext(traits.get());
if (!gfx || !gfx->valid())
{
// osg::notify - Unable to create a graphic context
return 1;
}

gfx->realize();
gfx->makeCurrent();


The code has stopped working since OSG 3.2.1.

From 3.2.1, the RGB plugin shows a warning "RGB plugin does not supporting writing compressed imagery" and the DDS output was not flipped.
From 3.4.1, I got a segmentation fault.

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

Any suggestions?



Thank you!

Cheers,
Roby


Last edited by urbanchaos on Fri May 18, 2018 12:10 pm; edited 1 time in total
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Fri May 18, 2018 12:09 pm    Post subject:
DXT texture compression
Reply with quote

Hi Roby,

On 18 May 2018 at 12:46, Roby Urban Chaos <> wrote:
Quote:
Now that I've changed the name, in according to the netiquette, the human name will appear.

Thanks :-)

Quote:
Thanks for the information.

Quote:
Going back to the code, below how I've realized a very small graphic context.


Code:

osg::ref_ptr<osg::GraphicContext::Traits> traits = new osg::GraphicContext::Traits;

traits->x = 1;
traits->y = 1;
traits->width = 1;
traits->height = 1;
traits->alpha = 8;
traits->windowDecoration = false;
traits->doubleBuffer = true;
traits->sharedContext = 0;
traits->pbuffer = 0;

osg::ref_ptr<osg::GraphicContext> gfx = new osg::GraphicContext::createGraphicsContext(traits.get());
if (!gfx || !gfx->valid())
{
// osg::notify - Unable to create a graphic context
return 1;
}

gfx->realize();
gfx->makeCurrent();




The code has stopped working since OSG 3.2.1.

The graphics context code has stopped working? Or the compression?


Quote:

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.

Cheers,
Robert.



------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
urbanchaos
Newbie


Joined: 19 May 2009
Posts: 7

PostPosted: Fri May 18, 2018 2:08 pm    Post subject:
Reply with quote

Quote:

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?



Thank you!

Cheers,
Roby
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Fri May 18, 2018 2:33 pm    Post subject:
DXT texture compression
Reply with quote

Hi Roby,

On 18 May 2018 at 15:08, Roby Urban Chaos <> wrote:
Quote:
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.

Flipping is a usage case, it all depends how you are using the data -
i.e. what tools you want to use with it. There are options in the DDS
plugin for flipping

For details run:

osgconv --format dds


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

RGB format doesn't not support compressed textures. The RGB format
existed well before GL compression was even dreamed up!

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
urbanchaos
Newbie


Joined: 19 May 2009
Posts: 7

PostPosted: Fri May 18, 2018 4:46 pm    Post subject:
Reply with 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 expect the same result of the 3.0.1 version. Is that correct?


Cheers,
Roby
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Sat May 19, 2018 11:31 am    Post subject:
DXT texture compression
Reply with quote

Hi Roby,

I have just run the test and it sure looks like it's flipped to me.

osgviewer --image Images/lz.rgb
./compressionbug
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 expect the same result.



Cheers,
Roby

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73674#73674








------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
urbanchaos
Newbie


Joined: 19 May 2009
Posts: 7

PostPosted: Wed May 23, 2018 7:50 am    Post subject:
Reply with quote

Hi Robert,

I've run the test several time and the DDS output image is not flipped.

I'm displaying the image with "ImageMagick" to understand if the input and the output image are the same.

See attachment (code, executable osg 3.4.1 - centos 7, lz.rgb, lz.dds).

Cheers,
Roby


Last edited by urbanchaos on Wed May 23, 2018 9:32 am; edited 1 time in total
Back to top
View user's profile Send private message
urbanchaos
Newbie


Joined: 19 May 2009
Posts: 7

PostPosted: Wed May 23, 2018 7:50 am    Post subject:
Reply with quote

Hi Robert,

I've run the test several time and the DDS output image is not flipped.

I'm displaying the image with "ImageMagick" to understand if the input and the output image are the same.

See attachment (code, executable osg 3.4.1 - centos 7, lz.rgb, lz.dds).

Cheers,
Roby
Back to top
View user's profile Send private message
urbanchaos
Newbie


Joined: 19 May 2009
Posts: 7

PostPosted: Mon Jun 04, 2018 6:39 am    Post subject:
Reply with quote

Hi Robert,

did you try my code?

Thank you!

Cheers,
Roby
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Mon Jun 04, 2018 8:29 am    Post subject:
DXT texture compression
Reply with quote

On 4 June 2018 at 07:39, Roby Urban Chaos <> wrote:
Quote:
did you try my code?

You obviously haven't read my reply. Yes I tested it.

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
urbanchaos
Newbie


Joined: 19 May 2009
Posts: 7

PostPosted: Mon Jun 04, 2018 8:53 am    Post subject:
Reply with quote

urbanchaos wrote:
Hi Robert,

I've run the test several time and the DDS output image is not flipped.

I'm displaying the image with "ImageMagick" to understand if the input and the output image are the same.

See attachment (code, executable osg 3.4.1 - centos 7, lz.rgb, lz.dds).

Cheers,
Roby


I've attached a new tar (compressTex.tar) with my code.

I get always a non-flipped DDS texture in output.

Roby
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Mon Jun 04, 2018 9:36 am    Post subject:
DXT texture compression
Reply with quote

Hi Roby,

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.

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
urbanchaos
Newbie


Joined: 19 May 2009
Posts: 7

PostPosted: Mon Jun 04, 2018 11:25 am    Post subject:
Reply with quote

Ok, no problem...

I let you know if I will find something new.

Thanks for all Robert.

Cheers,
Roby
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General [forum] All times are GMT
Page 1 of 1

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

Similar Topics
Topic Author Forum Replies Posted
No new posts Rend to Texture Once GuiYe General 1 Sun Aug 26, 2018 7:31 am View latest post
No new posts Can't share Texture among several tex... mp3butcher General 1 Fri Aug 17, 2018 11:06 pm View latest post
No new posts minor change: move assumeSizedInterna... mp3butcher General 9 Wed Aug 15, 2018 10:07 pm View latest post
No new posts Minor change proposal : Blacklist usa... mp3butcher General 14 Mon Aug 13, 2018 1:42 pm View latest post
No new posts Load an obj file and mapping a given ... aaa3d General 3 Mon Aug 06, 2018 2:27 pm View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP