[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0
Robert I'd agree that I'm dealing with a driver bug. I'm just not sure what the bug is. I think we are working in a underspecified area of OpenGL when dealing with mipmap levels smaller than the compression block size. However, I know that my driver generates 2x2 and 1x1 mipmaps for hardware generated compressed textures and this would suggest that it should happily work with these levels. I don't agree that it is unrelated to the OSX driver issue. Certainly the drivers are different and the symptoms may be different. But they both appear to touch the same question; what happens with mipmaps smaller than the block size. I don't have access to an OSX machine however, so I cannot investigate this claim further. I have not tried different driver/hardware/OS combinations. I'd agree that this would be useful, but I'm somewhat limited in how far I can go with this. I'd agree that a change to the core OSG is not warranted at this time. The models that cause the problem are not distributable. I may continue to try and create a model that has the issue as time permits. Scott smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0
smime.p7m Description: S/MIME encrypted message ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0
Sorry. It keeps trying to encrypt the message.
Robert
While continuing to build a model that results in the problem, I discovered
something I didn't see before. The IVE model had an incorrect number of mipmap
levels (it had 8) for a 32x32 texture. It makes sense that glTexStorage2D
would generate INVALID_OPERATION in this case. Rebuilding the model from a
source with uncompressed textures and recompressing the textures worked. The
original model was converted with a much older version of OSG, pre OSG 3 for
sure.
So I was barking up the wrong tree:)
That addresses my specific issue without needing a change to OSG 3.4.0.
However, I still think it is worth trying for the OSX case.
Trajce
In osg/Texture.cpp, function applyTexImage2D(), find the line:
useTexStorage &= sizedInternalFormat != 0;
add the following after the line:
if ( useTexStorage && compressed_image && numMipmapLevels > 2 )
{
numMipmapLevels -= 2;
}
This is clearly not production quality as it assumes block size is 4 and
complete mipmaps to 1x1. It should be enough to check the approach. You may
have to set GL_TEXTURE_MAX_LEVEL if the driver thinks the texture is
incomplete, but I didn't have that issue.
Scott
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0.
smime.p7m Description: S/MIME encrypted message ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0.
Robert Sorry for the bad posting of my last message. I'll repeat here and update with new information. 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. 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: If ( mipmap_offset.size()>0) osgImage->setMipmapLevels(mipmap_offsets); 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. 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. 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. 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. Scott smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0
I had an issue with OSG 3.4.0 when using a compressed 32x32 texture causing an INVALID_OPERATION in Texture::applyTexImage2D_load when calling glCompressTexSubImage2D. This is called only when the texture storage object is used. This resulted in the texture rendering as black. Note that the texture was loaded from a IVE file created with an earlier version of OSG. After some investigation, I suspected that a possible cause was that the texture included mipmaps down to 2x2 and 1x1 in size. The S3TC compression being used has a block size of 4 so cannot be used for these small mipmap levels. Modifying numMipmapLevels by subtracting 2 if the image is compressed and using texture storage corrected the problem. However this is likely not the best solution. My limited knowledge of OpenGL and this error suggests that this may be highly dependent on the OpenGL implementation. I had several other compressed textures larger than 32x32 with mipmaps down to 2x2 and 1x1 that worked fine without this change. The OpenGL documentation (see EXT_texture_compression_s3tc among others) however states that if the width or height are not multiples of 4 then the result is an INVALID_OPERATION. This can go unnoticed when not using a texture storage object. But with the texture storage object, the error was generated when loading the full texture (i.e. level 0). If my understanding is correct, others may have had similar issues with compressed textures with mipmaps. They have worked around the issue by disabling mipmaps for compressed textures in ReaderWriterDDS for example. If the above holds true, then it may point to the underlying problem. Windows 7 64-bit, nVidia Driver 352.86, OSG 3.4.0 Scott smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
