koturnの日記

普通の人です.ブログ上のコードはコピペ自由です.

PNGファイル再圧縮ツールを改良した

TL;DR

2020-12-07にも記事を書いたツールだが,当時より機能追加を行ったため,再度記事を書くことにした. 大きくは下記4点が追加となった.

  1. VRMファイルを処理可能になった
  2. 元のPNGファイルの画像フォーマットをそのままにしておくオプションの追加
  3. IDATのデータ部のサイズを指定可能にした
  4. 全チャンクの保存オプションの追加

リポジトリと実行バイナリ配布場所は下記の通り.

f:id:koturn:20210707033537p:plain
再圧縮前後の様子

1. VRMファイルを処理可能になった

VRMファイルをパースし,内部にPNGファイルデータが含まれる場合,再圧縮を行えるようにした. VRMファイル自体は先頭にjsonがあり,その後にバイナリデータが続き,json内のオフセットと長さ情報からデータを切り出すことが出来る形式のファイルとなっている.

なので,

  1. ファイル先頭のjsonをパース
  2. PNGデータを取り出す
  3. PNGデータを再圧縮
  4. 再圧縮したPNGデータをバイナリデータ部に書き戻す
  5. json全体のオフセットと長さ情報をすべて更新
  6. ファイルとして書き出す

という処理でVRMファイル内のPNGファイルデータの再圧縮を実現している.

2. 元のPNGファイルのピクセルデータフォーマットをそのままにしておくオプションの追加

前の記事にも書いていることであるが,再度書く.

これはzopflipng コマンド では存在している --keep-color-type オプションを使用できるようにしたものである. Google公式のリポジトリのものでは,zopflipng.dllからは --keep-color-type に相当する指定を行うことが出来ないが,クローンしたリポジトリではこの指定が可能になるような修正を行っている.

zopflipngは画像データの展開結果が変化しない(ビットマップデータへ展開した結果,元のものと全画素データを比較しても差がない)ならば,ピクセルデータフォーマットを変更することがある. 例えば,

  1. アルファ値が全て255であるARGB32bit形式をRGB24bit形式に変換
  2. 全体として256色以内の色数しか使われていない画像を8bitインデックス画像に変換
  3. 2とは逆に1bpp(2色のインデックス画像,1byteあたり8ピクセル)をRGB24bit画像変換
    • PLTE チャンクの削減によりデータサイズが小さくなることがある

といった変換を行うことがあり得る. 基本的に画像データの見た目に差が生じるわけではないので,問題が生じることはないが,3. の変換が生じた場合,インデックス画像しか取り扱えないアプリケーションで画像データを開けなくなる(特にEdge等のドット絵ツール). そのため,画像データフォーマットを保持する機能は欠かせない.

3. IDATのデータ部のサイズを指定可能にした

zopflipngは少しでもファイルサイズを削減するために,PNGファイルのIDATチャンクを1つにまとめる(IDATチャンクのデータ部ノサイズは自由であるため,1まとめにすることも分割することも可能.ただし,IDATチャンク1つにつき,データ長,チャンク種別,CRC-32の分のサイズオーバーヘッドが12 Bytesある). しかし,人によってはIDATチャンクをデータ部のサイズが最大8192 Bytesになるように分割したい,あるいはWindowsのpaint.exeのように65535 Bytes近くになるように分割したいという人もいるかもしれない.

そのため,PNGデータの再圧縮完了後にIDATチャンクを分割する処理を行うことができるように,オプション --idat-size を追加した.

このオプションを指定しなかったり,0やマイナスの値を指定すると,今まで通りIDATの分割処理を行わないが,例えば --idat-size=8192 と指定するとIDATチャンクのデータ部がそれぞれ最大8192 BytesとなるようにIDATチャンクを分割する.

IDATチャンクを小さくすることで,PNGデコーダの読み取り時の一時バッファのサイズを小さく保つことが出来るようになるが,これが速度面に寄与するかどうかは不明である. PNGの仕様としては下記の記述があるだけで,C言語的な時代を感じる.

Multiple IDAT chunks are allowed so that encoders can work in a fixed amount of memory; typically the chunk size will correspond to the encoder's buffer size.

VRChatやclusterの画像データ,またはGIMPといったアプリケーションが生成するPNGファイルのIDATチャンクのデータ部のサイズとしては 8192 Bytes が採用されている. これはおそらくlibpngのデフォルトのIDATのサイズなのではないかと思う.

4. 全チャンクの保存オプションの追加

--keep-all-chunks というオプションを指定すると,すべてのチャンクを保持したままにするようにした. このオプションは --keep-chunks=acTL,bKGD,cHRM,eXIf,fcTL,fdAT,gAMA,hIST,iCCP,iTXt,pHYs,sBIT,sPLT,sRGB,tEXt,tIME,zTXt を指定したのと同じ効果である.

zopflipngはファイルサイズを小さくすることを最優先にしているので,必須ではないチャンクは基本的に除去する. 以前のものでも保持したいチャンクは --keep-chunks= で指定することで残すことが出来たが,雑にメタデータチャンクを残したい場合にでも1つ1つチャンク名を指定しなければならないのは面倒であったため,このオプションを追加した.

裏で改善したところ

以下の項目は特に機能追加ではなく,ほとんどが自己満足的な改良である.

.NET 5への移行

最初は.NET Framework 4.8で作成していたが,最新のC#と標準ライブラリ(SpanSIMDAPI)を利用したかったので,.NET 5に移行した.

.NET 5では,.NET 5依存のバイナリをそのままリリースすることもできるし,Self-Containedという実行環境にて.NET 5が不要になるバイナリの作成を行うこともできる(その分ファイルサイズがかなり大きくなるが).

再圧縮結果のアンマネージドメモリをそのまま使うようにした

以前は koturn/ZopfliSharp にて,zopflipng.dll の関数呼び出しより得たアンマネージドメモリはすぐさま同サイズのマネージドメモリを確保し,そこにコピーし,そのマネージドメモリを返却するようにしていた

よく知られているように,.NETでは85KB以上のメモリ確保を行うと,LOHに確保されてしまう. 僕がよく再圧縮処理対象にするVRChatやclusterのPNGファイルはサイズが大きいため,再圧縮結果が85KB以内に収まるということはあまりない(VRChatの画像の多くは1.5MB,clusterの画像は1MB弱程度になる). そのため,このメモリアロケーションが気になっていた.

そこで,アンマネージドメモリを SafeBuffer として返却するメソッドをkoturn/ZopfliSharp追加し,それを利用するようにした. この変更により,処理時間が劇的に短くなるわけではないが,P/Invoke用のライブラリを作った以上はこのメソッドは欲しかったのと,趣味プロダクトであるので,微々たる処理の最適化を行いたかった.

再圧縮結果がオリジナルのものより悪ければ,オリジナルの方をそのまま使うという処理のために byte 配列と SafeBuffer を混在して扱う必要が生じたが,前述の通り,.NET 5へ移行したので,Span を利用し,統一的に扱うことによってコードをシンプルに保った. SafeBuffer から Span を生成するのにあたって下記のようにした.

private static unsafe Span<byte> CreateSpan(SafeBuffer sb)
{
    return new Span(sb.DangerousGetHandle(), (int)sb.ByteLength);
}

また,再圧縮のVerificationに必要な Bitmap インスタンスの生成にPNG画像データの Stream が必要になるが,UnmanagedMemoryStream を利用すれば,byte 配列に対する MemoryStream と同じノリで扱うことができる.

private static Bitmap CreateBitmap(SafeBuffer sb)
{
    using ums = new UnmanagedMemoryStream(sb, 0, (long)sb.ByteLength);
    return (Bitmap)Image.FromStream(ums);
}

SafeBufferDispose() メソッドの呼び出しで,中身のアンマネージドメモリを解放することができるので,using句を用いればメモリ解放漏れは無くなる.

using (var sb = Zopfli.OptimizePngUnmanaged(data, 0, data.Length))
{
    // 処理
}

画像比較ログの改善

zopflipngによる再圧縮のVerificationとして,元の画像と比較する機能がある. 以前は画像フォーマットが異なる場合,画像に差があることしかわからないログであったが,どのように画像フォーマットが変化したかわかるようにログ出力するようにした.

参考

clusterの写真リネームツールを作った

TL;DR

clusterで撮影した画像ファイルの一括ダウンロードで得られるzipファイル内のPNGファイル名を cluster_yyyy-MM-dd_HH-mm-ss_XXX.png という形式にリネームするツールを作った(yyyyMMddHHmmss は撮影日時の年月日時分秒,撮影日時=ファイル作成日時=ファイル最終更新時刻). ついでに,PNGファイルにメタ情報として,ファイル撮影日時を埋め込むようにした.

