koturnの日記

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

シェーダーにおける浮動小数点剰余(mod, fmod)の実装

TL;DR

シェーダー言語によってその言語組み込みの fmod()mod()) の実装は異なるため注意する必要がある. 挙動の罠に引っかからないためには自前で実装するのが安全である.

GLSL

// Equivalent to mod() in GLSL.
float fmodglsl(float x, float y)
{
    return x - y * floor(x / y);
}

HLSL

// Equivalent to fmod() in HLSL.
float fmodhlsl(float x, float y)
{
    return x - y * trunc(x / y);
}

CG, Unityのshaderlab(CGPROGRAM, HLSLPROGRAM かに依存しない)

// Equivalent to fmod() in CG.
float fmodcg(float x, float y)
{
    const float c = frac(abs(x / y)) * abs(y);
    return x < 0 ? -c : c;
}

fmodについて

fmod() とは浮動小数点の剰余の計算を行う関数である. シェーダー特有のものではなく,C言語<math.h> にも存在しているような普遍的な計算である.

Unityのshaderlabでの確認方法

僕個人としてはshaderlabをいじることがほとんどである. そのため,shaderlabでの組み込み関数 fmod() の実装がどうなっているかを調べることにした.

実装を見るためには,組み込み関数の fmod() と自前で用意した剰余関数から生成される命令(Direct X11用)を比較するのが手っ取り早い. とりあえず,以下のコードで確認することにした.

FmodImpl.shader

Shader "koturn/FmodImpl"
{
    Properties
    {
        _MainTex ("Main texture", 2D) = "white" {}
        _Color ("Multiplicative color for _MainTex", Color) = (1.0, 1.0, 1.0, 1.0)

        _Value01 ("Value01", Float) = 23.0
        _Value02 ("Value02", Float) = 3.7

        [KeywordEnum(Operator, Native Func, CG, HLSL, GLSL)]
        _ModType ("Mod operation type", Float) = 2  // Default: Back

        [Enum(UnityEngine.Rendering.CullMode)]
        _Cull ("Cull", Float) = 2  // Default: Back

        [Enum(UnityEngine.Rendering.CompareFunction)]
        _ZTest ("ZTest", Float) = 4  // Default: LEqual

        [Enum(Off, 0, On, 1)]
        _ZWrite ("ZWrite", Float) = 0  // Default: Off

        [Enum(UnityEngine.Rendering.BlendMode)]
        _SrcFactor ("Src Factor", Float) = 5  // Default: SrcAlpha

        [Enum(UnityEngine.Rendering.BlendMode)]
        _DstFactor ("Dst Factor", Float) = 10  // Default: OneMinusSrcAlpha
    }

    SubShader
    {
        Tags
        {
            "RenderType" = "Transparent"
            "Queue" = "Transparent"
        }

        Cull [_Cull]
        ZWrite [_ZWrite]
        ZTest [_ZTest]
        Blend [_SrcFactor] [_DstFactor]

        Pass
        {
            CGPROGRAM
            #pragma target 3.0

            #pragma vertex vert
            #pragma fragment frag

            #pragma multi_compile_local_fragment _MODTYPE_OPERATOR _MODTYPE_NATIVE_FUNC _MODTYPE_CG _MODTYPE_HLSL _MODTYPE_GLSL

            #include "UnityCG.cginc"

            UNITY_DECLARE_TEX2D(_MainTex);
            uniform float4 _Color;
            uniform float _Value01;
            uniform float _Value02;


            float fmodcg(float x, float y)
            {
                const float c = frac(abs(x / y)) * abs(y);
                return x < 0 ? -c : c;
            }

            float fmodglsl(float x, float y)
            {
                return x - y * floor(x / y);
            }

            float fmodhlsl(float x, float y)
            {
                return x - y * trunc(x / y);
            }


            struct appdata
            {
                float4 vertex : POSITION;
                float2 uv : TEXCOORD0;
            };

            struct v2f
            {
                float4 vertex : SV_POSITION;
                float2 uv : TEXCOORD0;
            };


            v2f vert(appdata v)
            {
                v2f o;
                o.vertex = UnityObjectToClipPos(v.vertex);
                o.uv = v.uv;
                return o;
            }

            fixed4 frag(v2f i) : SV_Target
            {
                float4 col = UNITY_SAMPLE_TEX2D(_MainTex, i.uv) * _Color;
#if defined(_MODTYPE_NATIVE_FUNC)
                col.a = fmod(_Value01, _Value02);
#elif defined(_MODTYPE_OPERATOR)
                col.a = _Value01 % _Value02;
#elif defined(_MODTYPE_CG)
                col.a = fmodcg(_Value01, _Value02);
#elif defined(_MODTYPE_HLSL)
                col.a = fmodhlsl(_Value01, _Value02);
#elif defined(_MODTYPE_GLSL)
                col.a = fmodglsl(_Value01, _Value02);
#endif
                return col;
            }
            ENDCG
        }
    }
}

