GlobalObjectIdでScene内オブジェクトの参照をシリアライズする

動機

Scene内オブジェクトの参照をシリアライズしたい、ということが稀にある。

🦀ではScene内の光源を点灯→ライトマップをベイク→光源を消灯、という一連のタスクを複数回実行する必要があるんだけど、 Bakeryはベイク時にベイク対象のSceneをアンロードしてしまうので、UnityEngine.ObjectはDestroyされて参照がnullになってしまう。 それで、ベイク後にObjectを再度取得する必要があり、参照をシリアライズしたい、ということになる。

真っ先に思いつくのはUnityEngine.Object.GetInstanceId()なんだけど、この値は可変なのでシリアライズには向いてない。 インスペクターをDebugモードにしたり、SceneアセットのYAMLを見ると、local file IDという概念があるのがわかるけど、これを生で取るのはこれまではReflectionを使う必要があった・・・

が、Unity2019くらいから GlobalObjectId というAPIが用意されていて、これを使うとシュッと実装できる。最高！

自分は https://github.com/NewBloodInteractive/com.newblood.lighting-internals を眺めていてこのAPIを知った。

ちなみに、GlobalObjectIdはUnityEditor名前空間なのでランタイムでは使えなくて、ランタイムでやりたい場合はヒエラルキーのパス + Componentの型で一応参照を保持することは可能で、 🦀v2ではこの方法でBakeryをサポートしてた（ObjectReference.cs）。

以下のような制約を飲める場合はこれでも許容できるケースもあるかもしれない： * ヒエラルキー上のパスでGameObjectにuniqueに決まらないと駄目 * GetComponentで取得するので、GameObjectに該当Componentが複数ついていると駄目 * GameObjectのリネームで参照が壊れる

GlobalObjectId

ドキュメントを読めばわかるのであんまり詳細に書かないけど、中身は以下のようになっていて、4つのパラメータで1つのIDを構成してる： * assetGUID * identifierType: * targetObjectId: local file idのこと * targetPrefabId

ToString()すると"GlobalObjectId_V1-{identifierType}-{assetGUID}-{targetObjectId}-{targetPrefabId}"になっていて、逆にこれからGlobalObjectId.TryParseで復元もできるので、文字列で保持するのでもよさそう。 Objectの取得はGlobalObjectId.GlobalObjectIdentifierToObjectSlow を使うだけ。

Sceneのコピー

🦀v3ではユーザーが作ったシーンに破壊的変更をあまり加えたくないので、ライトマップをベイクするときにSceneを複製して、複製したSceneに対してライトマップを焼くようにした。 （BakeryのstaticベイクはftLightmapStorageのコピーが面倒すぎてやってないけど、やる意志は一応ある。 https://github.com/shivaduke28/kanikama/issues/166）

手続きとしては

  1. Scene内のObjectのGlobalObjectIdを取得して、assetGUID以外の値を控えておく。
  2. Sceneのコピーを作って開く。
  3. 上で控えていたやつにコピー先のSceneアセットのGUIDを加えてGlobalObjetIdを取得する

ということをやってる（Prefabが混ざるとさらに面倒そうなのでPrefabは非許可ということにしてる）。 nullだったらGlobalObjectIdentifierToObjectSlowを呼んで～みたいなのが面倒なので、ラッパーみたいなのを用意しておくと便利だった。

余談

🦀でSceneのstaticなライトマップを焼くときにやることは

  1. Sceneをコピーする
  2. dynamic（= 🦀で動かす）光源を全部消灯する
  3. ライトマップを焼く
  4. 生成されたLightingDataAssetをオリジナルのSceneに参照させる

ということをやっているんだけど、4をコードから実行する方法が用意されていなくて、では.unityファイルを書き換えるか！と思ったんだけど

という感じで、どうにも面倒なので、生で書き換える汚いコードを書いた。南無三・・・ YAMLファイルが複数種類の改行コードを含んでいると壊れそうなので、何とかした方が良さそうではある。

KanikamaにLTCを入れた