背景

clusterのPNG画像はGUID形式のもので整理するのに不便という話がいつもたむろしているDiscordのチャットにあった. 複数選択して一括ダウンロードしたPNG画像はタイムスタンプが保持されていることは知っていたので,zipファイルを突っ込んだら中のファイルをリネームして,新しいzipファイルを作るCLIツールを作成した. また,画像のメタデータとして日付とかを持てるといいかもという話もあったので,ついでにそれも追加するようにした.

(ファイル名がGUIDであるのは,DBに突っ込む上での都合なのかどうかという想像が出来て楽しいところ)

PNGファイルの構造

PNGファイルの構造は非常に単純であり,先頭8バイトにシグネチャがあり,そこから下記の形式のチャンクが続くだけである. ただし,データ長やCRC-32といった数値はビッグエンディアンであることに注意しなければならない.

サイズ 意味
4 Bytes チャンクデータ長(N)
4 Bytes チャンク種別を示すASCIIテキスト4文字(IHDR, IDAT, tEXt など)
N Bytes チャンクに応じたデータ部
4 Bytes チャンク種別とデータ部のCRC-32

最初にIHDR,最後にIEND,IDATチャンクが複数ある場合はIDATチャンクの間に他のチャンクが存在してはならず,データ順になるように連続していなければならない等の制約があるが,全体的な構造を示す部分はなくただチャンクが並んでいるだけなので,チャンクの追加は容易である.

チャンク種別のASCII文字の何文字目が大文字か小文字かによって,チャンクの特性を表現している.

文字 意味
1文字目 大文字であれば必須チャンク
2文字目 大文字であれば仕様が公開・定義されているもの
3文字目 将来のために予約されているが,現在は常に大文字
4文字目 大文字の場合,他の必須チャンクの影響を受けるので,そのままコピーはできない

tEXtチャンク

tEXtチャンクの構造は下記の通り. データ部がASCII文字でキーと値がNULL文字で区切られている構造となっている. 仕様としては,キー部は80文字以内という但し書きがある.

サイズ 意味
4 Bytes データ長(M + 1 + N)
4 Bytes tEXt
M Bytes キー文字列
1 Byte \0 (NULL文字)
N Bytes 値となる文字列
4 Bytes CRC-32

Creation Time

WindowsエクスプローラではPNGファイルにキー:Creation Time,値:yyyy:MM:dd HH:mm 形式の時刻文字列のtEXtチャンクが存在する場合,それを撮影日時として表示する仕様となっているようだ. そのため,PNGファイルにキー:Creation Time,値:ファイル最終更新時刻をyyyy:MM:dd HH:mm:ss形式にした文字列 を埋め込む機能を入れた. これにより,ファイル名を手動で再度リネームしても更新時刻は失われなくなる. なお,ファイル1つにつき,31 Bytesサイズが増加するが微々たるものであるため,良しとした.

PNGの仕様としては時刻文字列としては RFC 1123 が推奨されるようだが,利便性を考え,Windowsエクスプローラ形式を採用した.

Title

ファイルをリネームするにあたって,もともとのファイル名もメタデータとして残すことにした. というのも,clusterのPNGファイル名はGUID形式のものであり,重複は基本的にない一意のものであると見做せるためだ. だからといって何かになるわけではないが,今後何かあったときに役立てることが出来る可能性がある.

tIMEチャンク

PNGファイルの仕様として,最終更新時刻を保持するためのチャンクも用意されている. これを設定したからといって,エクスプローラの表示に影響を与えるわけではないが,ついでなので追加することにした. UTC(あるいはGMT)の時刻が推奨されるため,UTCに変更して保存するようにした. そのため,値だけ見ればCreation Timeに保存した時刻と9時間のズレがある.

サイズ 意味
4 Bytes データ長(7)
4 Bytes tIME
2 Bytes
1 Byte
1 Byte
1 Byte
1 Byte
1 Byte
4 Bytes CRC-32

zipファイルの時刻精度について

zipファイルの仕様上,zipファイル内のファイルの時刻精度は2秒刻みである. そのため,時刻を含むだけの形式では,ファイル名重複が容易に起こりうるため,連番部分を追加している. 敢えてミリ秒っぽく3桁分を用意しているが,clusterではどう努力しても2秒以内に100枚以上のファイルどころか10枚以上のファイルの保存はできないと思われるので,1桁でもよいのではないかと思ってはいる.

あえてやらなかったこと

clusterの写真ファイルは保存速度のため,圧縮率レベルは1にして保存しているらしい(これはVRChatの写真も同様). (PNGの画像データはzlib形式のDeflate圧縮を採用しているので,実際に伸長して再圧縮して確かめてみた感じだと,zlibの最低の圧縮レベル圧縮率を指定したときと同一の結果となった) なので,ある程度の圧縮レベルにして,再圧縮するようにすれば,追加したチャンク分以上にデータサイズを削ることが出来ると考えた. だが,あくまでリネームツールのため,再圧縮は範疇外として採用しなかった. (再圧縮の処理時間が1秒だとしても対象ファイルが600枚あれば10分はかかってしまう)

同様の理由でIDATチャンクの結合も行わないことにしている(clusterのPNG画像はIDATのデータ部を 8192 Bytes 毎になるように分割している.IDATを結合することで,IDAT1つあたり 12 Bytes(データ長 + チャンク種別 + CRC-32) のファイルサイズを削減することが出来る).

再圧縮については,別で作成したPNGファイルの超圧縮ツールの役割であると思う.

参考

zipファイルの再圧縮ツールを作った

TL;DR

zopfliを用いて,zipファイルを再圧縮し,よりよい圧縮結果を得るCLIツールを作成した.

元ネタはkomiya-atsushi/zipzopであり,これをC# で再実装したものとなるが,

  1. ファイル単位での並列処理が可能
  2. zopfli.dll の関数に渡せるオプションを全て指定可能

という点が異なる.

背景

zopflipngを用いたPNG再圧縮ツールを作成した際に,「多くのzipファイルにもDeflate圧縮が用いられているのだから,zopfliでzipファイルを再圧縮できるはずだ」と考えていた.

探してみると,komiya-atsushi/zipzopというリポジトリが見つかった. しかし,zipファイル内のPNGファイルを並列で再圧縮するツールを作っていた身としては,並列処理できない点を不満に思った.

zopfliのP/Invoke用のライブラリは作成していたので,とりあえずC# で上記のツールを実装することにした.

使用方法

下記の通り. ディレクトリ指定時はそのディレクトリをzipファイルに圧縮した後,再圧縮を行う.

> RecompressZip.exe 【オプション】... 【zipファイル or ディレクトリ】...

オプション

オプション 機能
-b 【数値】, --block-split-max=【数値】 最大のブロック分割数を指定する.0は無制限を意味する.デフォルトは15.
-d, --dry-run 圧縮処理は行うが,ファイル内容の置き換えは行わない.ベンチマーク用のオプション.
-h, --help 使い方を表示し,プログラムを終了する.
-i 【数値】, --num-iteration=【数値】 最大の繰り返し回数を指定する.デフォルトは15.
-r, --replace-force 再圧縮の結果がオリジナルよりも悪かったとしても置き換えを行うようにする.
-v, --verbose zopfli.dllからの標準エラー出力へのデバッグ出力を有効にする.
-V, --verbose-more zopfli.dllからの標準エラー出力へのより詳細なデバッグ出力を有効にする.
--no-block-split ブロック分割を行わないようにする.
--no-overwrite 元のzipファイルの置き換えを行わないようにする.

使用した所感

7zipで作成した最高レベルの圧縮率のzipファイルに対して使用してみたところ,おおよそ1つのファイル(zipファイルエントリ)につき1%弱程度より圧縮することができた. しかし,ファイルによっては7zipの方が結果が良いこともあり,zopfliが万能ということでもなさそうだ.

普段はzipファイルを作成するときには,7zipで作っておいて,数バイトでも小さくしたいならば,本ツールにて再圧縮をかけるとよいと思う(-r を指定しない限り,元のものより悪い結果は採用しない).

または,Excelファイル(.xlsx)のようなアプリケーション自体がさほど圧縮率を気にせずに作成したzipファイルに対して,このツールを用いるとよいと思われる.

制限事項

元ネタをそのまま実装した形なので,下記の通り. これらについては特に対応することを考えていない.

  • 暗号化zip非対応
  • Deflate圧縮以外はそのまま格納(Deflate64も)

参考

Unityのシェーダで原点・XZコンパスを実装した

TL;DR

  • 常に原点を指す,またX軸,Z軸を指す針も含むシェーダを作った.
  • VRChatのアバターに付けるとベンリかもしれない

