ミップマップと積分画像の両方を実現することは、結果のピクセル値が元のテクスチャ空間内の任意のポリゴンの積分ではないという問題があります。積分画像を使用してテクスチャ座標に軸合わせ矩形を統合するには、4つのテクスチャルックアップが必要です。ミップマップを使用すると、OpenGLはミップマップの4つの隣接ピクセル値を補間し、4つのメモリルックアップも補間します。積分画像を使用すると、必要なメモリが少なくて済む（余分な前処理済みの画像はなく、元の画像ではなく積分画像のみ）、レベル判定は不要です。もちろんこれはシェーダを使って実装できますが、（現在は推奨されていない）固定機能のパイプラインは、ミップマップのサポートとインテグラルイメージのサポートを備えていないのはなぜですか？あなたはより少ないメモリを必要とする積分画像を使用してなぜOpenGLはミップマップをサポートしていますが、インテグラルイメージはサポートしていませんか？
この文は
真実であることを私は非常に疑問私は積分画像の値が非常に大きい取得することができます理解して何から、それゆえ必要典型的な24ビットミップマップ（ミップマップは画像のサイズの2倍に過ぎない）よりもはるかに多くのスペースを使用する浮動小数点表現、および/または精度が低く、補間の際にノイズを生成する。また、浮動小数点画像は、固定機能パイプラインで頻繁に使用されていませんでした。また、GPUは浮動小数点画像ではるかに低速でした。
画像に整数を使用すると、積分画像に必要なビット深度が不当に高くなります（白い画像ではbitdepth = extents + 8になります。つまり、256x256画像では264bit /カラーチャンネル）を使用します。
なぜ、（現在は推奨されていない）固定機能パイプラインが、ミップマップサポートとインテグラルイメージサポートを備えて設計されたのですか？
ミップマップのアクセスと補間は、単純なハードワイヤード回路として構築できるためです。なぜテクスチャのディメンションが2の累乗でなければならないのか疑問に思ったことはありませんか？ミップマップ計算を一連のビットシフトおよび加算として実装する。ガウスピラミッド内の隣接要素にアクセスすることは、積分を評価することよりも少ないメモリアクセスしか必要としない。あなたの主な問題があります：フィルレート、つまりビデオメモリの帯域幅は、常にGPUのボトルネックになっています。
*咳*ミップマップは3分の1を追加します。彼らは倍増しません。あなたは1 + 1/4 + 1/16 +を保存しなければなりません。算術進行式を使用するか、バイナリ算術の本能を適用してください（2の累乗ではなく2つ置きに設定してください）。 – Tommy