前々から🦀のユーザーからモニターのspecularが欲しいという要望をもらっていたけど、色々面倒でやってなかった。 というのも、🦀はPRTの実装であり光源のTRSはstaticであることが前提にあるが、LTCはdynamicなものに対しても使えるわけで、その辺の組み合わせには自由度があるし、立て付けをどうするかが悩ましかった。

v3で欲しい機能があったら自分で作ってね、というスタンスにしたので、じゃあ自分の中での「まあこんくらいの機能があればいいでしょ」を実装に入れてもいいな、ということで以下の仕様で入れた。

  • Texture LightのTRSはstaticしてTextureだけが動的に変わるとする。
  • diffuseはこれまで通りPRTでやる。
  • specularだけLTCでやる。
  • specularの影をdiffuseの影で代用する。
  • Texture Lightはシーンに3つまでで全て同じTextureを使う。

LTC自体は https://github.com/selfshadow/ltc_code/tree/master をVRC向けに移植したやつで特に珍しいことはしてない。 テクスチャのフィルタリングだけlox先生に教えてもらったサーフェスのシェーダーでmipmap使ってガウス関数を階段関数で近似するやつになってる。

LTCのちゃんとした影は https://eheitzresearch.wordpress.com/705-2/ があるけど、🦀に組み込むのは難しいのでdiffuseのvisivilityを使うことにした。

スペキュラのシャドウで欲しい値は、fをスペキュラのBRD（e.g. GGX）、Vをvisibilityとしたときに \int f(v,l) L_i(l) V(l) n \cdot l d l が影付きのライティングで、これが計算できないので、

\displaystyle \left( \int f(v,l) L_i(l) n \cdot l d l \right) * \frac{ \int f(v,l) L_i(l) V(l) n \cdot l d l}{\int f(v,l) L_i(l) n \cdot l d l}

を計算しましょうという話で、第1項はLTCで計算できて第2項を求めましょうという話でした。 それで、色々あきらめてdiffuseの影を使うというのはfをdiffuseのBRDF（e.g. 定数）にするということであり、

\displaystyle \frac{ \int L_i(l) V(l) n \cdot l d l}{\int L_i(l) n \cdot l d l}

を使っているということになる。なのでもちろん全然正しくなくて、具体的には影の面積がせまくなってると思う。けど、ないよりはある方がそれっぽいのでヨシ！

それで \int L_i(l) V(l) n \cdot l d l と \int L_i(l) n \cdot l d lを計算しましょうということになるけど、 これはUnityでライトマップをベイクするときに直接光だけ（bounce=0）にして、影ありと影なしでベイクすれば作れる。 あとは焼いたライトマップ2枚を使って、（影ありの明るさ）÷（影無しの明るさ）を計算すればよくて、16bit floatで十分っぽい雰囲気だったので、 BC6H圧縮したHDRテクスチャ1枚にTexture Light3枚までのvisibilityを格納できるということになる（3枚までにしたのはこれが理由）。

実際に動いているのはこんな感じ。わかりにくいけどDJブースの手前にはスペキュラが映り込んでいないのがわかる。

細かい話をすると、Unityのライトマッパーを使うとき、発光マテリアルのついたRendererを光源に使うと、影なしLightmapは焼けないです。 多分内部的には発光マテリアル付きRendererは光源としては扱われてないっぽくて、Bounce=0でベイクするとこれらのRendererから出てる光はライトマップに焼かれないっぽい。 MeshRendererのCastShadowフラグは光源向けの値っぽいので、なるほど、という感じがする。仕方ないので、🦀ではArea Lightを使ってる。

🦀v3

v3.0.0b1

ベータだけどとりあえず出した。

github.com

🦀についてはQiitaの記事を参照 qiita.com

動機

🦀は雑に言うと「ベイクする機能」+「ランタイムで動かす機能」という構成で v1は「Unityのライトマッパー」+「U#」という感じで、 v2でベイク側をリファクタして「Unity or Bakery」 + 「U#」にした。

ランタイムはU#オンリーだったんだけど、こっちも

  • 普通のC#でも動くやつが欲しい
  • Macでも使えるようにしたい
  • clusterでも使いたい
  • URPでも使いたい