背景

シェーダで取得できるモデル行列 unity_ObjectToWorld から平行移動成分,すなわちワールド座標を取得して,表示するシェーダは簡単にできた. そこで,ワールド座標に対するコンパス(羅針儀)が作れないかと考えて実装することにした.

現実世界でのコンパスといえば北を指すものである. だが,VRにおいては北は存在しないので,原点を指すものを作ることにした. また,ベンリだと思ったので,X軸も指すようにした.

原理

ワールド座標の取得

シェーダで利用できるモデル行列は unity_ObjectToWorld である. この行列はローカル座標をワールド座標に変換する行列で,拡大・回転・平行移動を行う同次変換行列である.

端的には,ヒエラルキのトップにオブジェクトを持っていったときのTransformのPosition,Rotation,Scaleを反映する行列と言える(はず).

具体的には下記のようになっている.

\begin{equation} \boldsymbol{M} = \begin{pmatrix} a & b & c & T_{x} \\ d & e & f & T_{y} \\ g & h & i & T_{z} \\ 0 & 0 & 0 & 1 \end{pmatrix} \end{equation}

$a$ ~ $i$ が拡大・回転の成分であり,$T_{x}$ ~ $T_{z}$ が平行移動の成分である. $a$ ~ $i$ はX軸まわり,Y軸まわり,Z軸まわりの回転が絡んだものになっているので,$\sin$,$\cos$ を使って表現するとごちゃごちゃした形になる.その中身の成分それぞれを求める必要はないので,拡大・回転成分が入っている,とだけ覚えておく.

$n$ 次元のものを扱う際,$n + 1$ 次元の行列,ベクトルを導入すると定数項を積に組み込んでまとめて扱えるのでベンリである(大学の画像処理やロボティクス,多変量解析や機械学習の授業でも習う算数のテクニックである).

unity_ObjectToWorld からワールド座標成分 $\boldsymbol{v}_{T}$ を抜き出すには,

\begin{equation} \boldsymbol{v}_{T} = \begin{pmatrix} a & b & c & T_{x} \\ d & e & f & T_{y} \\ g & h & i & T_{z} \\ 0 & 0 & 0 & 1 \end{pmatrix} \begin{pmatrix} 0 \\ 0 \\ 0 \\ 1 \end{pmatrix} = \begin{pmatrix} T_{x} \\ T_{y} \\ T_{z} \\ 1 \end{pmatrix} \end{equation}

とすればよい.

X軸方向の取得

XZ平面において,X軸を始点としたときのXZ平面上のベクトル($ \boldsymbol{v} = (v_{x}, v_{z}) $)の角度 $\theta$ は

\begin{equation} \theta = \arctan \left( \frac{v_{z}}{v_{x}} \right) \end{equation}

である.

X軸方向を取得するには,X軸が対象のオブジェクトがワールド座標系において,どれだけ回転しているかを知ることができればよい.

まず,X軸のベクトル $\boldsymbol{v}_{X} = (1, 0, 0)^{T}$ (とりあえず単位ベクトルで良いだろう) に対し,モデル行列の回転・拡大の要素のみを作用させ,それがどれだけ元のX軸のベクトルから回転しているかを考える. モデル行列の平行移動成分をゼロにする手もあるが,実装としてはバーテックスシェーダで予め計算した値を用いる方がよいと思うので,モデル行列を作用させたベクトルから,ワールド座標(平行移動成分)を引く手段を取る.

すなわち,

\begin{equation} \boldsymbol{v}_{M} = \boldsymbol{M} \boldsymbol{v}_{X} - \boldsymbol{v}_{T} \end{equation}

である.

ここで,XZ平面(Y軸からの視点)で考える.

$\boldsymbol{v}_{M}$ と $\boldsymbol{v}_X$ (X軸)のなす角 $\theta_{M}$ はまさしく逆正接の値なので,

\begin{equation} \theta_{M} = \arctan \left( \frac{v_{M_{z}}}{v_{M_{x}}} \right) \end{equation}

となる.

UV座標

テクスチャとしてはX軸の正方向とX軸から反時計周りに $\frac{\pi}{2}$ に回転させた位置に矢印があるだけのものを用意した.

f:id:koturn:20210420191014p:plain
XZ軸画像

UV座標としては,X軸矢印は中心 $(0.5, 0.5)$ から $\theta_{M}$ だけ回転した位置にもってくるのではなく,$0$ の位置にそのままあればよいので,UV座標の回転角 $\phi_{M}$ は,

\begin{equation} \phi_{M} = \theta_{M} \end{equation}

となる.

サンプリングUV座標を正の方向(反時計周り)に回転させた場合,第三者の目線としては,マイナス方向(時計周り)にテクスチャ画像が回転しているように見える. これがどの向きでも常にX軸を指すという挙動である.

原点方向の取得

モデル行列が平行移動成分のみで構成されている($a, e, i = 1; ~ b, c, d, f, g, h = 0$)のであれば,オブジェクトのワールド座標ベクトルとX軸となす角は

\begin{equation} \theta_{T} = \arctan \left( \frac{v_{T_{z}}}{v_{T_{x}}} \right) \end{equation}

であるので,原点方向はその反対向きの

\begin{equation} \theta_{O}' = \theta_{T} + \pi \end{equation}

である.しかし,モデル行列に回転・拡大成分があるならば,その分を加味する必要がある.

\begin{equation} \theta_{O} = \theta_{T} - \theta_{M} + \pi \end{equation}

UV座標

テクスチャとしてはX軸の正方向に矢印があるだけのものを用意した.

f:id:koturn:20210420191139p:plain
原点矢印画像

UV座標としては,中心 $(0.5, 0.5)$ から $\theta_{O}$ だけ回転した位置に目的のテクセルがなければならないので,$\theta_{O}$ の正負を反転させたものが,UV座標の回転角 $\phi_{O}$ となる.

\begin{equation} \phi_{O}' = -\theta_{O} = -(\theta_{T} - \theta_{M} + \pi) = \theta_{M} - \theta_{T} - \pi \end{equation}

角度なので $2\pi$ を加えてもよく,

\begin{equation} \phi_{O} = \phi_{O}' + 2\pi = \theta_{M} - \theta_{T} + \pi \end{equation}

として,$\pi$ の項を正にしておくと個人的にスッキリする(気持ちの問題).

まとめ

モデル行列 unity_ObjectToWorld を利用すればワールド座標だけでなく,原点の方向,軸の方向を取得することができる.

やっていることは高校生レベルの算数であるが,回転角の正負に関してはエイヤッとシェーダを変更して,Unity上で確認という行き当たりばったりに実装していったため,ある程度言語化するためにこの記事を書いた.

まだ不完全であるため,随時加筆修正すると思う.

シェーダで原点・XZコンパスを実装したモチベーションは,単に実装できそうだからという理由でしかないが,もしかしたらVRChatの広大なワールド散策で役に立つこともあるかもしれない.

カスタムレンダーテクスチャでライフゲームを実装した

TL;DR

カスタムレンダーテクスチャでライフゲームを実装してVRChatのアバターに付けた.

f:id:koturn:20210410201058g:plain
ライフゲーム

背景

オタクはすぐにシェーダでライフゲームを実装するもの,らしい.

N番煎じではあるが,VRChatのアバターライフゲーム付けるのはすぐにできるなと思ったので実装した. カスタムレンダーテクスチャは1つ前の状態を取れるので,ライフゲームの実装をするのにもってこいというわけである.

初めてシェーダを書いたが,作る中で色々と学びがあったので,記事を書くことにした.

作り

  1. ランダムな初期化を行わない
  2. 初期状態は画像ファイルを与える
  3. 振動子や移動物体等の永遠に生存するもののみを対象にする
  4. アルファ値0.0を死滅状態,それ以外を生存状態とする(生存状態のアルファ値は自由に設定可能)

初期化画像

初期化画像として下記のような死滅セルはアルファ値0,生存セルは色付き(下記の例では RGBA = (0, 255, 0, 255))で1bpp(2色パレット)のPNG画像を採用した.

f:id:koturn:20210411180245p:plain
初期化画像(Galaxyパターン)

1bppのPNG画像を採用した理由としては以下の3点である.

  • ライフゲームでは2値あれば十分である
  • 2値画像を表現する際,1bppパレット形式が基本的に最小データサイズの表現形式である(※)
  • パレット形式のPNG画像なら編集できるドット絵ツールがある

※IDATチャンクが十分に小さいとき(画像の縦と横のサイズが十分に小さいなど),各チャンクのヘッダとパレット自身のサイズが占める割合が多くなるため,32bppARGB形式の方が小さくなる場合もある

