Opengl es 是否可以部分更新pvrtc纹理
我创建了一个1024*1024的纹理Opengl es 是否可以部分更新pvrtc纹理,opengl-es,pvrtc,Opengl Es,Pvrtc,我创建了一个1024*1024的纹理 glCompressedTexImage2D(GL_TEXTURE_2D, 0, GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IMG, 1024, 1024, 0, nDataLen*4, pData1); 然后像这样更新它的第一个512*512部分 glCompressedTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 512, 512, GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IM
glCompressedTexImage2D(GL_TEXTURE_2D, 0, GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IMG, 1024, 1024, 0, nDataLen*4, pData1);
glCompressedTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 512, 512, GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IMG, nDataLen, pData2);
glerror 1282（无效操作）是否可以部分更新pvrtc纹理，如果是如何更新的？在我听来，就像你在GLES2上无法更新一样（链接到，请参阅3.7.3。） 如果xoffset或yoffset不等于零，或者如果宽度和高度分别与纹理的宽度和高度不匹配，则调用CompressedExSubImage2D将导致无效的_操作错误。调用修改的区域之外的任何texel的内容都是未定义的。对于图像易于修改的特定压缩内部格式，可以放宽这些限制
使GLCompressedExSubImage2D听起来对我来说有点无用，tbh，但我想它是用于更新单个MIP或纹理数组级别的。令人惊讶的是，我将一个小的pvrtc纹理数据复制到了一个大的，它的工作原理与GLCompressedExSubImage2D一样。但我不确定在我的引擎中使用此解决方案是否安全。正确或错误地说，PVRTC1没有CompressedExSubImage2D支持的原因是，与ETC*或S3TC不同，纹理数据没有被压缩为独立的4x4个texel正方形，反过来，根据格式，可以表示为64位或128位数据。使用ETC*/S3TC，只需替换其对应的64位或128位数据块，即可替换任何对齐的4x4 texel块，而不会影响纹理的任何其他区域 PVRTC1的两个目的是避免块效应，并利用相邻区域通常非常相似的事实，从而可以共享信息。尽管压缩数据被分组为64位单元，但这些单元会影响texel的重叠区域。在4bpp的情况下，它们是7x7，对于2bpp，它们是15x7 正如您稍后指出的，您可以自己复制数据，但可能存在模糊边界：例如，我使用了这些64x64和32x32纹理（已使用PVRTC1@4bpp进行压缩和解压缩） + 然后做了相当于“TexSubImage”的操作，得到： 正如您应该能够看到的，随着颜色信息跨边界共享，较小纹理的边界已被弄脏 在实践中，这可能无关紧要，但由于它不严格符合TexSubImage的要求，因此不支持它 PVRTC2具有更好的子映像替换功能，但至少在一个知名平台上没有公开