というような気持ちは前からあって、VCCとU#1.0でようやくPackageとしての開発環境が整った、という感じ。

概要

Kanikamaを複数のモジュールに分割して、モジュールの一部をユーザーが自前のものを使えるようにした。

  • Kanikama.Core: Unityでライトマッパーで遊ぶ時あると便利な細かい実装が入っているところ。これ自体にビジネスロジックはない。Utilityとかにリネームするかも。
  • Kanikama.GI.Baking: UnityでPrecomputedRadianceTransferをやるためにライトマップを沢山焼いてTexture2DArrayを作るBakingPipelineの"実装"。
  • Kanikama.GI.Runtime: BakingPipelineが生成したアセットをランタイムで動かすための"実装"（通常のC#、Built-in/URPが使える）。
  • Kanikama.GI.Bakery: BakingPipelineのBakery版。Pipelineはほぼコピペ。
  • Kanikama.GI.Udon: GI.RuntimeのU#版の実装。VRC SDK、U#に依存する。

という感じになっている。

v2までの🦀ではBaking/Runtimeがくっつていたけど、ここを頑張って分離した。 結果として、ランタイム側の実装（Kanikama.GI.RuntimeやKanikama.GI.Udon）はライトマッパーやBakingPipelineのことを気にしなくてよくなったし、 BakingPipelineの開発中はU#のことを気にしなくてよくなった。

User Custom なんとかって？

User Custom BakingPipeline / Runtime

「動かないQuadライトの（例えばLTCで計算した）スペキュラーに対して、シャドウイングをしたい」みたいな状況になったとする。 こういうときに、シーンを真っ暗にして、白色のQuadライトを直接光だけでベイクしたライトマップがあれば、影がないときのirradianceはLambertの計算（LTCのdiffuseのときのやつ）があるので、 （影あり）/（影なし）を遮蔽の近似として使えるんでは、みたいなことが思いつくわけだけど、 こういうときに、ライトマップのベイクやらなんやらを自前のBakingPipelineとして実装したくなる、というか自分はなったことがあり、そのときに🦀のコードが使えなくて悲しい気持ちになったので、 今回は使いまわせる部分は使いまわせるような設計にした。

自前のアセットを作ったら、ランタイムの実装も勿論自前である。がんばって！

User Custom Kanikama Pipeline

Baking PipelineまではKanikamaを使うけど、ランタイムの実装は自前のものを使うよ、というケース。 Kanikamaはもともと可能な限り汎用的に使えるように設計してきたつもりだけど、汎用性とパフォーマンスの板挟みになるケースがちょいちょいあって、割と頭を抱えることが多かった。

例えば、Kanikamaではモニターの色をシェーダーに配る時にCameraでレンダリングした後にReadPixels/GetPixelsを使ってC#側にColor[]を持っていったあとにシェーダーに配っているけど、 これはモニターの枚数がわからないからやっているだけであって、モニターが1枚ならシェーダーでRenderTextureをmipmap指定して読みこんだ方が速いし、この形ならshaderだけでGIが実装できる（例えば、clusterでも動く）。

v3では開き直ることにして、Kanikamaが提供するランタイムの実装は"ひとつの実装例"という立て付けにして、不満がある場合はランタイムの実装だけ分離できるようにしたので自分でやってね、という感じにした。

余談だけど、 Kanikama.GI.RuntimeとKanikama.GI.Udonではモニターの実装が違っていて、前者ではTexture2D.GetRawTextureDataを使っているのでU#よりも速くなってたりする。

User Custom (Udon) Light Source

ランタイムもKanikamaに乗っかるけど、自前の光源を追加で使いたいよ、というときはコンポーネントレベルで実装を加えられるようにした。 U#も抽象クラスをサポートしたので、こういうことができて良い。

所感

実装はシンプルになったけど、使う側からすると複雑さが増したんでは、という感じがする。やっていることが複雑なので、もうエンジニア向け（というか自分が使う用）のライブラリということでもいいかな～という気持ちに・・・

ドラム式洗濯機を買った

家電

引っ越しで家電を失ったので、色々買い直した。

買ったもの

  • 冷蔵庫
  • 電子レンジ
  • 炊飯器
  • 洗濯機