ただし,初期化画像で参照するのは,あくまでアルファ値のみなので,死滅セルのアルファ値が0であれば セルの色自体はシェーダにプロパティを設け,カスタムレンダーテクスチャ用のマテリアルのインスペクタを通じて設定できるようにした.

また,上記の例のテクスチャ画像の縦横のサイズは16x16 pixelである. これは4の倍数かつ2のべき乗のサイズでGalaxyパターンが繰り返し可能な最小の画像サイズのためである.

初期化画像の設定

画像がかなり小さいサイズであるのと,ピクセルをハッキリさせたいので,Filter ModeはPoint (no filter)にする.

f:id:koturn:20210410195928p:plain
初期化画像の設定

シェーダーの全容

ライフゲーム用のカスタムレンダーテクスチャのシェーダは下記の通り.

Shader "koturn/GameOfLife"
{
    Properties
    {
        // shader_feature: _CUTOUTSIDE_ON
        [Toggle]
        _CutOutside ("Cut outside of texture; Treat as zero outside texels", Float) = 0

        _Color ("Cell Color", Color) = (0.0, 1.0, 0.0, 1.0)
    }
    SubShader
    {
        ZTest Always
        ZWrite Off
        Lighting Off

        Pass
        {
            Name "Update"

            CGPROGRAM
            #pragma target 3.0

            #include "UnityCustomRenderTexture.cginc"

            #pragma vertex CustomRenderTextureVertexShader
            #pragma fragment frag
            #pragma shader_feature _ _CUTOUTSIDE_ON

            //! 浮動小数点演算誤差許容範囲
            static const float eps = 1.0e-3;
            //! 全要素1のベクトル
            static const float3 ones3 = float3(1.0, 1.0, 1.0);
            //! 生存セルの色
            uniform float4 _Color;

#ifdef _CUTOUTSIDE_ON
            /*!
             * @brief テクスチャ座標外の指定時は(0.0, 0.0, 0.0, 0.0)を返すtex2Dを行う
             * @param [in] tex テクスチャサンプラー
             * @param [in] uv  UV座標
             * @return テクスチャ座標外の指定時は(0.0, 0.0, 0.0, 0.0),テクスチャ座標内はテクセルの色
             */
            inline float4 tex2DCutOutside(sampler2D tex, float2 uv) {
                const float2 v = step(0.0, uv) * step(uv, 1.0);
                return v.x * v.y * tex2D(tex, uv);
            }
#endif  // _CUTOUTSIDE_ON
            /*!
             * @brief フラグメントシェーダ
             * @param [in] i  カスタムレンダーテクスチャの入力値
             * @return 1つのテクセルに対するRGBA値
             */
            float4 frag(v2f_customrendertexture i) : COLOR
            {
                const float2 d = float2(1.0 / _CustomRenderTextureWidth, 1.0 / _CustomRenderTextureHeight);
                const float2 uv = i.globalTexcoord;

#ifdef _CUTOUTSIDE_ON
                const float3x3 neighbor3x3 = step(_Color.a, float3x3(
                    tex2DCutOutside(_SelfTexture2D, uv - d).a,
                    tex2DCutOutside(_SelfTexture2D, float2(uv.x, uv.y - d.y)).a,
                    tex2DCutOutside(_SelfTexture2D, float2(uv.x + d.x, uv.y - d.y)).a,
                    //
                    tex2DCutOutside(_SelfTexture2D, float2(uv.x - d.x, uv.y)).a,
                    0.0,
                    tex2DCutOutside(_SelfTexture2D, float2(uv.x + d.x, uv.y)).a,
                    //
                    tex2DCutOutside(_SelfTexture2D, float2(uv.x - d.x, uv.y + d.y)).a,
                    tex2DCutOutside(_SelfTexture2D, float2(uv.x, uv.y + d.y)).a,
                    tex2DCutOutside(_SelfTexture2D, uv + d).a));
#else
                const float3x3 neighbor3x3 = step(_Color.a, float3x3(
                    tex2D(_SelfTexture2D, uv - d).a, tex2D(_SelfTexture2D, float2(uv.x, uv.y - d.y)).a, tex2D(_SelfTexture2D, float2(uv.x + d.x, uv.y - d.y)).a,
                    tex2D(_SelfTexture2D, float2(uv.x - d.x, uv.y)).a, 0.0, tex2D(_SelfTexture2D, float2(uv.x + d.x, uv.y)).a,
                    tex2D(_SelfTexture2D, float2(uv.x - d.x, uv.y + d.y)).a, tex2D(_SelfTexture2D, float2(uv.x, uv.y + d.y)).a, tex2D(_SelfTexture2D, uv + d).a));
#endif  // _CUTOUTSIDE_ON
                const float sum = mul(mul(ones3, neighbor3x3), ones3);

                const float a = _Color.a * (step(abs(sum - 3.0), eps)
                    + step(_Color.a, tex2D(_SelfTexture2D, uv).a) * step(abs(sum - 2.0), eps));

                return float4(_Color.rgb, a);
            }
            ENDCG
        }
    }
}

カスタムレンダーテクスチャの設定

f:id:koturn:20210410195930p:plain
カスタムレンダーテクスチャの設定

Wrap Mode

Repeatにすると,領域外を指定したときに反対側の座標を指定したことになる. これについては後述する.

Filter Mode

初期化画像と同様,Pointを指定する.

Initialization Mode

Initialization ModeはOn Load,SourceはTexture and Colorで,Textureに初期化用のPNG画像を指定する.

Update Mode

Update ModeはRealtimeでDouble Bufferedにチェックを入れる. Double Bufferedにチェックを入っていれば,Dimensionに応じたサンプラー_SelfTexture2D_SelfTexture3D_SelfTexture3D_SelfTextureCubeを利用することで,1つ前のテクスチャの状態を取得することができる.

Periodは更新周期に該当する.グライダーガン系は更新頻度高めで,周期が短めのものは更新頻度低めにするといい感じだと思う.

領域外の扱い

領域外については,下記の2つのどちらかで扱うのが一般的である.

  1. 領域外を死滅セルとして扱う
  2. 領域の端と端をくっつけて,RPGの世界のようなトーラス型の世界として扱う

必要に応じてどちらかを使えるかを選択できるようにした(shader_feature を利用).

f:id:koturn:20210410195945p:plain
カスタムレンダーテクスチャマテリアルの設定

実は2.については,カスタムレンダーテクスチャ自体の設定でWrap Modeを「Repeat」にしていれば,tex2D() で領域外を参照したときに達成できる(後述).

1.については,計算上,多少の工夫が必要となる. tex2D と同様に使える関数として下記のものを用意した.

inline float4 tex2DCutOutside(sampler2D tex, float2 uv) {
    float2 v = step(0.0, uv) * step(uv, 1.0);
    return v.x * v.y * tex2D(tex, uv);
}

step(0.0, uv) * step(uv, 1.0) がポイントで, 0.0 <= uv.x && uv.x <= 1.0 であれば uv.x1.0,そうでなければ 0.0 となる. uv.y に関しても同様である. 従って, uv.x * uv.yuv が領域内のテクスチャ座標なら 1.0,領域外なら 0.0 となるので,これを tex2D() に掛ける.

行列の要素の和

単純に全要素の和を求めてもよかったが,全要素1のベクトルと行列の積を利用して,スマートに求めた. 下記の部分が該当する.

const float sum = mul(mul(ones3, neighbor3x3), ones3);

アセンブリ命令としては,dp3というベクトルの内積を求める命令の組み合わせに変換されるようなので,単純に8回加算するより効率が良い可能性がある(実行時間の計測はしていないので断言できない). 算数的には式(\ref{eq:MatrixSum})の計算を行っているだけである.

\begin{eqnarray} \begin{pmatrix} 1 & 1 & 1 \end{pmatrix} \begin{pmatrix} a & b & c \\ d & e & f \\ g & h & i \end{pmatrix} \begin{pmatrix} 1 \\ 1 \\ 1 \end{pmatrix} & = & \begin{pmatrix} a + d + g & b + e + h & c + f + i \end{pmatrix} \begin{pmatrix} 1 \\ 1 \\ 1 \end{pmatrix} \nonumber \\ & = & (a + d + g) + (b + e + h) + (c + f + i) \nonumber \\ & = & a + b + c + d + e + f + g + h + i \label{eq:MatrixSum} \end{eqnarray}

更新部分

最も単純な実装

ライフゲームのルールの文面,

  • 誕生: 死んでいるセルに隣接する生きたセルがちょうど3つあれば,次の世代が誕生する.
  • 生存: 生きているセルに隣接する生きたセルが2つか3つならば,次の世代でも生存する.
  • 過疎: 生きているセルに隣接する生きたセルが1つ以下ならば,過疎により死滅する.
  • 過密: 生きているセルに隣接する生きたセルが4つ以上ならば,過密により死滅する.