生成コード

部分的に抜粋する.

組み込み関数のfmod

今回の検証対象である. 生成された命令からNVidiaのCgの言語仕様に書かれているのと同様の実装になっていることがわかる.

   0: div r0.x, cb0[3].x, cb0[3].y
   1: ge r0.y, r0.x, -r0.x
   2: frc r0.x, |r0.x|
   3: movc r0.x, r0.y, r0.x, -r0.x
   4: mul o0.w, r0.x, cb0[3].y

また,CGPROGRAMHLSLPROGRAM かに依らず同じコードが生成された. 挙動をCgの実装に統一しているのだろう.

演算子

演算子 % を用いた場合でもコンパイルは通るのだが,組み込み関数の fmod() を用いた場合とは異なるコードが生成されていた.

   0: mul r0.x, cb0[3].y, cb0[3].x
   1: ge r0.x, r0.x, -r0.x
   2: movc r0.x, r0.x, cb0[3].y, -cb0[3].y
   3: div r0.y, l(1.000000, 1.000000, 1.000000, 1.000000), r0.x
   4: mul r0.y, r0.y, cb0[3].x
   5: frc r0.y, r0.y
   6: mul o0.w, r0.y, r0.x

これをシェーダーコードに翻訳すると下記のようになる.

float fmodop(float x, float y)
{
    const float xy = x * y;
    const float a = (xy >= -xy) ? y : -y;
    const float b = frac((1.0 / a) * x);
    return a * b;
}

計算結果は浮動小数点計算における誤差を無視すれば,組み込み関数の fmod() と一致する. 生成されているコード量としてあまり効率的でないように思われるが実際はどうなのだろうか?

例えば,

   3: div r0.y, l(1.000000, 1.000000, 1.000000, 1.000000), r0.x
   4: mul r0.y, r0.y, cb0[3].x

   div r0.y, cb0[3].x, r0.x

でいいのでは?などと思ったりする.

fmodglsl

float fmodglsl(float x, float y)
{
    return x - y * floor(x / y);
}
   0: div r0.x, cb0[3].x, cb0[3].y
   1: round_ni r0.x, r0.x
   2: mad o0.w, -cb0[3].y, r0.x, cb0[3].x

floor()round_ni 命令に対応しており,命令名はおそらくRound to Negative Infinityのことで,負の無限大への丸めを意味するのだろう. y が正のときは正の値を,y が負のときは負の値を返すようになっている. x / y が負数のときの挙動が fmodhlsl() と異なり,正負に関係なく周期的な挙動をするため,素直に扱いやすいと思う.

fmodhlsl

float fmodhlsl(float x, float y)
{
    return x - y * trunc(x / y);
}
   0: div r0.x, cb0[3].x, cb0[3].y
   1: round_z r0.x, r0.x
   2: mad o0.w, -cb0[3].y, r0.x, cb0[3].x

trunc()round_z 命令に対応しており,命令名はおそらくRound to Zeroのことで,0への丸めを意味するのだろう. x / y が負数のときの挙動が fmodglsl() と異なり,正負で周期的な挙動が切り替わる形である.