このうち、洗濯機以外はアイリスオーヤマの手ごろそうなやつをAmazonで買った。

アイリスオーヤマ 冷蔵庫 一人暮らし 142L 幅50cm 最高水準の冷凍機能 冷凍室3段 53L 2ドア 静音設計 右開き ブラック IRSD-14A-B

アイリスオーヤマ 冷蔵庫 一人暮らし 142L 幅50cm 最高水準の冷凍機能 冷凍室3段 53L 2ドア 静音設計 右開き ブラック IRSD-14A-B

Amazon
アイリスオーヤマ 炊飯器 3合 IH式 デザインタイプ 50銘柄炊き分け機能 極厚火釜 ヘルシーメニュー 低温調理機能 パン・ケーキ機能 グレー RC-IL30-H

アイリスオーヤマ 炊飯器 3合 IH式 デザインタイプ 50銘柄炊き分け機能 極厚火釜 ヘルシーメニュー 低温調理機能 パン・ケーキ機能 グレー RC-IL30-H

Amazon
アイリスオーヤマ 電子レンジ 17L ターンテーブル ヘルツフリー 単機能 全国対応 一人暮らし 新生活 IMB-T178-W ホワイト

アイリスオーヤマ 電子レンジ 17L ターンテーブル ヘルツフリー 単機能 全国対応 一人暮らし 新生活 IMB-T178-W ホワイト

Amazon

アイリスオーヤマにこだわりはないのだけど、タイルカーペットや折り畳みベッドなどを使っていて困ったことがないので、じゃあこれで、ということにした。 冷蔵庫が気持ち大きめな気もしたけど、自炊を始めると普通にいっぱいになるので良かったと思う。ビールも買うしな。

炊飯器は3合炊きである程度新しいものならなんでもよいが、説明書を読むと米の銘柄が指定できたりして思ったより高機能のものを買ったかもしれない、という印象がある。 米については特に不満はないが、id:Sixeight さんに土鍋を勧められたので、丁寧ランクが上がったらそういうのも良さそうかなと思う。

衣食住のトライフォース

これまでの人生で、自分は好きなこと（PC周辺、スピーカーなど）にお金を使い、それ以外は雑、ということが多かったと思う。 最近は心境の変化があり、なんやかんや衣食住は人生と切り離せないので、目を背けるよりは向き合った方が良さそう、という気持ちになっている。

洗濯機は「衣」であり、自炊は「食」であり、引っ越しが「住」ということになる。 衣食住、なんか心技体っぽい感じがしてかっこいい。トライフォースなのかもしれない。

洗濯物を干すのがとにかく苦手なので、これは文明の力で解決するしかないということで、ドラム式洗濯機を買おうと前から決めていた。

洗濯機

ネットで調べると、ドラム式洗濯機には型が２つあるということがわかる。 全然ちゃんとわかってないけど、自分の理解だと以下のようになってそう。

ヒーター型

  • 温度が高い
  • 服が縮んだり痛んだりしやすい
  • 殺菌能力は高い
  • 安い
  • 電気代が高い

ヒートポンプ型

  • 温度は低め（65度くらい？）
  • 服にやさしい
  • 殺菌能力は低い、カビの対策が必要らしい
  • 高い

どっちがいいかわからんが、引っ越しで金を使いまくっていて気持ちが大きくなっていたのでヒートポンプ式にした。

注文してから届くまで

設置までやってくれるオプションのある、ヨドバシ.comで注文した。

搬入時にやっぱり家に置けません、ということがないように、Web上に色々注意書きがあって助かる。

ヨドバシ.com - 洗濯機・衣類乾燥機の設置

これによると、洗濯機幅+10cmの広さが必要ということになっていて、 小型の洗濯機は横幅が60cmくらいあるので、70cmくらい必要ということになる。

自分の家は廊下と洗面所の境界がドアを外したとしても幅63cmしかなくて、ちょっと怖かったけど、 確認の電話がかかってくる、ということだったのでエイヤで注文した。