に従った最もナイーブな更新方法は以下の通り.

texel = tex2D(_SelfTexture2D, uv);
if (texel.a < _Color.a) {
    if (abs(sum - 3.0) < eps) {
        texel.a = _Color.a;
    }
} else if (1.5 < sum && sum < 3.5) {
    texel.a = _Color.a;
} else {
    texel.a = 0.0;
}
return texel;

更新ルールを読み替えた実装

しかし,更新ルールの文面をよく読むと,真っ先に現在のセルの生存判定を行なう必要がないことがわかり,下記のように読みかえることができる.

  • 隣接する生きたセルがちょうど3つあれば,次の世代は生存状態
  • 隣接する生きたセルが2つでなければ,次の世代は死滅状態
  • それ以外は前の状態から変化しない
if (abs(sum - 3.0) < eps) {
    return _Color;
} else if (abs(sum - 2.0) > eps) {
    return float4(_Color.rgb, 0.0);
} else {
    // 状態変化無しだが,初期化画像の上書きのため,_Colorの値を用いる
    return float4(_Color.rgb, step(_Color.a, tex2D(_SelfTexture2D, uv).a) * _Color.a);
}

条件分岐を削除した実装

このコードをよく見ると,条件分岐は変数 sum に関するものであり,各条件は直行していることが見てとれる. なので,ある条件を満たすときのみその値になるように書き換えることができる.

論理和論理積の代わりに加算と乗算を用いて,下記のように修正すると等価な計算となる. (GPUでは条件分岐は避けるべきという話なので,なるべく条件分岐は削除したい)

float a = _Color.a * (float(abs(sum - 3.0) < eps)
    + step(_Color.a, tex2D(_SelfTexture2D, uv).a) * float(abs(sum - 2.0) < eps));
return float4(_Color.rgb, a);

実際に生成されるアセンブリコードを確認すると,条件分岐を消去できていることを確認できた.

Shader Disassembly:
//
// Generated by Microsoft (R) D3D Shader Disassembler
//
//
// Input signature:
//
// Name                 Index   Mask Register SysValue  Format   Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_POSITION              0   xyzw        0      POS   float
// TEXCOORD                 0   xyz         1     NONE   float
// TEXCOORD                 1   xyz         2     NONE   float   xy
// TEXCOORD                 2   x           3     NONE    uint
// TEXCOORD                 3   xyz         4     NONE   float
//
//
// Output signature:
//
// Name                 Index   Mask Register SysValue  Format   Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_Target                0   xyzw        0   TARGET   float   xyzw
//
      ps_4_0
      dcl_constantbuffer CB0[53], immediateIndexed
      dcl_sampler s0, mode_default
      dcl_resource_texture2d (float,float,float,float) t0
      dcl_input_ps linear v2.xy
      dcl_output o0.xyzw
      dcl_temps 5
   0: mov r0.y, v2.y
   1: div r1.xyzw, l(1.000000, 1.000000, 1.000000, 1.000000), cb0[51].xyxy
   2: add r2.xyzw, r1.xzyw, v2.xxyy
   3: add r1.xy, -r1.zwzz, v2.xyxx
   4: mov r1.w, r2.x
   5: mov r0.x, r1.w
   6: sample r3.xyzw, r1.wyww, t0.wxyz, s0
   7: sample r0.xyzw, r0.xyxx, t0.xyzw, s0
   8: mov r3.y, r0.w
   9: sample r0.xyzw, r2.ywyy, t0.xyzw, s0
  10: mov r3.z, r0.w
  11: ge r0.xyz, r3.xyzx, cb0[52].wwww
  12: and r0.xyz, r0.xyzx, l(0x3f800000, 0x3f800000, 0x3f800000, 0)
  13: dp3 r0.z, l(1.000000, 1.000000, 1.000000, 0.000000), r0.xyzx
  14: mov r2.x, r1.x
  15: sample r3.xyzw, r2.xzxx, t0.xywz, s0
  16: sample r4.xyzw, r1.xyxx, t0.xyzw, s0
  17: mov r3.x, r4.w
  18: mov r2.yw, v2.yyyx
  19: sample r4.xyzw, r2.xyxx, t0.xyzw, s0
  20: sample r2.xyzw, r2.wzww, t0.xywz, s0
  21: mov r3.y, r4.w
  22: ge r3.xyz, r3.xyzx, cb0[52].wwww
  23: and r3.xyz, r3.xyzx, l(0x3f800000, 0x3f800000, 0x3f800000, 0)
  24: dp3 r0.x, l(1.000000, 1.000000, 1.000000, 0.000000), r3.xyzx
  25: mov r1.z, v2.x
  26: sample r1.xyzw, r1.zyzz, t0.xyzw, s0
  27: mov r2.x, r1.w
  28: mov r2.y, l(0)
  29: ge r1.xyz, r2.xyzx, cb0[52].wwww
  30: and r1.xyz, r1.xyzx, l(0x3f800000, 0x3f800000, 0x3f800000, 0)
  31: dp3 r0.y, l(1.000000, 1.000000, 1.000000, 0.000000), r1.xyzx
  32: dp3 r0.x, r0.xyzx, l(1.000000, 1.000000, 1.000000, 0.000000)
  33: add r0.xy, r0.xxxx, l(-3.000000, -2.000000, 0.000000, 0.000000)
  34: ge r0.xy, l(0.001000, 0.001000, 0.000000, 0.000000), |r0.xyxx|
  35: sample r1.xyzw, v2.xyxx, t0.xyzw, s0
  36: ge r0.z, r1.w, cb0[52].w
  37: and r0.xyz, r0.xyzx, l(0x3f800000, 0x3f800000, 0x3f800000, 0)
  38: mad r0.x, r0.z, r0.y, r0.x
  39: mul o0.w, r0.x, cb0[52].w
  40: mov o0.xyz, cb0[52].xyzx
  41: ret
// Approximately 0 instruction slots used

boolからfloatへのキャスト

シェーダではbool型からfloat型へのキャストが許されている. true であれば 1.0 を,false であれば 0.0 を返すようになっているようだ.

シェーダアセンブリでは,比較命令およびその結果と 0x3f800000 の and を取っている部分が該当する. 比較命令は結果が真であれば 0xffffffff を格納し,偽であれば 0x00000000 を格納するらしい. それと 0x3f800000 との and を取れば1.0か0.0になるカラクリのようだ(IEEE 754では).

step()abs() に関しても比較演算結果によって戻り値が異なるだけなので,0x3f800000 と and を取っている部分に化けていると思われる.

特に step() は式(\ref{eq:StepFunction})の計算を行うだけなので,比較結果を bool にキャストすることに他ならない.

\begin{equation} step(a, x) = \begin{cases} 0 & (x < a) \\ 1 & (x \geq a) \end{cases} \label{eq:StepFunction} \end{equation}

浮動小数点数の等値比較

IEEE 754では,例えば1.0を8回加算したとしても8.0になるだけだが,GPUIEEE 754を採用しているとも限らないので,2数の絶対値の差が小さい正の数 eps より小さければ等しいとして,安全な方に倒している.

色相変化

単なるライフゲームではつまらないので,時間とともに色相を変化させようと考えた.

カスタムレンダーテクスチャは別のカスタムレンダーテクスチャへの入力に利用することが可能である. そのため,色相の変化を1つのカスタムレンダーテクスチャで行うのではなく,別のカスタムレンダーテクスチャで行うことにした. こうすることで,ライフゲーム自体の更新頻度に関わらず,色相変化を行うことが可能になる.

シェーダーの全容

色相変化用のカスタムレンダーテクスチャのシェーダは下記の通り.

