<div dir="ltr"><div><div><div>Hi Scott,<br><br></div>The problem under OSX looks to be a driver bug, there is small chance that it's related to the problems you are seeing but likely a different issue.<br><br></div>The problem you describe sounds like a driver bug too, testing out without other drivers/hardware/OS combinations would help with this. Have you tried any other combinations?<br><br></div><div>There is possibility that different drivers handle the input data in different ways. The addition of the glTextureStorage2D usage might be adding another code pathway in the drivers that adds/removes/changes the way that data is handled introducing the inconsistency that you are seeing. The driver shouldn't be doing this, but no code is perfect.<br><br>Without an example model that can reproduce the problem there isn't much others can do at this stage. Potentially we could add a catch for compressed textures + mipmap levels into osg::Texture*, but before any mods to the core OSG I'd need to have a test example to work from that exhibits a problem so that can confirm that these changes actually work.<br><br></div>Robert.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 September 2015 at 22:24, Davis, Timothy S CTR comnavairsyscom <span dir="ltr"><<a href="mailto:timothy.s.davis.ctr@navy.mil" target="_blank">timothy.s.davis.ctr@navy.mil</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Robert<br>
<br>
Sorry for the bad posting of my last message. I'll repeat here and update with new information.<br>
<br>
The code in question was added sometime during OSG 3.3.x development. It was not in OSG 3.2.1. I just recently jumped from 3.2.1 to 3.4.0 for my application which is when I ran into the problem. It worked fine with OSG 3.2.1. In particular, it appears to be the added support for texture storage objects and not specifically "compressed texture support". I noted the call that gave the error was glCompressTexSubImage2D. However I should point out that I determined this using gDEBugger. My version doesn't seem to understand the texture storage extension. So the error may have been generated by the earlier call to setup the texture storage. I checked into this and indeed an INVALID_OPERATION was generated by the call to glTexStorage2D.<br>
<br>
In addition, on my machine the problem doesn't affect all compressed textures with mipmaps. The model that first caused the problem had several such textures, but only a small 32x32 texture resulted in a problem. I have no idea why this would be the case. However I remember others reporting issues with loading DDS textures and working around it by commenting out the following line in ReaderWriterDDS:<br>
If ( mipmap_offset.size()>0) osgImage->setMipmapLevels(mipmap_offsets);<br>
Commenting that line out would appear to disable mipmaps for compressed textures and avoid the problems I've indicated. This older problem was reported only on OSX, but may be related. This type of changed made to the IVE loader would also have fixed my problem at the expense of disabling mipmaps.<br>
<br>
Looking at a different model, the one problem texture was 128x128. So there appears to be nothing special about the size. I did see that the rendering result for the models that have the problem is different between using the fixed-function pipeline and a shader. With the FFP, the rendering appears correct, though the INVALID_OPERATION error is generated. With a shader, the textures rendered black.<br>
<br>
I looked at making a simple model that would reproduce the problem. However, I've failed to create such a model. It just always works with no render problems or OpenGL errors.<br>
<br>
For my application, I've worked around the problem by reducing the number of mipmap levels to avoid using levels smaller than the compression block size. So I consider the problem fixed for me. However, I feel this is information that you and the rest of the community can use.<br>
<br>
<br>
Scott<br>
<br>
<br>_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
<br></blockquote></div><br></div>