ヨドバシの人からかかってきた電話の内容は以下のような感じ

  • 搬入できる広さはあるか（Web上でも書いたけど再度確認）
  • 洗濯機を置く場所の広さ、水を出すところと捨てるところの位置関係はどうか

それで家について説明すると、「一度見積業者を派遣して置けるかどうか確認した方が良さそう」ということだったので、お願いした。 ちなみに見積は100円でやってくれるのですごい。マジか。

電話がかかってきたのが日曜とかで業者が来たのが木曜日くらいだったと思う。 業者の人が言うには

  • 63cmあれば60cmの洗濯機は入る（+10cmなくても大丈夫）
  • 備え付けの洗濯機パンだと排水ポンプを洗濯機の下に置く必要があるので、洗濯機に下駄を履かせる必要がある。
  • 注文した洗濯機（AQUA）は下駄を履かせるのが禁止なので、別の洗濯機じゃないと駄目

ということだった。家の洗濯機パンは多分これ

SANEI 洗濯機パン 床上配管用 外寸640mm×640mm H546-640

SANEI 洗濯機パン 床上配管用 外寸640mm×640mm H546-640

Amazon

そのあとにヨドバシから再度電話がかかってきて、「AQUAは下駄無理って言ったけど、一応メーカーが出してる専用の下駄なら使えるが、結構いい値段する」と言われたので、 じゃあ60cm以下の別のやつにしますと言ったら、その電話で注文のキャンセルまで行ってくれた。

そのあと再度Webから注文すると、前回の注文時の見積の内容が引き継がれていて、全てがスムーズだった。

一般的に注文はそれ単体で意味を持つデータなのに、ユーザーに紐づいた過去の注文のデータを引き継げるのは便利ですごい。ヨドバシ好きになった。

60cm以下なら何でもよいということで、パナソニックの細いやつを買った。

ヨドバシ.com - パナソニック Panasonic NA-LX113BL [ドラム式洗濯機 洗濯11kg/乾燥6kg 左開き マットホワイト] 通販【全品無料配達】

実際に搬入するときは、見積に来た人と同じ人がやってきて、爆速で配置までやってくれた。

ちなみにエレベーターが無い場合、階数に応じて追加の搬入費用がかかって、下駄と合わせて6600円を業者の方に支払った。 重いものを運ぶのは大変なので、ヤマトの単身パックも同じような追加料金を要求して良いのでは、と思う。

使い心地

  • でかい。
  • 音はそんなに気にならない。
  • 洗濯物干さなくて良いのもそうだけど、乾燥が速いのが思ったより快適。
  • タオルが無いので風呂に入れない、は3hくらい待てば解消できる。
  • 衣類の洗濯表示ではドラム式での乾燥はダメということになっていても、おうちクリーニング機能でいけるものもあるらしい。
  • 機能を全て把握できてない。
  • 不安なやつは洗濯までやって、脱水する前に取り出してる。

ドラム式洗濯機 vs デュアルランド論争

普通に便利なので、長持ちするならペイするな～と思う。 一方で、短期間で急に壊れたら結構ショックがデカそう。

やはりデュアルランドの方が良いのかもしれない（？）

《Volcanic Island》[3ED] 土地R | 日本最大級 MTG通販サイト「晴れる屋」

丁寧ポイント

日々の生活の中で、なんとなく丁寧な感じがするものがある。 こういうときに丁寧ポイントを得た、ということにしている。

別に厳密な定義もデータの永続化も一切していないが、丁寧ポイントを得ると丁寧な感じがして良い。

布団を干す

これは丁寧ポイントが発生する行為である。 寝室は西向きのベランダに直面していて、午後は日当たりが良いので、折り畳みベッドを畳んで布団を干している。 ベッドはすのこがむき出して、その上に布団を敷くのだけど、安い布団なので寝心地が悪いのでベッドと布団の間にマットレスを敷いている。 マットレスは固いのでベッドを折りたたむときはマットレスをどける必要があり、これが地味に不格好というか、ハマってない感じがしてくやしい。 ともかく布団を干すと丁寧ポイントが得られるし、なんか寝るとき気分が良くて良い。 手で持つ掃除機も買ったので、ときどき布団に直接掃除機をあてて色々吸わせている。丁寧。