y の符号が反転したとしても同じ値を返す.

fmodcg

float fmodcg(float x, float y)
{
    const float c = frac(abs(x / y)) * abs(y);
    return x < 0 ? -c : c;
}

生成される命令としては組み込み関数の fmod() と一致している. 前述の2つよりも命令数が少し多い.

   0: div r0.x, cb0[3].x, cb0[3].y
   1: frc r0.x, |r0.x|
   2: mul r0.x, r0.x, |cb0[3].y|
   3: lt r0.y, cb0[3].x, l(0.000000)
   4: movc o0.w, r0.y, -r0.x, r0.x

誤差を考慮しなければ算出される値は fmodhlsl() と同じである.

ただし,前述の2つと比較すると,正または負に誤差が発生するので,この関数の返却値に対して積・商を行った結果をそのまま floor()ceil() に通すと想定外の値となることがある. (fmodglslfmodhlsl を用いた場合と異なる結果になる)

あまりこの実装を用いるメリットはないように思われるが....

参考文献

PostgreSQLで外部テーブルに無理矢理UPSERTする

背景

PostgreSQLには外部のPostgreSQLサーバに格納されたデータをアクセスするためのpostgres_fdwモジュールがある. これにより,外部のテーブルを自身のサーバにあるかのように扱うことが可能となるが様々な落とし穴がある.

そのひとつは,UPSERT(INSERTON CONFLICT DO UPDATE)が使用できないことである. ドキュメントにも下記の記載がある.

Note that postgres_fdw currently lacks support for INSERT statements with an ON CONFLICT DO UPDATE clause. However, the ON CONFLICT DO NOTHING clause is supported, provided a unique index inference specification is omitted.

しかし,何とかして外部テーブルにUPSERTをしなければならない場面があったので,この記事では代替手法について述べる.

準備

本記事では,下記のテーブルを例にとりUPSERT対象として扱う.

CREATE TABLE t_upsert_test (
  pkey1 VARCHAR(32) NOT NULL
  , pkey2 INTEGER NOT NULL
  , val1 VARCHAR(32) NOT NULL
  , val2 VARCHAR(32) NOT NULL
  , val3 INTEGER
  , val4 INTEGER
  , PRIMARY KEY (pkey1, pkey2)
);

他テーブルからのSELECT結果をUPSERT

通常のUPSERT

PostgreSQLの通常のUPSERT(ON CONFLICT DO NOTHING)は下記の形となる. t_upsert_test_tmp から t_upsert_test_tmp にUPSERTを行う例を示している.

INSERT INTO t_upsert_test (
  pkey1
  , pkey2
  , val1
  , val2
  , val3
  , val4
)
SELECT
  pkey1
  , pkey2
  , val1
  , val2
  , val3
  , val4
FROM
  t_upsert_test_tmp
WHERE
  val3 = 0
  AND val4 = 1
ON CONFLICT (pkey1, pkey2)
DO UPDATE
SET
  val1 = EXCLUDED.val1
  , val2 = EXCLUDED.val2
  , val3 = EXCLUDED.val3
  , val4 = EXCLUDED.val4
;

代替UPSERT

ドキュメントに記載の通り,ON CONFLICT DO NOTHING 句(INSERTできなかったレコードは無視)は使用可能である. PostgreSQLではRETURNING句を用いることで,INSERTしたレコードを取得することができる. これらとWITHと組み合わせることで,何とかUPSERTの代替を実現することができると考えた.

WITH ct1 AS (
  SELECT
    pkey1
    , pkey2
    , val1
    , val2
    , val3
    , val4
  FROM
    t_upsert_test_tmp
  WHERE
    val3 = 0
    AND val4 = 1
)
, ct2 AS (
  INSERT INTO t_upsert_test (
    pkey1
    , pkey2
    , val1
    , val2
    , val3
    , val4
  )
  SELECT
    pkey1
    , pkey2
    , val1
    , val2
    , val3
    , val4
  FROM
    ct1
  ON CONFLICT DO NOTHING
  RETURNING
    *
)
UPDATE t_upsert_test
SET
  val1 = t1.val1
  , val2 = t1.val2
  , val3 = t1.val3
  , val4 = t1.val4
