2

自然に正方形ではないテクスチャ（たとえば、アスペクト比が4：1の写真のテクスチャ）があるとします。そして、PVRTC圧縮を使用して、このテクスチャをiOSデバイスに表示したいとします。これには、テクスチャが正方形である必要があります。圧縮時にテクスチャが正方形になるように拡大すると、テクスチャを遠くから見たときに非常にぼやけた画像になります。

これはミップマッピングが原因だと思います。ミップマップフィルターは新しいより大きな引き伸ばされた寸法を認識するため、それを使用して低いミップレベルを選択しますが、これらのピクセルはちょうどそのサイズに引き伸ばされているため、実際には正しくありません。他の次元を見ると、より高い解像度のmipレベルが選択されます。

この理論は、正方形である必要のない形式でテクスチャを残すと、ミップマップバージョンがちょうどダンディに見えるという観察によって（ある程度）確認されています。

LODバイアスパラメータがありますが、ドキュメントにはそれが両方の次元に適用されると書かれています。求められているのは、LODにバイアスをかける方法のようですが、1つの次元にのみバイアスをかけます（つまり、スケールアップされたテクスチャの次元でより高い解像度にバイアスをかける）。

元のテクスチャの正方形のサブセットを使用できるようにジオメトリを切り刻む以外に（これは実行不可能であり、本番パイプラインを提供します）、この問題に対処するために使用した巧妙なハックはありますか？

4

1 に答える 1

0

たとえば、頂点UVで何ができるかに応じて、いくつかのオプションがあるように思われます。

[うーん、以下では、V座標が上から下に伸びていると仮定していることに気づきました...私が古い学校であることを許可する必要があります:-)]

最初に頭に浮かぶのは、4N * N（X * Y）ソーステクスチャを垂直方向に4回繰り返して、4N * 4Nテクスチャを作成し、モデルのV座標を調整して1/4にすることです。現在の値。これにより、メモリの面で大きな節約にはなりませんが（4bpp PVRTCが4倍大きくなることを効果的に意味するため）、テクスチャの他の部分にアクセスできないため、帯域幅とキャッシュスペースを節約できます。MIPマッピングは、1x1テクスチャまでずっと機能します。

または、少しスペースを節約したい場合で、4N * Nテクスチャのペアがある場合は、それらを「一種の」4N*4Nアトラスにまとめてみることができます。最初のテクスチャを一番上のN行に配置し、次に一番上の行のN/2を続けます。2番目のテクスチャの下部のN/2行、2番目のテクスチャ、上部のN/2行の順にパックします。最後に、最初のテクスチャの一番下のN/2行を実行します。最初のテクスチャにアクセスするUVの場合、Vパラメータに対して同じ除算を4で行います。2番目のテクスチャでは、4で割り、0.5を追加する必要があります。これは、MIPマップレベルが小さくなり、2つのテクスチャがブレンドされるまでは正常に機能するはずです...しかし、それが本当に問題になるとは思えません。

于 2012-03-27T16:23:20.213 に答える