Amazon.co.jp: アイリスオーヤマ 折り畳みすのこベッド OTB-WH

スニーカーの手入れをする

これも丁寧ポイントが発生する。 手入れというのは、外の汚れを適応な布で拭いて、中に敷いているやつを水洗いして干す、とかそれくらい。 もうちょっと丁寧にしたいので、防水スプレー（アメダス）を買ってこのまえかけておいた。 汚れもつきにくくなって良いらしい。

手入れ中に外に出られないのは困るので、普段履いているNew Balance 996の色違いを買った。 毎日履くより一日置いた方が人も靴も休まるのかもしれない。996は歩きやすいしデザインも好きで助かっている。

996｜ライフスタイル｜ニューバランス公式通販 | New Balance

お茶パックからお茶をつくる

家で飲むのは酒以外は大抵お茶なので、ペットボトルを買わずにパックから作ると丁寧な感じがしてよい。 お茶をつくるやつは無印のやつが洗いやすくて助かってるけど、ちょっとでかすぎる気もしてる。 Webを見ていると横置きできるタイプもあるらしいので、そっちの方が良いかも。 お茶パックは抽出時間が経過したらちゃんと取り出すとより丁寧です。

アクリル冷水筒 | 無印良品

コーヒーを手で淹れる

これはボーナスステージで、自分にとっては趣味でやりたいことなのだけど、 コーヒーを淹れているときは大変穏やかになれてよい。

前職の同僚がくれた電動ミルを使っていてちょっと丁寧ポイントが低くなっているが、電気ケトルを使わずにコーヒーポットをガスコンロで温めてお湯を作っているのでプラスマイナスゼロということにしたい。 チェンソーマン４話のアキ君が朝コーヒーを淹れている演出がすごく好きなので、ベランダに椅子を置くことで丁寧ポイントを高めたい。

前の家に温度計を忘れてしまい、温度も味もブレブレなので、もう少し丁寧にドリップするとよさそう。

洗濯

洗濯は苦手過ぎるので洗濯機に一任しており、丁寧ポイントは得られていない。 高い買い物だったので、感想が終わった後は毎回フィルターを布で拭いている。これは少し丁寧かもしれない。

ふきんなどは漂白したりするべきっぽいので、そういう部分で丁寧ポイントが得られそう。

自炊

自炊は高度な概念で、とても生活の一部にはまだなっておらず、どっちかというとちょっとしたイベントになってる。 先は長いが、この道の先に"丁寧の王"がいる、そういう気がしている。


open.spotify.com

1LDKめっちゃいい

引っ越しがだいぶん落ち着いてきた。 家電を買いまくっていて、冷蔵庫と掃除機が届いていて、 洗濯機と電子レンジと炊飯器は明日届くらしい。 洗濯機はドラム式を買うにあたって色々あったので、届いたらまたなんか書くと思う。

本題に入ると新居は1LDKにした。 1LDKなので、リビングと寝室で2部屋ある。 リビングが8畳、寝室が6畳くらい。

自分はほとんどリモートワークで出社も月に1回程度なので、家の環境は結構大事になっていて、広い家に住んだらよくなるんじゃないかという淡い期待で1LDKにした。

仕事をするにはPCデスクとデスクチェアを置く必要があり、そこそこのスペースを使うので、リビングと寝室のどちらに拠点を設けるかかなり迷った。 リビング is Livingなわけで、そこで生活する時間が長いことが想定されている概念だと思うので、リビングで仕事することにした。 こういうときは概念に従う方が良い。

1LDK広すぎて持て余さないか不安だったけど、結果としてはかなり良いです。寝室概念がかなり強い。

寝室の役割が

  • 寝る
  • 着替える
  • 普段使わないものを収納する
  • 布団を干す（ベランダにつながってる）

くらいしかなくて、これらをリビングと分離できるのがかなり良い。 寝室はある程度生活感が溢れていてもリビングは自分の好きな雰囲気を維持できる。 自宅の睡眠・衣類機能と飯・仕事機能が分離されているのを感じる。