FROM (
  SELECT
    pkey1
    , pkey2
    , val1
    , val2
    , val3
    , val4
  FROM
    ct1
  EXCEPT
  SELECT
    pkey1
    , pkey2
    , val1
    , val2
    , val3
    , val4
  FROM
    ct2
) t1
WHERE
  -- ※1
  t_upsert_test.pkey1 = t1.pkey1
  AND t_upsert_test.pkey2 = t1.pkey2
;

※1は主キーの一致条件を並べるだけのWHERE句である,

やっていることとしては下記の通り.

  1. t_upsert_test_tmp から t_upsert_test にUPSERTしたいレコードを抽出
  2. 抽出したレコードを t_upsert_testINSERTし,主キー重複レコードがあった場合は無視する(ON CONFLICT DO NOTHING
  3. 抽出したレコードとINSERTに成功したレコードの差集合を求め(これがUPDATEすべきレコード),UPDATEを実行する.

CTE(Common Table Expression)はコストが高くなりがちであるが,対象テーブルが外部テーブルであるならばCTEで一度共通化しておいた方がコストは低くなるようだ(上記の例では ct1).

単一のUPSERT

通常のUPSERT

INSERT INTO t_upsert_test (
  pkey1
  , pkey2
  , val1
  , val2
  , val3
  , val4
)
VALUES (
  'ABCD'
  , 42
  , 'aa'
  , 'bb'
  , 1
  , 2
)
ON CONFLICT (pkey1, pkey2)
DO UPDATE
SET
  val1 = EXCLUDED.val1
  , val2 = EXCLUDED.val2
  , val3 = EXCLUDED.val3
  , val4 = EXCLUDED.val4
;

代替UPSERT

冗長な書き方となるが,下記のように代替UPSERTの形にすることができる.

WITH ct AS (
  INSERT INTO t_upsert_test (
    pkey1
    , pkey2
    , val1
    , val2
    , val3
    , val4
  )
  VALUES (
    'ABCD'
    , 42
    , 'aa'
    , 'bb'
    , 1
    , 2
  )
  ON CONFLICT DO NOTHING
  RETURNING
    *
)
UPDATE t_upsert_test
SET
  -- ※1
  val1 = 'aa'
  , val2 = 'bb'
  , val3 = 1
  , val4 = 2
WHERE
  -- ※2
  pkey1 = 'ABCD'
  AND pkey2 = 42
  -- ※3
  AND EXISTS(SELECT * FROM ct)
;

INSERTで指定した値を再度UPDATE部で指定し直さなければならないのが何とも冗長である.

※1はINSERTで指定した値のうち,主キーを除くものを指定している. ※2はINSERTで指定した主キーに対する値を条件としている. ※3はINSERTできたレコードが無かった場合,という条件指定である.

無理矢理1つのクエリにまとめる形としたが,多くの場合SQLはプログラムから発行すると思うので,

  1. INSERTON CONFLICT DO NOTHING)を行う
  2. INSERT件数が0件ならUPDATEを行う

といった形で,INSERTUPDATEを別々に実行した方がよいと思われる.

まとめ

  • PostgreSQLでは外部テーブルに対し,通常のUPSERT(ON CONFLICT DO UPDATE)はできない
  • RETURNINGEXCEPTを組み合わせることで,高コストではあるが外部テーブルへの代替UPSERTを実現することができる

代替UPSERTは通常のUPSERTに比べ,はるかに高コストであるため,件数が少ないテーブルに対してのみ用いるべきである. そもそも,外部テーブルへのUPSERTを行う必要がないように,設計を見直すべきであると思う.

参考

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のアバターに付けたカスタムレンダーテクスチャは機能したりしなかったりするので,重要な部分に用いず,アクセサリ程度にとどめるのがよい