Shader "koturn/HueRotation"
{
    Properties
    {
        // shader_feature: _HUEONLY_ON
        [Toggle]
        _HueOnly ("Treats Hue only, ignore offset of Saturation and Value", Float) = 0

        _MainTex ("Source Texture", 2D) = "white" {}
        _TimeScale ("Time multiplier for HSV rotation", Float) = 0.1
        _HueOffset ("Offset of Hue (H)", Range(0.0, 1.0)) = 0.0
        _SaturationOffset ("Offset of Saturation (S)", Range(-1.0, 1.0)) = 0.0
        _ValueOffset ("Offset of Value (V)", Range(-1.0, 1.0)) = 0.0
    }
    SubShader
    {
        ZWrite Off
        ZTest Always
        Lighting Off

        CGINCLUDE
        #pragma target 3.0

        #include "UnityCustomRenderTexture.cginc"

        #pragma vertex CustomRenderTextureVertexShader

        UNITY_DECLARE_TEX2D(_MainTex);
        ENDCG

        Pass
        {
            Name "Nothing"

            CGPROGRAM
            #pragma fragment frag
            /*!
             * @brief フラグメントシェーダ
             *
             * 指定されたUV座標のテクセルの値をそのまま返す
             *
             * @param [in] i  カスタムレンダーテクスチャの入力値
             * @return 1つのテクセルに対するRGBA値
             */
            float4 frag(v2f_customrendertexture i) : COLOR
            {
                return UNITY_SAMPLE_TEX2D(_MainTex, i.globalTexcoord);
            }
            ENDCG
        }

        Pass
        {
            Name "Update"

            CGPROGRAM
            #pragma fragment frag
            #pragma shader_feature _ _HUEONLY_ON

            inline float3 rgb2hsv(float3 rgb);
            inline float3 hsv2rgb(float3 hsv);

            uniform float _TimeScale;
            uniform float _HueOffset;
#ifndef _HUEONLY_ON
            uniform float _SaturationOffset;
            uniform float _ValueOffset;
#endif  // !_HUEONLY_ON
            /*!
             * @brief フラグメントシェーダ
             *
             * @param [in] i  カスタムレンダーテクスチャの入力値
             * @return 1つのテクセルに対するRGBA値
             */
            float4 frag(v2f_customrendertexture i) : COLOR
            {
                const float4 texel = UNITY_SAMPLE_TEX2D(_MainTex, i.globalTexcoord);
                float3 hsv = rgb2hsv(texel.rgb);
#ifdef _HUEONLY_ON
                hsv.x += _Time.y * _TimeScale + _HueOffset;
#else
                hsv = float3(
                    hsv.x + _Time.y * _TimeScale + _HueOffset,
                    saturate(hsv.y + _SaturationOffset),
                    saturate(hsv.z + _ValueOffset));
#endif  // _HUEONLY_ON
                return float4(hsv2rgb(hsv), texel.a);
            }

            /*!
             * @brief RGB色空間からHSV色空間へ写像を行なう
             *
             * 入力のRGBの各要素は閉区間: [0.0, 1.0] の範囲になければならない
             *
             * @param [in] rgb  RGB値
             * @return HSV値
             */
            inline float3 rgb2hsv(float3 rgb)
            {
                static const float4 k = float4(0.0, -1.0 / 3.0, 2.0 / 3.0, -1.0);
                static const float e = 1.0e-10;

                const float4 p = rgb.g < rgb.b ? float4(rgb.bg, k.wz) : float4(rgb.gb, k.xy);
                const float4 q = rgb.r < p.x ? float4(p.xyw, rgb.r) : float4(rgb.r, p.yzx);
                const float d = q.x - min(q.w, q.y);
                return float3(abs(q.z + (q.w - q.y) / (6.0 * d + e)), d / (q.x + e), q.x);
            }

            /*!
             * @brief HSV色空間からRGB色空間へ写像を行なう
             *
             * 入力のHSVのSV要素は閉区間: [0.0, 1.0] の範囲になければならない
             *
             * @param [in] hsv  HSV値
             * @return RGB値
             */
            inline float3 hsv2rgb(float3 hsv)
            {
                static const float4 k = float4(1.0, 2.0 / 3.0, 1.0 / 3.0, 3.0);

                const float3 p = abs(frac(hsv.xxx + k.xyz) * 6.0 - k.www);
                return hsv.z * lerp(k.xxx, saturate(p - k.xxx), hsv.y);
            }
            ENDCG
        }
    }
}

RGBからHSVへの変換,その逆に関しては先人に知恵を借りた. RGBからHSVに変換するよく知られた実装では条件分岐が含まれるので,先人のシェーダ用の賢い実装は参考になる.

inline float3 rgb2hsv(float3 rgb)
{
    static const float4 k = float4(0.0, -1.0 / 3.0, 2.0 / 3.0, -1.0);
    static const float e = 1.0e-10;

    const float4 p = rgb.g < rgb.b ? float4(rgb.bg, k.wz) : float4(rgb.gb, k.xy);
    const float4 q = rgb.r < p.x ? float4(p.xyw, rgb.r) : float4(rgb.r, p.yzx);
    const float d = q.x - min(q.w, q.y);
    return float3(abs(q.z + (q.w - q.y) / (6.0 * d + e)), d / (q.x + e), q.x);
}

inline float3 hsv2rgb(float3 hsv)
{
    static const float4 k = float4(1.0, 2.0 / 3.0, 1.0 / 3.0, 3.0);

    const float3 p = abs(frac(hsv.xxx + k.xyz) * 6.0 - k.www);
    return hsv.z * lerp(k.xxx, saturate(p - k.xxx), hsv.y);
}

色相変化の速度

Unityのシェーダでは経過時間(秒)をfloat値として取得できる. 特にこだわりはないので,素直に扱える経過時間に係数がかかっていないもの(_Time.y)を利用する.

インスペクタから色相の変化速度を設定できるようにしたいので,_Time.y に対する係数のプロパティ _TimeScale を用意する. ついでに初期色相位相も指定できるとベンリだと思ったので,_HueOffset というプロパティも用意する.

hsv.x += _Time.y * _TimeScale + _HueOffset;

このままだと色相値が [0.0, 1.0] に収まっていないが,hsv2rgb() の中で frac() 関数を通しているので問題はない. frac関数とは,小数部を返す関数であり,わかりやすく表現すると式(\ref{eq:FracFunction})となる.

\begin{equation} frac(x) = x - \lfloor x \rfloor \label{eq:FracFunction} \end{equation}

例えば frac(0.3) == 0.3frac(1.1) == 0.1frac(123.4) == 0.4 となる. 0.0 ~ 1.0で循環する動きをするため,色相値に対して利用するのにもってこいの関数である.

なお,もののついでとして,SVのオフセットも指定できるようにした. ただし,ほとんどの場合利用することはないと考え,shader_feature で利用しないコード生成もできるようにした.

カスタムレンダーテクスチャの貼り付け

たかがライフゲームなので,適当にQuadを用意して貼り付けるようにした. ただし,両面から見えるようにカリングはオフにした方が良いと思う.

Standard Shaderではカリングの設定はできないので,

  1. Standard Shaderのコードを入手し,Cull Off を加えたものを利用する
  2. MToonなどのカリングの指定ができるシェーダを利用する
  3. 適当なシェーダを書く

のいずれかで対応するとよい.

適当なシェーダとは,例えば下記のような超ミニマルなサーフェースシェーダ等でもよいと思う.

Shader "koturn/SimpleSurface"
{
    Properties
    {
        _MainTex ("Albedo (RGB)", 2D) = "white" {}
        _Glossiness ("Smoothness", Range(0, 1)) = 0.5
        _Metallic ("Metallic", Range(0, 1)) = 0.0
    }
    SubShader
    {
        Tags
        {
            "RenderType" = "Transparent"
            "Queue" = "AlphaTest"
        }
        LOD 200
        Blend SrcAlpha OneMinusSrcAlpha
        ZWrite Off

        CGPROGRAM

        #pragma surface surf Standard fullforwardshadows alphatest:fade

        #pragma target 3.0

        UNITY_DECLARE_TEX2D(_MainTex);

        struct Input
        {
            float2 uv_MainTex;
        };

        uniform half _Glossiness;
        uniform half _Metallic;

        void surf(Input IN, inout SurfaceOutputStandard o)
        {
            fixed4 c = UNITY_SAMPLE_TEX2D(_MainTex, IN.uv_MainTex);
            o.Albedo = c.rgb;
            o.Metallic = _Metallic;
            o.Smoothness = _Glossiness;
            o.Alpha = c.a;
        }
        ENDCG
    }
    FallBack "Diffuse"
}

問題点

原因はよくわからないが,VRChatだとカスタムレンダーテクスチャの更新が止まることがある. 特に複数人いる場合,ワールドが重い場合にその傾向があるように思う.

自分視点だと停止することが多いが,他の人視点だと動作していることが多いので,あまり気にしないことにしている.

また,色相変化に _Time を用いているが,float 値であるため,十分に長い時間が経過すると,色相変化が機能しなくなるのではないかと思う. だが,通常の運用において,長時間VRChatにログインすることはないため,無視することにしている.

なお,このブログ中のアセンブリコードはあくまでDirect3D用のアセンブリコードなので,他のプラットフォームでは別のコード生成がされるであろうことは注意したい.