𝑪𝒍𝒆𝒂𝒏 𝑨𝒓𝒄𝒉𝒊𝒕𝒆𝒄𝒕𝒖𝒓𝒆...（？）


リビングはそんなに広い訳じゃないので、客が来たときに少し狭く感じるかもしれないけど、 稀に来る客よりも普段使う自分を優先するべき、ということにした。

一緒に住んでいる人が存在したりするとリビングは共有スペースのはずなので、 リビングがめちゃくちゃ広くないと寝室に作業スペースを設けることになりそう。 そういう場合はもう一部屋書斎みたいなのがあると良いのかもしれない。 ガハハ！独り身は気楽で良いわい！

とはいえ、客人が来て酒を飲む機会は稀にはあるはずで、流石にダイニングテーブルと椅子が必要そうなので、 ダイニングテーブルはKANADEMONOで45cm x 120cmの細長いダイニングテーブルを注文した。 PCデスクもKANADEMONOで買ったやつで、材質を同じやつにした。お揃いで良い。 椅子はまだ買ってないけど、あんまり重くないやつを2つくらい買っておいて普段は片方を寝室にしまっておくと良さそう。

「丁寧な暮らし」を攻略するためにかなり気合を入れる

丁寧な暮らしに憧れがある。

憧れはあるが、これまで一切丁寧な暮らしをやってこなかった。 1人暮らしを始めたのは大学に入ってからだったけど、そのときから今も変わらず、 今一番やりたいことをやれるだけやりまくる、ということしかしてこなかったと思う。

B1～B2くらいの頃はお絵描きにハマっていて、授業中もずっと絵を描いてた。おかげで線形代数と微積の授業の記憶があんまりない。 B3の後期からはセミナーが始まって、ありがたいことにとても熱心な先生に指導をしてもらい、 それから5～6年くらいは日々数学しかしてなかったと思う。

ポスドクの頃は自炊を少しだけやったけど、レベルが低く、特に冷蔵庫の状態管理がいまだに難しく感じる。 食材というのはDisposableなものだと思っていて、ライフサイクルが食材によって異なる。 状態が多ければ多いほど複雑になるので、ライフサイクルが短いものの方が簡単になる。

例えば、小松菜やホウレン草などは2日くらいで消費できるので簡単と言える。

人参やじゃがいもも難しい。キャベツや白菜、大根などは怖くて購入したことがない。 多くの場合、量が多いことは寿命が長いことを意味するので、うかつには買えない。

玉ねぎは微妙なラインで、火もすぐ通るし、消費が簡単なので、どちらかと言えば簡単な方だと思う。ちゃんとやれば勝てる。

量が少なければ簡単かといえばそうではない。 インターネットでレシピを調べると、謎の葉っぱなどを香りづけに入れる、ということが書かれている。 これがかなり厄介で、例えば、葉っぱが5枚入っていて、料理に使うのが2枚だとすると、困る。 他にも使えることがわかっていないと購入するのが難しい。

というか、「一人暮らしのおすすめレシピ！」みたいな謳い文句で、謎の葉っぱやら調味料やらをおしゃれに加えるのはやめて頂きたい。 UnityでC#を習い始めの人間におしゃれ目的でUniRxを少しだけ使わせようとするな。

概ね使えた調味料たち

  • 酒
  • 砂糖
  • 塩
  • コショウ
  • 醤油
  • みりん
  • ポン酢
  • めんつゆ（だし属性）
  • 酢（余った）

手を出せなかった調味料たち

  • 味噌
  • だし
  • 他にも色々あるはずだけど、知らない

自分が料理に対して感じる難しさは、つまり、系統立てた入門書を読まずに、インターネットでかいつまんでいることに要因があると思う。 自分が知っている概念（食材）で作れる良い感じの難易度で良い感じに非自明なものを例題としてあげているような本があるとよさそう。 群論を勉強していない人間に圏論を使って物事を説明をするのはやめた方がいい。

ともかく、タイトルの通り、丁寧な暮らしにはいまだに憧れがあり、今回の引っ越しはかなり気合を入れている。 食事と睡眠を良い感じにして、良い感じの人生を良い感じに過ごしていきたいです。

おすすめの料理本などがあれば教えてください。