- XORテクスチャは、ピクセルの x, y 座標を XOR して作るシンプルな手続き型テクスチャで、画像ファイルなしにテクスチャマッパーを素早く試すときに便利
- C++では
^ 演算子で x ^ y の値を作り、これを RGB に入れるとグレースケールのパターンが生まれ、XOR は 2 つのビットが互いに異なるときだけ 1 を返す
- テクスチャサイズは 2 の累乗 のときにパターンが見栄えよく、256 より小さいサイズでは値の範囲が狭く暗くなるため、色値を掛けて補正できる
- 256 より大きい XOR テクスチャは 8 ビットチャンネルの 0〜255 の色範囲 に制限されて品質が向上せず、より大きいサイズには値の除算やより多くのビットチャンネルが必要
- 同じ座標ベースの方式に
& と | を適用すれば AND、OR テクスチャも作れ、AND はより暗く、OR はより明るく、XOR と AND の和は OR になる
XORテクスチャが役立つ場面
- XORテクスチャは生成が非常に簡単で、見た目にもそれらしい手続き型テクスチャ
- デモやイントロのリリースではあまりに多用されているため良い選択ではなく、ゲームでも派手な床タイルのような用途でもない限り実用性は低い
- 画像ファイルを読み込んだり複雑な生成コードを書いたりせずに、新しい テクスチャマッパー が動作するかを素早く確認できる
座標 XOR でパターンを作る
- 基本のアイデアは、現在のピクセルの
x 座標と y 座標を XOR すること
- C++での XOR 演算子は
^
- 例のコードでは 256×256 画面のすべてのピクセルについて値を計算する
Uint8 c = x ^ y
ColorRGB(c, c, c) でグレースケールの色を設定する
- 実行結果は、座標のビットパターンが結合された XORパターン として現れる
サイズと色範囲の制約
- テクスチャサイズは 2 の累乗 のときのほうがパターンが見やすい
- 色コンポーネント値は 0 から 255 まで
- XOR 演算で生成される最大の色値は、テクスチャサイズが 2 の累乗である場合、テクスチャの次元と同じになる
- 64 のように 256 より小さいパターンは暗すぎて見える
- 色値を 4 倍に掛ければ明るさを戻せる
- 512 のように 256 より大きいサイズでは、色が 256 を超えないように制限する必要がある
- 256 で剰余を取ることもできるが、そうすると本来の XOR パターンではなくなる
- 2 で割るほうがよい
- 8 ビットチャンネルでは区別可能な色値が不足するため、256×256 より大きい XOR テクスチャでも品質は高くならない
- より多くのビット数をサポートするカラーモードなら、大きなテクスチャの限界は変わる可能性がある
XOR演算のビット動作
- XOR は 2 つの整数の 2 進表現において、対応する各ビットごとに演算を行う
- Exclusive OR は 2 つのビットが異なれば 1、同じなら 0 を返す
- 真理値表は次のとおり
0 XOR 0 = 0
0 XOR 1 = 1
1 XOR 0 = 1
1 XOR 1 = 0
- たとえば
5 XOR 13 = 8
- 2 進数では
0101 XOR 1101 = 1000
色のバリエーション
- XOR 値はグレースケールだけでなく、RGB の各チャンネルに別々に適用することもできる
- 例では
c = x ^ y を使って色を構成する
r = 255 - c
g = c
b = c % 128
- XOR 値を HSV 色空間の hue として使い、
HSVtoRGB 関数に渡すこともできる
- 例では
ColorHSV(c, 255, 255) を HSVtoRGB に変換してピクセル色として使う
AND と OR テクスチャ
- XOR の代わりに AND と OR 演算子を使っても、似たような座標ベースのテクスチャを作れる
- C++での AND 演算子は
&、OR 演算子は |
- AND は 2 つのビットがどちらも 1 のときだけ 1 を返す
0 AND 0 = 0
0 AND 1 = 0
1 AND 0 = 0
1 AND 1 = 1
- OR はどちらか一方、または両方が 1 なら 1 を返す
0 OR 0 = 0
0 OR 1 = 1
1 OR 0 = 1
1 OR 1 = 1
- AND テクスチャは 1 を返す場合が 1 つしかないためより暗く、OR テクスチャは 1 を返す場合が多いためより明るい
- XOR テクスチャと AND テクスチャの和は ORテクスチャ になる
結論と活用例
- XOR テクスチャは作りやすく、テクスチャレンダラーが動作しているかをテストするのに有用
- アート制作やゲームのようなアプリケーションには向いていない
x ^ y ^ z 形式の 3Dテクスチャ としても使え、例では惑星テクスチャレンダラーが正しく動作するかの確認に使われている
1件のコメント
Hacker News のコメント
そのおかげで Pacman、Snake、Space Invaders のようなレトロゲームを再実装できるようになり、端末だけでは不可能だった作業ができるようになりました。
このサイトが、かなり若い頃にソフトウェア開発のキャリアを始めるきっかけになったと思います。当時は https://lodev.org/cgtutor/ のページとサンプルをほとんど暗記するほど読み込んでいましたが、数学の一部はその頃まったく理解できませんでした。
x ^ yの代わりにparity(x ^ y)を使い、1 ビットの数が偶数なら一方の色、奇数ならもう一方の色で塗るようにしたところ、ほとんど繰り返しているようで完全には繰り返さないタイル模様のように見えて、視覚的に面白いものでした。古いファイルを探してみると、2019 年に fasm で書いていて、XPM2 ファイルを生成しており、見るには手動で XPM3 に変換する必要がありました。結果の画像はこちらです: https://i.postimg.cc/FsFhXSHG/xortiles.png
望まれればコードを上げることもできますが、そこまで関心があるかは分かりません。
Xor(x,y)なら、ハミング距離はPopCount(Xor(x,y))になりそうです。たぶん?
自分のブログをさりげなく投げて身をかわします: https://nicknash.me/2012/10/26/happy-halloween/
5 4 7 6 1 0 3 2color = (y == (x ^ t))のような関数で t の値を変えながらアニメーションさせると似た効果が出ますが、これは munching squares と呼ばれています。もともとは 1960 年代初頭に PDP-1 用に書かれたもので、Computer History Museum の PDP-1 で実演されるのを見たことがあります。
PDP-1 のディスプレイは点を打つことしかできず、ビットマップのフレームバッファを使わないのに、どうやって特有の XOR テクスチャが作られるのかずっと不思議でした。
実際には、画面の蛍光体の長い残光を利用し、各点の明るさが時間とともに減少する仕組みでした。
CHM に実行動画がありますが、蛍光体の残光効果はあまり捉えられていません: https://www.computerhistory.org/collections/catalog/10266415...
MAME で実行した動画では、蛍光体の残光が XOR テクスチャを作る過程がある程度分かります: https://youtu.be/AxJzUiaQ7xM?si=X9K47c4WyD6AisUp
Dwitter は canvas を使う 1 行の JavaScript サンプルのための Twitter のような場所で、ユーザーは作品を 140 バイト以内に収める必要があります。
別の二項演算子を使って シェルピンスキーの三角形を作るいくつもの派生もあります: https://www.dwitter.net/h/sierpinski
サイトの最後のほうの図のひとつに出てくるものと同じ虹色のカラースケールを使ったのでかなり似て見え、6 フィート×6 フィートの装飾として壁に掛けています。
20 年前の資料ですが、特に シェーダー作業をしているなら、今でもあちこちで使える内容がたくさんあります。
~:"1/~&.#:i.2^8ここで見られます: https://jsoftware.github.io/j-playground/bin/html2/#base64=b...