まとめ

  • カスタムレンダーテクスチャは前の状態を取得できるので,ライフゲームの実装にもってこいである
  • 工夫次第でライフゲームの更新部分の条件分岐を無くすことができる
  • 1つのカスタムレンダーテクスチャに処理を詰め込むと実装が苦しくなるので,いくつかのカスタムレンダーテクスチャにすると楽
  • カスタムレンダーテクスチャを利用すれば,アニメーションを用いなくても,ゲーミング的なアレを実現できる.
  • VRChatのアバターに付けたカスタムレンダーテクスチャは機能したりしなかったりするので,重要な部分に用いず,アクセサリ程度にとどめるのがよい

previm + MathJax 3.X

TL;DR

previmでMathJax3.Xを使用できるようにする.

背景

previm/previmMarkdownのプレビューを可能にするプラグインでとてもベンリである. これにMathJaxを組み合わせると,数式が書けるようになり,ものすごくベンリになる.

このMathJaxであるが,2019/9にVer3.0がリリースされていたらしい. 今までVer2.X系を使用していたが,なるべく新しいものを使いたいものである. 実際,MathJax3はMathJax2と比べて処理が高速になったらしい.

しかし,メジャーバージョンアップデートだけあって,2.X系の記述とは異なるものにする必要がある.

現行のWebにあるPrevim + MathJaxの情報はMathJax Ver2.X系のものばかりであるため,Ver3.Xを使用する方法を書くのは意義があると考えた.

変更点

変更点は下記の通りである(git diff の出力結果).

diff --git preview/_/index.html preview/_/index.html
index b08364d..81f142c 100644
--- preview/_/index.html
+++ preview/_/index.html
@@ -38,6 +38,18 @@
             <script src="../_/js/lib/zip_deflate.js"></script>
             <script src="../_/js/lib/plantuml.js"></script>
             <script src="../_/js/previm.js"></script>
+            <script>
+            MathJax = {
+              tex: {
+                inlineMath: [['$', '$'], ['\\(', '\\)']],
+                tags: 'ams'
+              },
+              chtml: {
+                matchFontHeight: false
+              }
+            };
+            </script>
+            <script id="MathJax-script" async src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-chtml.js"></script>
             <div id="monitor"></div>
         </div>
     </body>
diff --git preview/_/js/previm.js preview/_/js/previm.js
index 84f1ae7..4149808 100644
--- preview/_/js/previm.js
+++ preview/_/js/previm.js
@@ -98,6 +98,12 @@
       Array.prototype.forEach.call(_doc.querySelectorAll('pre code'), hljs.highlightBlock);
       autoScroll('body', beforePageYOffset);
       style_header();
+
+      if (typeof MathJax.texReset === 'function') {
+        MathJax.texReset();
+        MathJax.typesetPromise();
+        autoScroll('body');
+      }
     }
   }

tags: 'ams' は数式に番号を付けたくない場合は不要である. tex-chtml.js の読み込みが終わるまで,MathJax.texReset 等のメソッドが生えてこないので,previm.js の関数内では typeof を使用して,メソッドが存在しなければ呼び出しをしないようにしている.

CDNの利用が嫌なら(オフライン環境でもMathJaxを利用したい場合など),ローカルにMathJax一式を落としてきて指定するとよい.

おまけ

このブログは以前までMathJax2を利用していたが,ついでなのでMathJax3を利用するようにした.

参考

C言語でダブルクオートで囲まれたカラムを含むCSVファイルのパースを行う

TL;DR

タイトル通り,C言語でダブルクオートで囲まれたカラムを含むCSVファイル(RFC 4180 2.6章,2.7章参照)のパースを実装した.

背景

2021年にもなってC言語を書かなければならないことがあり,その中でCSVファイルのパースを行う必要があった.

既存の実装を利用しようと,「C言語 CSV」でググってみたのだが,fgets()sscanf() を利用した貧弱なCSVのパースのみであり,実用に耐えないものばかりであった(「1行読み取って」の時点で改行を含むカラムを扱うことができないため,CSVのパースとしては失格である).

そのため,RFC 4180 2.6章,2.7章に従ったCSVを取り扱えるパースを実装した.

本題

とにかく実装は下記の通り. とりあえず動作が確認できるものとして,コマンドライン引数で指定されたCSVファイルをタブ区切りで出力するプログラムとしているが,キモは get_next_csv_token() である. この関数でCSVの1カラムが取得できるので,EOFに到達するまで繰り返し呼び出す.

実装1

#include <assert.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
#include <string.h>


#if defined(NDEBUG)
#  ifdef _MSC_VER
#    define ASSUME(x)  __assume(x)
#  else
#    define ASSUME(x)
#  endif  // _MSC_VER
#elif defined(assert)
#  define ASSUME(x)  assert(x)
#else
#  define ASSUME(x)
#endif  // defined(NDEBUG)


//! CSVのカラム取得結果の列挙体
typedef enum
{
  //! 通常のカラム
  CSVTOKENTYPE_COLUMN = 0,
  //! 行末のカラム
  CSVTOKENTYPE_EOL_COLUMN = 1,
  //! 既にEOFに到達しており,読み取りを行ったときに返却される値
  CSVTOKENTYPE_NO_COLUMN = 3,
  //! バッファサイズに格納できないときに返却される値
  CSVTOKENTYPE_BUFSIZE_ERROR = -1
} csv_token_type_t;


//! カラムデータの読み取り中断時の状態を格納する構造体
typedef struct
{
  //! バッファサイズ溢れで格納出来なかった文字
  int prev_char;
  //! ダブルクオートで囲まれているかどうか
  bool is_quoted;
  //! 読み取り文字数
  size_t n_read;
} csv_parse_state_t;


static void show_usage(FILE *fp, const char *progname);
static int show_csv_parse_result(const char *filepath);
static csv_token_type_t get_next_csv_token(FILE* fp, char *dst_buf, size_t dst_buf_size, char delim, csv_parse_state_t *state);


/*!
 * @brief このプログラムのエントリポイント
 *
 * @param [in] argc コマンドライン引数の数
 * @param [in] argv コマンドライン引数の配列
 * @return 終了ステータス
 */
int
main(int argc, const char *argv[])
{
  if (argc < 2) {
    show_usage(stderr, argv[0]);
    return 64;  // EX_USAGE
  }

  for (int i = 1; i < argc; i++) {
    printf("==================== CSV File No.%d ====================\n", i);
    show_csv_parse_result(argv[i]);
  }

  return EXIT_SUCCESS;
}


/*!
 * @brief このプログラムの使用方法を表示する
 *
 * @param [in,out] fp 出力先ファイルストリーム
 * @param [in] progname プログラム名
 */
static void
show_usage(FILE *fp, const char *progname)
{
  fprintf(fp, "[Usage]\n");
  fprintf(fp, "  %s [CSV file]...\n", progname);
}


/*!
 * @brief CSVファイルのパース結果を表示する
 *
 * 行番号を付け,1カラムごとにタブ区切りでカラム内容を出力する
 *
 * @param [in] filepath 対象となるCSVファイル
 * @return 正常終了時は0,それ以外は非0
 */
static int
show_csv_parse_result(const char *filepath)
{
  FILE *fp = fopen(filepath, "r");
  if (fp == NULL) {
    perror("fopen");
    return errno;
  }

  size_t colbuf_size = 8192;
  char *colbuf = (char *)malloc(colbuf_size);
  if (colbuf == NULL) {
    fclose(fp);
    perror("malloc");
    return errno;
  }
  char *colbuf2;

  csv_token_type_t ctt;
  csv_parse_state_t state = {0};

  int linenr = 1;
  printf("Line %d: ", linenr);

  while ((ctt = get_next_csv_token(fp, &colbuf[state.n_read], colbuf_size, ',', &state)) != CSVTOKENTYPE_NO_COLUMN) {
    switch (ctt) {
      case CSVTOKENTYPE_COLUMN:
        printf("%s\t", colbuf);
        break;
      case CSVTOKENTYPE_EOL_COLUMN:
        printf("%s\nLine %d: ", colbuf, ++linenr);
        break;
      case CSVTOKENTYPE_NO_COLUMN:
        // 絶対にここは通らないがコンパイラの警告抑制のため
        ASSUME(0);
        break;
      case CSVTOKENTYPE_BUFSIZE_ERROR:
        colbuf_size *= 2;
        // オーバーフローのチェックはしない
        colbuf2 = (char *)realloc(colbuf, colbuf_size);
        if (colbuf2 == NULL) {
          free(colbuf);
          fclose(fp);
          perror("realloc");
          return errno;
        }
        colbuf = colbuf2;
        break;
      default:
        // 絶対にここは通らないがコンパイラの警告抑制のため
        ASSUME(0);
        break;
    }
  }
  putchar('\n');

  free(colbuf);
  fclose(fp);

  return 0;
}


