2

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_IMG, nDataLen, pData2);

この更新が生成さglerror 1282(invalid operation)れました。1024*1024 領域全体を更新すると、すべて問題ありません。pvrtc テクスチャを部分的に更新できないようです。

pvrtc テクスチャを部分的に更新することは可能ですか?

4

3 に答える 3

1

GLES2ではできないように思えます（仕様へのリンク、3.7.3を参照）。

CompressedTexSubImage2D を呼び出すと、xoffset または yoffset がゼロに等しくない場合、または幅と高さがそれぞれテクスチャの幅と高さと一致しない場合、INVALID_OPERATION エラーが発生します。呼び出しによって変更された領域外のテクセルの内容は未定義です。これらの制限は、画像が簡単に変更される特定の圧縮された内部形式に対して緩和される場合があります

glCompressedTexSubImage2D は私には少し役に立たないように聞こえますが、個々のミップまたはテクスチャ配列レベルを更新するためだと思います。

于 2016-10-01T18:30:02.933 に答える
1

驚いたことに、小さな pvrtc テクスチャ データを大きなデータにコピーしました。これは glCompressedTexSubImage2D と同じように機能します。しかし、エンジンでこのソリューションを使用しても安全かどうかはわかりません。

于 2016-10-01T21:14:58.967 に答える
1

Rightly or wrongly, the reason PVRTC1 does not have CompressedTexSubImage2D support is that unlike, say, ETC* or S3TC, the texture data is not compressed as independent 4x4 squares of texels which, in turn, get represented as either 64 or 128 bits of data depending on the format. With ETC*/S3TC any aligned 4x4 block of texels can be replaced without affecting any other region of the texture simply by just replacing its corresponding 64- or 128-bit data block.

With PVRTC1, two aims were to avoid block artifacts and to take advantage of the fact that neighbouring areas are usually very similar and thus can share information. Although the compressed data is grouped into 64-bit units, these affect overlapping areas of texels. In the case of 4bpp they are ~7x7 and for 2bpp, 15x7.

As you later point out, you could copy the data yourself but there may be a fuzzy boundary: For example, I took these 64x64 and 32x32 textures (which have been compressed and decompressed with PVRTC1 @4bpp ) ...

enter image description here + enter image description here

and then did the equivalent of "TexSubImage" to get:

enter image description here

As you should be able to see, the border of the smaller texture has smudged as the colour information is shared across the boundaries.

In practice it might not matter but since it doesn't strictly match the requirements of TexSubImage, it's not supported.

PVRTC2 has facilities to do better subimage replacement but is not exposed on at least one well-known platform.

< Unsubtle plug > BTW if you want some more info on texture compression, there is a thread on the Stack Exchange Computer Graphics site < /Unsubtle plug >

于 2016-10-03T11:54:37.347 に答える