/*!
 * @brief CSVファイルの次のカラムを得る
 *
 * @param [in,out] fp ファイルストリーム
 * @param [in,out] dst_buf カラムデータ格納先バッファ
 * @param [in]     dst_buf_size カラムデータ格納先バッファのサイズ
 * @param [in]     delim 区切り文字
 * @param [in]     state 読み取り状態
 * @retval CSVTOKENTYPE_COLUMN 通常のカラムの読み取り時
 * @retval CSVTOKENTYPE_EOL_COLUMN 行末のカラムの読み取り時
 * @retval CSVTOKENTYPE_NO_COLUMN fpが既にEOFに到達しているとき
 * @retval CSVTOKENTYPE_BUFSIZE_ERROR バッファに格納できないとき
 */
static csv_token_type_t
get_next_csv_token(FILE* fp, char *dst_buf, size_t dst_buf_size, char delim, csv_parse_state_t *state)
{
  int c = EOF;
  size_t pos = 0;
  csv_token_type_t ctt = CSVTOKENTYPE_EOL_COLUMN;

  // 初回なら読み取り
  if (state->prev_char == '\0') {
    c = fgetc(fp);
    if (c == EOF) {
      return CSVTOKENTYPE_NO_COLUMN;
    }
    if (c == '"') {
      state->is_quoted = true;
    }
  } else {
    // 前回バッファイサイズ溢れで格納できなかった文字を格納
    dst_buf[pos++] = (char)state->prev_char;
  }

  if (state->is_quoted) {
    // ダブルクオート部の読み取り
    while ((c = fgetc(fp)) != EOF) {
      if (c == '"' && (c = fgetc(fp)) != '"') {
        // ダブルクオート囲い終わりの場合
        state->is_quoted = false;
        break;
      }
      // ダブルクオート以外
      // または,ダブルクオートが連続する場合(ダブルクオートのエスケープ)
      if (pos + 1 >= dst_buf_size) {
        goto buffer_size_error;
      }
      dst_buf[pos++] = (char)c;
    }
  }

  // ダブルクオート外の読み取り
  for (c = (c == EOF ? fgetc(fp) : c); c != EOF; c = fgetc(fp)) {
    if (c == '\n') {
      ctt = CSVTOKENTYPE_EOL_COLUMN;
      break;
    } else if (c == delim) {
      ctt = CSVTOKENTYPE_COLUMN;
      break;
    } else {
      if (pos + 1 >= dst_buf_size) {
        goto buffer_size_error;
      }
      dst_buf[pos++] = (char)c;
    }
  }

  dst_buf[pos] = '\0';

  state->prev_char = '\0';
  state->is_quoted = false;
  state->n_read = 0;

  return ctt;

buffer_size_error:
  dst_buf[pos] = '\0';
  state->prev_char = c;
  state->n_read += pos;
  return CSVTOKENTYPE_BUFSIZE_ERROR;
}

get_next_csv_token() はバッファサイズの確認も行っており,バッファ溢れが起こる場合,出力先バッファに格納する文字を state に退避して,エラーを返す作りとしている. 呼び出し元で,返り値の確認をし,バッファ溢れがあった場合は格納先バッファを realloc() で2倍の容量で再確保するようにしている.

実装2(簡易実装)

バッファ溢れ時の処理を大雑把にし,もうちょっとシンプルな実装にするなら以下のようにしてもよいと思う. ただし,この実装はバッファ溢れの度にシーク位置を戻して,バッファを拡張後,再度読み直すようにしているので,バッファ溢れが頻繁に起こるならば非効率である. (show_csv_parse_result()get_next_csv_token() 以外は前のものと同じなので省略)

/*!
 * @brief CSVファイルのパース結果を表示する
 *
 * 行番号を付け,1カラムごとにタブ区切りでカラム内容を出力する
 *
 * @param [in] filepath 対象となるCSVファイル
 * @return 正常終了時は0,それ以外は非0
 */
static int
show_csv_parse_result(const char *filepath)
{
  FILE *fp = fopen(filepath, "r");
  if (fp == NULL) {
    perror("fopen");
    return errno;
  }

  size_t colbuf_size = 2;
  char *colbuf = (char *)malloc(colbuf_size);
  if (colbuf == NULL) {
    fclose(fp);
    perror("malloc");
    return errno;
  }
  char *colbuf2;

  csv_token_type_t ctt;

  int linenr = 1;
  printf("Line %d: ", linenr);

  while ((ctt = get_next_csv_token(fp, colbuf, colbuf_size, ',', CSVPARSEERRACT_REWIND_TO_HEAD)) != CSVTOKENTYPE_NO_COLUMN) {
    switch (ctt) {
      case CSVTOKENTYPE_COLUMN:
        printf("%s\t", colbuf);
        break;
      case CSVTOKENTYPE_EOL_COLUMN:
        printf("%s\nLine %d: ", colbuf, ++linenr);
        break;
      case CSVTOKENTYPE_NO_COLUMN:
        // 絶対にここは通らないがコンパイラの警告抑制のため
        ASSUME(0);
        break;
      case CSVTOKENTYPE_BUFSIZE_ERROR:
        colbuf_size *= 2;
        // オーバーフローのチェックはしない
        colbuf2 = (char *)realloc(colbuf, colbuf_size);
        if (colbuf2 == NULL) {
          free(colbuf);
          fclose(fp);
          perror("realloc");
          return errno;
        }
        colbuf = colbuf2;
        break;
      default:
        // 絶対にここは通らないがコンパイラの警告抑制のため
        ASSUME(0);
        break;
    }
  }
  putchar('\n');

  free(colbuf);
  fclose(fp);

  return 0;
}


/*!
 * @brief CSVファイルの次のカラムを得る
 *
 * @param [in,out] fp ファイルストリーム
 * @param [in,out] dst_buf カラムデータ格納先バッファ
 * @param [in]     dst_buf_size カラムデータ格納先バッファのサイズ
 * @param [in]     delim 区切り文字
 * @param [in]     erract バッファ溢れエラー時の動作
 * @retval CSVTOKENTYPE_COLUMN 通常のカラムの読み取り時
 * @retval CSVTOKENTYPE_EOL_COLUMN 行末のカラムの読み取り時
 * @retval CSVTOKENTYPE_NO_COLUMN fpが既にEOFに到達しているとき
 * @retval CSVTOKENTYPE_BUFSIZE_ERROR バッファに格納できないとき
 */
static csv_token_type_t
get_next_csv_token(FILE* fp, char *dst_buf, size_t dst_buf_size, char delim, csv_parse_erract_t erract)
{
  int c;
  size_t pos = 0;
  csv_token_type_t ctt = CSVTOKENTYPE_EOL_COLUMN;
  long spos = erract == CSVPARSEERRACT_REWIND_TO_HEAD ? ftell(fp) : 0;

  c = fgetc(fp);
  if (c == EOF) {
    return CSVTOKENTYPE_NO_COLUMN;
  }
  if (c == '"') {
    // ダブルクオート部の読み取り
    while ((c = fgetc(fp)) != EOF) {
      if (c == '"' && (c = fgetc(fp)) != '"') {
        // ダブルクオート囲い終わりの場合
        break;
      }
      // ダブルクオート以外
      // または、ダブルクオートが連続する場合(ダブルクオートのエスケープ)
      if (pos + 1 >= dst_buf_size) {
        goto buffer_size_error;
      }
      dst_buf[pos++] = (char)c;
    }
  }

  // ダブルクオート外の読み取り
  for (; c != EOF; c = fgetc(fp)) {
    if (c == '\n') {
      break;
    } else if (c == delim) {
      ctt = CSVTOKENTYPE_COLUMN;
      break;
    } else {
      if (pos + 1 >= dst_buf_size) {
        goto buffer_size_error;
      }
      dst_buf[pos++] = (char)c;
    }
  }

  dst_buf[pos] = '\0';
  return ctt;

buffer_size_error:
  if (erract == CSVPARSEERRACT_REWIND_TO_HEAD) {
    fseek(fp, spos, SEEK_SET);
  } else {
    ungetc(c, fp);
  }
  dst_buf[pos] = '\0';
  return CSVTOKENTYPE_BUFSIZE_ERROR;
}

まとめ

C言語RFC 4180の2.6章,2.7章に従ったCSVのパースを実装した. 実運用上ではバッファサイズの制限や,カンマ,改行を含むカラムがあるCSVファイルを扱うことが可能なように最初から考えておいた方がよいと思う.

(本当はちゃんと動作するライブラリを使用するのがよいと思う)

なお,RFC 4180 2.1章ではCSVの改行はCR+LFとなっているが,この記事では従っていない.

参考