人生初のコロナになったので罹患日記

1日目

朝 37.4℃
昼 37.7℃
夕方 39.4℃
夜 39.6℃

発熱、喉のイガイガと刺すような痛み、むせるような咳(喋る、息吸うだけで咳出る)、締め付けるような頭痛、ピントが合わないような頭のモヤ感

2日目

朝 39.2℃
昼 36.8℃
夕方 37～38℃
夜 39.4℃

症状は同じ。若干の睡眠障害あり(全然寝付けない、寝てもすぐ起きる、等)、頭痛はやや痛い程度

3日目

朝 38.4℃
昼 36.1℃
夕方 36.8℃
夜 36.5℃

発熱のみ解消。喉の痛みは増加。水を飲むだけで喉に刺したような痛みが生じる。

4日目

朝 36.8℃
昼 36.4℃
夕方 37.0℃
夜 38.4℃

再び発熱。加えて花粉症のようなサラサラ透明な鼻水、鼻詰まり、ドライノーズ(鼻腔内が乾燥していて少し息吸うだけで鼻奥が痛い)、息苦しさ

ドライノーズと鼻詰まりのせいで鼻呼吸が出来ない、または出来ても痛い。しかし口呼吸ではすぐ咳が出てしまう。めっちゃ浅い呼吸で過ごすしかなかった。

5日目

朝 38.4℃
昼 36.1～37.1℃
夕方 36.2℃
夜 38.4℃

喉の痛み、頭痛は低減。

味覚障害(味を感じない)が追加。

6日目

朝 36.1℃
昼 36.2℃
夜 36.2℃

喉はほぼ痛くない。頭のモヤ感もそれなりに解消。鼻水もほぼ解消、鼻水、ドライノーズも気にならない程度

咳が悪化。むせの咳から突然出るタイプの咳に変化し、咳が体力的に辛くなるように。また嗅覚もかなり低下。

7日目

朝 36.5℃
昼 36.8℃
夜 36.4℃

症状に変化は無し

8日目

平熱

症状に変化はなし

味覚障害と咳が酷い

9日目

平熱

症状に大きな変化はなし

味覚が少しずつ戻ってきているように感じる

10日目

平熱

夜にかけて味覚の大半が回復。一部感じにくい味もあるためバランスはやや悪いかなくらい

咳は変わらず酷い

咳は長引くらしく、他に症状が回復したので日記はここまで。

追記：22日目

ついに咳が止まる

長すぎた後遺症

感想

何もシルバーウィークの頭に罹らなくてもいいぢゃん...って感じ。
3日目あたりで熱が引いたと思ったらまた発熱して味覚が消える多段攻撃が凶悪すぎる。

味覚がほんっっっっとうに辛かった。生きる意味が分からなくなった。
このウイルスの開発者は凄い。絶対に許さない。

手洗いうがいちゃんとしてても罹るのでもう運だと思う。
二度と罹らないことを祈って今日もおいしくご飯をむしゃり。

番外：味覚障害での食べ物

美味しさを感じたもの

• LIFE ごま油風味のドレッシング
• 焼いた豚肉
• Pasco つぶいちごジャムパン
• 牛バラ肉焼肉味(脂のみ感じる)
• もずく
• キムチ

何も感じないもの

• お茶
• ポカリ
• 味噌汁
• ヤマザキ てりやきハンバーガー
• 焼きそば
• カニクリームソースのパスタ
• わかめラーメン(カップ麺)
• ランチパック ツナマヨ味

なんかでっかいファイル上げれないんすけど。

色々設定いじくってどう考えても512MBまでのデータがあげれるようにしたのに、なぜ。

構成

• Ubuntu 24.04
• WordPress
• php8.3
• nginx
• Cloudflare

対処

調べること結構なお時間

Cloudflareって100MBまでのデータしか扱えないんすね。
それ以上はR2？だか外部ストレージへって。

い、嫌でつ・・・

てなわけで脳筋になるよ。

まずはFTPでファイルをここに置くよ

wordpress/wp-content/uploads/{yyyy}/{MM}/

次にwpコマンドでWordpressにインポートさせるよ

$ sudo -u {user} wp media import path/to/media --path=path/to/wordpress

おわり。

$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

// バージョンが出ればOK
$ php wp-cli.phar --info

$ chmod +x wp-cli.phar
$ sudo mv wp-cli.phar /usr/local/bin/wp

// 使えればOK
$ wp --info

コマンド覚えらんねーよっていう人（私）向けのスクリプト

#!/bin/bash
set -euo pipefail

if [ $# -ne 1 ]; then
  echo "Usage: $0 /path/to/file"
  exit 1
fi

FILE="$(realpath "$1")"

if [ ! -f "$FILE" ]; then
  echo "File not found: $FILE"
  exit 1
fi

WP_PATH=path/to/wordpress

sudo -u {user} wp media import "$FILE" \
  --path="$WP_PATH"

echo "DONE"

いや～圧倒的に無駄な時間を過ごした。

2026/05/30 に横浜でヒロアカ10周年記念コンサートが開催されると聞き、
S席抽選を勝ち取りるんるんでパシフィコ横浜まで行ってきました♪

https://www.heroaca-concert2026.jp

午前は起きれないだろうと踏んで午後の部のみ行ってきたよ！

周り女の人しかいなくてびっくりしたよ！肩身せまい！！！

気にせず会場にｲﾝ~

座席は2F-14列-63！

国立大ホール難しくってぇ・・・

2階席だったので2階に上がったら1階席だったんだぜ
普通に迷子になった。4Fが2階席で6Fが3階席らしい、むつかしい。。。

大半の席でS席と言える程大差ない経験が得られるなら、それは本当に理想。
実際音も演出も十分すぎる程よかったから間違いなくS席だった。

第一部（第1期～第4期）

演奏は2部編成で、まずは1~4期の楽曲の演奏だった。

暗くなった・・・はじまる・・・っ！！
瞬間、、、

個性がなくても、あなたみたいなヒーローになれますか...！！

「君はヒーローになれる」
「You Say Run」
2曲続けての演奏、、、
おいおい初っ端から泣きそうだぞこっちは。

こんな感じで映像と演奏が両方見えるし、要所要所で声優さんの生アフレコもあるもんだから
感情大爆発しっぱなしなんだよね・・・
生オーケでのヒロアカ曲たまんねぇ...

セトリは既に公開されている↓ので強く印象に残ったものだけ
https://x.com/heroaca_anime/status/2060744063071162425?s=20

「ヴィランの進行」
「暴走する悪意」
USJで死柄木が攻めてきた時の曲
映像とオーケストラの威圧感たっぷりの演奏。。。全身震えたのを思い出す。。。

「爆殺王!!」
かっちゃん♡
岡本さんも生で見れて特大ハッピー
あんな温厚そうな雰囲気なのにどこから声出てんの...

「三位一体」
AFO vs オールマイトのとこ
山下さん、岡本さん、梶さん3人の生アフレコとこの曲とこのシーン、興奮しないはずもなく。
かっちゃんが切島くんの手を掴んだ後、轟くんのシーンに戻った後の1セリフ
　よし、逃げるぞ
これで締まるの草　いやシーン的に丁度いいけどさぁｗ

「All Might with U.A. Students」
さらばだ、OFA...
AFO vs オールマイト決着のシーン
次は、君だ。
のシーンを含めてこの一曲にまとめあげたそのセンス、素晴らしいです...

「勝己と出久」
なのになんで...！おれがオールマイトを終わらせちまってんだぁ...？！
岡本さんの演技、オーケストラの盛り上げ方、胸がきゅっとなって涙が滲んできた...
かっちゃんの声で、かっちゃんの悩みを文字通り目の前で聞くの、胸張り裂けそうだった、、、

「俺が君のヒーローになる」
ルミリオンが個性失って尚戦い続ける名シーン。改めてミリオすごすぎる。
ここも曲の盛り上げが上手すぎてサビに入るときの鳥肌と思わず手に力が入ってしまう演出、すごくよかった。

「Might」
元気とユーモアのない社会に 明るい未来は やって来ない..
ボーカルの方の歌も相まって、ここまでの流れも含めて感動がすごすぎた。
記憶の中の映像がどんどん繋がって、それがオーケストラとボーカルで引き立てられて、
言葉にできない、これが感動ってやつか、って感情に包まれてた。

幕間

ここで小休憩。林さん、声優3人のトーク。
一瞬 あれ？！お、おわり？！いや、十分感動したしええか・・・ って思ったら全然半分だったって言うねｗ

曲の背景とか、どの曲が好きですか～とか、曲にまつわる色々が聞けて楽しかった。
BGMあるあるだと思うけど、生演奏を想定してないから今回に合わせて編曲大変だったとか。

第二部（第5期～FINAL SEASON）

「それいけさらに向こうへ」
「歴代継承者」
A組 vs B組のシーン
ちょっとダークな雰囲気が深まったなって感じる良い2曲
オーケストラも重みがあって身体に響いてきてとてもよかった

「恐怖の象徴」
リデストロあたりのシーン
ダーク全開！震える程のずっしりした音と、恐怖感が伝わる素晴らしい演奏

「Revengers」
7th！浮遊！
この曲の絶望的な状況からの覚醒感、たまらんです。。。
サビのわくわく感とかほんとやばい、やばい（語彙力）
唯一惜しかったのは、僕がどうなろうとも！！のとこ、声欲しかったなぁ・・・

「The Last Wielder」
レディ・ナガンのシーン
オールマイトの
　誰もが知ってる、鉄砲よりも速く駆けつける
これ伏線になってるのいいよね、好き。
私はジェントルやらレディナガンやらの、元は正義で純粋悪じゃない大人が大好きなので。。。
ここでレディナガン見れてとても嬉しかったです。。。
あとこんなかっこいい曲だったっけ？！って震えながら感じてた。
（この辺りから涙腺が大分怪しい）

「I'm sorry for everything I've done」
今までごめん。のシーン
賛否両論あるけど、かっちゃん好きだよ。。。（クソデカ感情）
これ生アフレコだったんだけど、泣かないはずもなく。ぽろぽろ泣いてた。

「STAR AND STRIPE」
スターアンドストライプのとこ
相変わらず強すぎな～この人ｗｗ
スターの登場から退場までをまとめ上げてて、しっかり活躍が見れたし、オーケストラに合わせてその偉大さを感じれてとても良かった。
かっこいいよスター。

「Butterfly Effect」
復活かっちゃん vs AFO のシーン
クラスター覚醒からの映像。
オールマイト救うところからかな？って思ってたから少し意外だった。
速すぎて止まれないとこ生アフレコあって迫力と面白さが混ざってて感情ぐっちゃになりそうだったｗ
まだ、追いつけっかなぁ...を知ってるからこそ、ここでの 今なら追い越せそうな気がする で感動するんだよなぁ・・・
かっちゃん好きだ...

「You Can Do It!」
最後、デクが皆の力を借りてAFOへ立ち向かうシーン
ちなみに、ここで一瞬ジェントルが出てきて、そこで涙腺決壊した。
そこ？！って感じだけど、ジェントル好きだから仕方ない。。。

ここ、ずっとオーケストラの迫力と、皆必死になってデクを支える映像一気に流れてきて、
思わず手に力入れて 頑張れ...！！って思ってしまった。
まさに "頑張れって感じのデク" ってのを肌で感じれて本当に良かった。

もうずっと泣きながら、ペンラ持ってないのに握っている手が動いてて、
音楽と作品に身体も心も動かされているのを感じた。全部大好きだぁ・・・

最後、山下さん渾身のスマッシュ！！が聞けて大満足。かっこいいよデク...

アンコール

手拍子に合わせて帰ってきた林さん
アンコールに相応しい曲、何だろう、、、You Say Runとかもっかいやるのかな？
って思ったらなんかルンルンの林さん

「Hero too」
あ、文化祭の耳郎ちゃんの曲！！
ぴったりすぎるのありましたわｗｗ

他のBGMでもボーカルしてた女性の方が歌ってたの知らなかった。
もう一人外国の方でボーカルの方いるんだけど、その方ともくっそ楽しそうに歌っててめちゃ楽しかったｗ
あと林さんペンラ振り回してパフォーマンスしてたｗ器用だなぁｗｗ
（後で元体操選手って知ってびっくりした。すごすんぎ）

プレゼント

林さん「ここで皆さんにプレゼントがあります」

え？なに。。？
ざわつく会場

林さん「スマホの電源入れてもらって、ここからは撮影OKです」

え？！な、なに？！？
もっとざわつく会場

ヒロアカに関係した方、オーケストラに関与した方、作曲に関与した方、そして私達。
今日この日にかけての全てに感謝が添えられ、始まる演奏。

「You Say Run」

こんな、こんな最高のプレゼントを頂いてもいいんですか・・・（涙）

ヒロアカファンの誰もが生で聴きたかったこの曲を、2度も聴かせてくれて、さらに録音まで・・・
演奏後は拍手喝采、私も手を上げ精一杯の感謝を込めて大きく拍手しました。本当にありがとう─...

最後は林さん、山下さん、岡本さん、梶さんの4人の声かけで、
「さらに向こうへ！Plusー！」
全員「Ultraーーーー！！！」

さいっっっっっっこうに楽しい、最高に心震える、最高の思い出ができた。
本当に本当に特大感情が溢れて止まらないコンサートだった！！

おわりに

うっきうきで帰路に。

間に合いそうだし関内二郎でも食べて帰ろうかな～
な～んて思って電車に乗ったら
...なんか人身事故で止まってるんですけど？？？

諦めて桜木町駅まで歩くことに。せっかくだから夜の横浜散歩～

みなとみらい駅からビル伝いに歩いて行けるの斬新で面白いな～
と思いつつ結局外に出ることにセルフツッコミしながら歩くこと10分

なんか空中を浮く謎の箱がある！！
ロープウェイってやつ？！こんな街中に？！？

珍しかったのでうきうきでぱしゃり
良いことあったね～

おわり。
コンサートはUnderTaleも行ったし、シッティング系ならはちたやのライブがそうだったし、
オーケストラめちゃ好きだ～～

ヒロアカ以外にもまた機会あったらコンサート行きたいな！

最近出たuse_figmaプラグイン...
ずっとUI系の仕事をしてたので、さすがに試してみたいですよね。

ということで触ってみたという記事です。

ついでにDESIGN.mdなるものも出てきたらしく。
指示さえできれば、指示されできればしっかりしたデザインをAIで作れるんじゃ？って検証も一緒にしたいと思います。

情報

use_figma plugin: https://github.com/figma/mcp-server-guide/blob/d8bcb41b17ae473b3a830129bcd451ee1911e512/skills/figma-use/SKILL.md

figma公式: https://www.figma.com/blog/the-figma-canvas-is-now-open-to-agents/

DESIGN.md: https://qiita.com/miruky/items/a6312c14e6352376ec00

環境

• Windows11 home
• WSL2 Ubuntu22.04.4
• Cursor 2.6.22 Proプラン

環境設定

プラグインインストール

Cursor Settings > Plugins > Figma

figma-useがあることを確認したら（しなくてもいいが。）Add to Cursorでプラグインをインストール

Figma MCP接続

再びCursorSettings > tools & MCP > Plugin MCP Servers からconnect

DESIGN.mdの作成

CLAUDE.mdと同じ要領で作れるとのことで、agentに作らせてみる。

だいたいどんなUIデザインにしたいかな～を頭に浮かべつつ・・・

あなたはWebUIデザイナです。
DESIGN.mdを作成してください。
以下詳細な要件です。

全体的なデザインはモダンなWebUIで、デザインベースはそちらに任せる。
ユースケースはiOSブラウザ、Windowsブラウザ。
色はオレンジと黄色を基調とした暖かみのあり家庭的な構成とし、色度が低めで目に優しいカラーベースを取る。
ボタンインタラクションはホバー、押下、選択中、通常の4種類。
遷移、UIを説明する文章などは最小限に、アイコンなど非テキスト的な表現をベースとする。

その他、今のプロジェクトに必要なUIの内、上記で定義されていない内容があれば質問して

↑こんな指示をしてみて、
↓こんなのを生成させてみた。

# Meal Menu App — Web UI デザインガイド

本書は [docs/plan/implementation-plan.md](../docs/plan/implementation-plan.md) の Web フロント（Next.js + Tailwind + FullCalendar）に対する**見た目とインタラクションの規範**である。実装は [tailwind.config.ts](./tailwind.config.ts) と [src/app/globals.css](./src/app/globals.css) にトークンを反映していく。

## 1. スコープと前提

| 項目 | 内容 |
|------|------|
| アプリ | Meal Menu App（献立カレンダー） |
| 対象画面 | `/`（ログイン導線）、`/app`（献立カレンダー：月・週・日・リスト表示、範囲選択・イベント操作）、`/app/menus`（メニュー CRUD） |
| クライアント | **iOS Safari**、**Windows**（Chrome / Edge / Firefox を想定した一般的な挙動） |
| テーマ | **ライトのみ**。ダークテーマ用の色トークンは定義しない |

## 2. デザイン原則

- **トーン**: モダンな Web UI。家庭的で暖かみのある印象を、**低彩度**のオレンジとイエロー（クリーム〜アンバー系）で表現する。
- **情報量**: 画面説明・遷移を文章で長く書かない。可能な範囲で**アイコン・レイアウト・色分け**で状態を伝える。
- **ラベル**: ナビや主要操作は**アイコンを主**とし、短いラベルは任意。アイコンのみのコントロールは [§7](#7-アイコンと非テキスト-ui) と [§8](#8-アクセシビリティ) に従う。

## 3. カラートークン（セマンティック）

彩度は抑え、背景と本文のコントラストは **WCAG 2.1 の AA（本文 4.5:1 相当）** を満たすことを前提に調整する。下表の例は参照用であり、実装時は測定して微調整してよい。

| トークン名 | 用途 | 例（参照） |
|------------|------|------------|
| `--color-background` | ページ全体の下地 | ごく薄いクリーム〜ウォームグレー |
| `--color-surface` | ヘッダー・カード・パネル | 白に近いオフホワイト |
| `--color-surface-elevated` | モーダル・ドロップダウン等の一段上 | `surface` よりわずかに明るい or 影で区別 |
| `--color-border` | 区切り線・入力枠 | 低彩度のオレンジグレー |
| `--color-text-primary` | 見出し・本文 | 暖みのあるダークブラウン〜チャコール |
| `--color-text-muted` | 補助・メタ情報 | `text-primary` より明度を上げた色 |
| `--color-accent` | 主 CTA・リンク強調・選択の主色 | **ミュートされたオレンジ** |
| `--color-accent-soft` | ハイライト背景・バッジ・「今日」など | **低彩度のイエロー〜ピーチ** |
| `--color-danger` | 削除・エラー（使用頻度は低め） | 彩度を抑えたテラコッタ〜レッドブラウン |
| `--color-success` | 成功（任意） | 彩度を抑えたオリーブ〜セージ |

**禁止に近いこと**: ネオン調の高彩度オレンジを全面背景にしない。`accent` は「塗りつぶしの大面积」より、ボタン・フォーカス・小さな強調に使う。

## 4. タイポグラフィ

- **フォント**: ルートレイアウトで読み込んでいる **Geist** 系（`--font-geist-sans` 等）を既定とする。変更する場合は本書と [src/app/layout.tsx](./src/app/layout.tsx) を同時に更新する。
- **階層**（目安）:

  | 役割 | 目安 |
  |------|------|
  | ページタイトル | 例: `text-xl`〜`text-2xl`、`font-semibold` |
  | セクション見出し | 一段階小さく、`font-semibold` |
  | 本文 | `text-sm`〜`text-base`、`leading-relaxed` |
  | キャプション・補助 | `text-xs`〜`text-sm`、`text-muted` |

- **行の長さ**: 説明文が続くブロックは **最大幅を制限**（例: `max-w-prose` 相当）し、長文は避ける（§2 と整合）。

## 5. スペーシング・レイアウト・タッチ

- **コンテナ**: メインコンテンツは既存と同様、**最大幅 ~72rem（`max-w-6xl` 前後）** を基準とし、横余白は `px-4` 程度を維持する。
- **タッチターゲット（iOS）**: タップ可能な要素は **最短辺 44px 相当以上**（`min-h-[44px] min-w-[44px]` または十分な `padding`）を満たす。
- **密度**: 献立カレンダー・メニュー一覧は誤タップを避けるため、リスト行・カレンダーセル内の操作域は余白を確保する。

## 6. ボタンとインタラクション

すべてのボタンおよび「ボタン相当」のクリック領域（セグメント切替・ツールバーのアイコンボタン等）は、次の **4 状態**を区別できること。

| 状態 | 条件 | 見た目の指針 |
|------|------|----------------|
| **通常** | デフォルト | `accent` または `surface`＋`border`。本文とのコントラストを確保 |
| **ホバー** | ポインタが乗る（`:hover`、タッチでは該当しにくい） | 背景を一段変化、または境界・影をわずかに強める |
| **押下** | クリック中（`:active`） | ホバーより一段暗く、または内側に沈む影で「押している」ことを示す |
| **選択中** | トグル ON・セグメント選択・リストの現在行など（`aria-pressed="true"` / `aria-current` / `data-state=selected` 等と対応） | `accent-soft` の背景＋`accent` の境界または下線で明確に |

**キーボード（Windows 含む）**: `:focus-visible` 時は **必ず視認できるフォーカスリング**（`accent` 系のアウトラインまたはリング）を付与する。マウスだけの `:focus` と区別してよい。

## 7. アイコンと非テキスト UI

- **セット**: 新規にアイコンライブラリを入れる場合は **Lucide React** を第一候補とする（未導入でもよい。導入時は依存関係とツリーシェイクを考慮）。
- **一貫性**: 献立カレンダー・メニュー・ログアウトなど、**同じ意味には同じアイコン**を使う。ストローク太さ・グリッドサイズ（例: 20px / 24px）を揃える。
- **装飾**: アイコン色は `text-primary` / `text-muted` / `accent` のいずれかに寄せ、カラフルな絵文字に頼らない。

## 8. アクセシビリティ

- **名前**: アイコンのみのボタン・リンクには **`aria-label`**、または画面上は隠した短いテキスト（visually hidden）で**操作名**を必ず付与する。
- **状態**: 選択中・展開済みなどは `aria-expanded` / `aria-pressed` / `aria-current` を適切に使う（§6 の「選択中」と連動）。
- **コントラスト**: §3 の前提を満たさない組み合わせは採用しない。

## 9. FullCalendar（サードパーティ）

[src/app/globals.css](./src/app/globals.css) の `--fc-*` 変数は、**§3 のトークンと矛盾しない**ようにマッピングする。

| FullCalendar 変数 | マッピングの考え方 |
|-------------------|-------------------|
| `--fc-page-bg-color` | `--color-background` に合わせる |
| `--fc-neutral-bg-color` | `--color-surface` またはややニュートラルな拡張 |
| `--fc-border-color` | `--color-border` |
| `--fc-button-bg-color` 等 | ツールバーボタンは §6 の「通常／ホバー／押下／選択中」に対応できる色 |
| `--fc-today-bg-color` | `--color-accent-soft` |
| `--fc-button-text-color` | `--color-surface` 上で読める色（必要ならボタン専用のオンカラー） |

カレンダー内の献立イベント（`.meal-banner` 等）も、**本文が読めるコントラスト**とトークンとの整合を保つ。

## 10. 実装メモ（Tailwind との関係）

- **CSS 変数**: `:root` に §3 の名前を定義し、Tailwind の `extend.colors` で `background: 'var(--color-background)'` のように参照する方法を推奨する。
- **併用**: コンポーネント単位で `bg-[var(--color-accent)]` のように直接参照してもよいが、**名前の一覧は本書と `globals.css` で一致**させる。
- **既存の `--background` / `--foreground`**: ルートの意味を本トークン体系に寄せるか置き換えるかは実装 PR で決め、本書のセマンティック名を優先する。

## 11. 本書で扱わないもの

- **ダークモード**用のパレット（§1）。
- **コンポーネントごとのピクセルパーフェクト仕様**の網羅（必要なら Figma や個別issueで補完）。

---

*最終更新: デザイン変更時に本書を更新し、実装（Tailwind・globals・FullCalendar 上書き）と同期すること。*

figma_useプラグインでfigma上にデザインを作ってもらう

いよいよ本題。
Figma上にデザインを作ってもらう...！！

/figma-use あなたは熟練のWebUIデザイナです。
@apps/web/DESIGN.md に従い、このプロジェクトに沿うUIデザインをfigma上に作成してください。

・・・ん？

じょ、じょうげん・・・？？？

ｲﾔｱｱｱｱｱｱｱｱｱｱｱ

悲しみの課金。そして続き。

出来上がったものが以下。

・・・・・・・・・🤔
Figma Makeと大差なくね？？？？？？？

適当に作らせたUIの色付け版みたいになっちゃった。
多分指示が悪かった、、、のだと思いたい。。。
（プロンプトエンジニアリング下手なんでもっと勉強しなければ...）

もう少し調べてみた

どうやらDESIGN.mdはCLAUDE.mdとは違い、便宜上のファイルのようで、
別にこの名称じゃなくてもいいし、なんなら複数ファイルに跨っていても良いらしい。
　→最終的にCLAUDE.mdでルーティングできてれば問題ない。

そして、Stitch向けのテンプレート ということらしい。
まぁ概念は応用できるが、完全に同じ使い方は難しそう。

そして、サンプルではこれを元にチャットベースでUI構築を行い、index.htmlを作成することで作っていたよう。
つまりfigmaなどのデザインツールとMCP連携して云々はそもそも使い方が違いそう。

思い描いたワークフロー

画期的じゃん！って思ったのは理由があって、
これ業務活用することでデザイナが抱える属人性の低下や、発生しがちな用語の定義ブレ、
その他あらゆる問題をmdに強制させて、チーム開発の速度・精度向上、さらにエンジニアリングを追加してフロント実装も手軽にできるようにできるのでは？！
って考えてた。

どゆことっていうと、
md（DESIGN.md）を一種の仕様書のように扱うことができ、
md ↔ figma で最終的にデザイン設計を複数のmdに残すことで、
デザインノウハウの回収、流用のベース（skill化など）に応用できる
って考えてた。

結局はコードベースになっちゃうけど、
個人的にfigmaが仕様書です！のスタイル大嫌いだからむしろこうなってほしい感はある。。。

あったのだが！力及ばず・・・

どこかでリベンジしたみ

もう少し手を加えてみる

ちょっと悔しいのでプロンプト修正

/figma-use 
https://www.figma.com/design/IKKjvbf33ZD9zbUs5wce8E/Meal-Menu-App---Web-UI--DESIGN.md-?node-id=0-1&p=f&t=BWaZoI4S6TLTZSw9-0 
@apps/web/DESIGN.md に従いUIを作成してもらったが、ここからデザインの修正を加えたい

まず元々apps/webに作成されたデザインがベースのようになっているが、これを一切廃止し、完全新規でDESIGN.mdに従った条件でリデザインして欲しい。
次にポップアップで表示されるべき内容のデザインがないため、全ポップアップ遷移を含めてデザイン作成をしてほしい。
またアイコンはSVGで作成し、テキストによる説明は基本NGとする。
レスポンシブデザインに対応し、iOS、PC、ブラウザ拡縮などに対応し、適切なUXを得られるようなUIをデザインして欲しい。
なお使い回しが可能なものに関してはコンポーネント化すること。

以上条件に従って修正して。

おお、悪くないか？

（Googleマークはアウトなんじゃ・・・）

あ、だめそう。

やっぱり仕様に起こされてない部分が激よわ。
全画面分の要件をドキュメント化することができれば実現可能なのか？
　→それはデザイナにとって嬉しいのか・・・？

今回はタイムオーバー
次やるときはもう少し情報仕入れてリベンジしたい！

なんだかんだもう3年は聴き続けてる推しシンガー、HACHIさんのライブ Unlockture に行ってきたレポートです。

https://www.youtube.com/@HACHIVSinger

無料パートあるので聴いてください！！！！！！
https://www.youtube.com/watch?v=SLbAdBBFoII

感想

Close to Heart, for ASTRAとライブを見てきて今回三回目。
これまではライブハウスでの開催が多かったですが、なんと初のホールライブ。

ホールライブはアンテのコンサートでしか体験したことなかったのですが、
バラード多めのHACHIさんがどのようなライブに仕上げるのかワクワクしてました。

形式はオールシッティング。
ライブというよりはコンサートに近い感じでした。

だからこそ、しっとりと、しっかりと、
HACHIさんの歌声に乗った感情や歌詞の言葉一つ一つを、じっくりと味わって聴くことが出来ました。

まぁめ～～～～～～～～～～っちゃよかったわけですね。

私は特にバラードが好きで、歌詞に自分を重ねて共感するのがとても好きなのですが、
世間ではあんまりなのか、ただ大きな音と激しい曲調なら何でもいいみたいなつまんない雰囲気が良しとされてるように感じます。

そんなモヤモヤを最近特に感じてた中でのこのライブ。
そりゃ良かった以外言いようがない。
自分が求めてた、自分が最も音楽を楽しめる環境でのライブ、そりゃよかったしか言えません。

まさかVシンガーにも（というか界隈にも）これをしてくれる人がいるとは...

何となく今日まで好きな理由が分かった気がしました。

セットリスト

なんとご本人様がツイートくださってました。ありがてぇ
https://x.com/8HaChi_hacchi/status/1999489124995391660?s=20

1. To Be Alive
新曲。
ちなみにアルバム新曲は先行リリース含めて聴いてなかったので、
どんな曲かワクワクしてたらいきなり来た！？ってびっくりした。
歌詞がストレートに重い。だがそれが好き。
さすがに最初はテンション高めの曲かなって思ってたから構えてなかったから、
もう一度ちゃんと聴きたい。

2. fragment
好き曲きた～～～～！！
この曲すち！！ってテンション上がった。
HACHIさんの高音綺麗すぎな。

3. ∞
新曲。
この曲もびっくりするぐらい感情が重い。
存在証明とか、その辺の歌はめっぽう弱いのでね...

4. Brand New Episode
アルバム収録曲。
https://www.youtube.com/watch?v=NR6Qa_pb1M0
早朝のようなさわやかがある曲。
歌詞もちゃんと重くていい。
MVも流れてた。かわいい。

5. まなざし
好き曲きた！！
この曲はClose to Heartでの演出が一生思い出に残ってるくらい良い曲。

6. いつまでも
これも好き曲。
曲想がおしゃれで好き。

7. √64
実は仕事終わりなので若干の疲れもあり、
あまりにもしっとり癒しすぎて寝そうになった。
心地よすぎるのです。
'音のない宇宙で眠りたい' って歌詞があるんですけど、
この音に包まれながら眠りたい...ってなった。

8. 空が待ってる
好き曲。
後ろ向きな中、前を向いて歌うような。
どことなく切ない曲、好き。

9. ビー玉
そういえば久しぶりに聴いた曲。
曲全体の抑揚がすごくて聴き入った。
感情の揺れとかが伝わって良かった。

10. 夏灯篭
これも久しぶりに聴いた曲。
切ない曲。
テンポ的に心地よくて眠気がすごかった、。

11. 万華鏡
歌詞が面白くて好き曲。
VJの万華鏡も綺麗で良かった。

12. Rainy proof
きちゃあ！
失恋曲、いいね。。。
しんみりして若干涙腺に来た。

13. Empty town
新曲。
良かったのは覚えてるけど曲が思い出せないっ...!!!
悲しい、アルバム出たら聴き直したい。

14. Deep Sleep Sheep
テンポが良くて好き曲。
でも歌詞はしっかり重い。それがいい。

15. 異星から
おもしろ曲。
こういう曲調なんて言うんだろうね。
Barとかで流れてそうな感じ。好き。

16. Chère amie
新曲。
まさかの語りがある曲。
ミュージカルみたいな感じして楽しかった。
歌詞は切なかった記憶。

17. 光の向こうへ
MCでこの曲を匂わせてからの、来たぁぁぁ...
最初の曲が今日歌ってもしっかり感動できるってのは、すごいことだと思うのです。
MCがあったこともあり、歌声にあまりにも感情が乗りすぎていて、
ホールという環境でその歌声がダイレクトに伝わりすぎて、
まるで曲の一部になったかのように心が動いたのを鮮明に覚えている。
'僕たちは弱いけど歌うよ。僕たちは怖いけど歌うよ。'
そういって歌い続けて、今歌ってるんだってことが歌声から伝わる。
しっかり号泣しながら聴いてた。ありがとう─...

18. Pale Blue Dot
HONEY BEESかな、でもテンション違うか、って思ってたらこの曲...！！！
コーラス歌うの楽しかったよ...
この曲も感情激つよ激おもで涙腺どこいったくらい泣いた。
光の向こうへで感じた、"今歌っている"ということを示すように、
はっきりとそこで歌うHACHIさんの姿が素敵すぎてとても泣いた。

幕閉じ。
鳴りやまない拍手。
皆HACHIさんの歌が好きで、こういう曲が好きな人たちで、
ちゃんと聴いて余韻に浸っているのがよく分かって嬉しかった。

しばらくしてアンコール。

19. Before anyone else
新曲。
アンコールで新曲？！そんなことある？！って思ったけど、
めっちゃ感情強い曲でしっかり感動した。
またアルバム出たらちゃんと歌詞も読みこんで聴きたい。

光の向こうへの感想の続き

この曲は弱さが前面に出されていて、それでも歌い続ける、進み続けるという力強さがある曲。

'届かなくても君に歌うよ'
この席でちゃんと聴こえてるよ。そう思い、気づけば涙がこぼれていた。

なんとなく声が震えてるのが分かり、それでも力強く歌っているのがまた感情を動かす。

この全面的な弱さが、自身の心と共感できすぎて他人事じゃないように感じる。
だからこそHACHIさんの歌が好きなんだろうと、改めて強く感じた。

私自身が常にネガティブで、でも諦めきれないこともあって。
そんな感情にストレートに、"一人じゃない" というような、心に寄り添うような。
歌声から伝わる感情が心を掴み、直接動かされるような。
きっとこの曲に感じた気持ちがあるからこそ、今回のライブがより感動したんだと思った。

後書き

本当は終わってから二郎 京急川崎店に行こうと思ってたけど、
あまりにも良すぎて、心が満足しすぎて食欲がなくなるという事態になり家へ直行。

帰ってからもしばらく何も食べれずベッドに転がりながら余韻に浸っていた。

”良かった” この感情で心が埋まったのは久しぶり過ぎて、
楽しさと感動を思い出しながらしばらく過ごしてた。

3回目のライブでしたが、渋谷O-East、Zepp新宿と来て今回カルッツかわさき。
年々ステージが遠くなっていくことに一人しみじみと感動していました。

最近、好きだったものが嫌いになることが多く。
特に好きと感じていた頃とその人が変わってしまったためというのが大半で、
好きでい続ける難しさを感じていました。

HACHIさんのテーマがずっと心に寄り添う曲と一貫していて、
そのテーマが好きになって、
それが今でも変わらないことが何より嬉しくて。

いい人に巡り合えたなととても感じる良いライブでした。

アルバムも、今後の活動もとても楽しみ！
HACHIさんの歌は、いいぞ。

JMSでシースルーLEDを見て、ぶいすぽフェスで再びライブ演出が再燃。
ほんでLEDビジョンってどういう仕組みなん？っていうのを調べてみる。

シースルーLEDを調べた会
https://irukanonedoko.com/consider-transparentdisplay-jms2025/

色んな事情

JMSで偶然NovastarのVX16Sを使っているのが見えた。
これの出力はEthernetとHDMI。

JMSの時はてっきりHDMIかと思ったが、
2週間くらい考えてやっぱりEthernet以外ありえんわってなってさらに調べることに。

確定てきなソースはないが、Artnetでもなく各社の独自仕様になっているらしい。
CANみたいな感じでパケットが特殊なのかなぁ。

LEDビジョンのレンタル会社が必ず機材のレンタルも出してるのは、
LEDビジョンごとに対応するビデオコントローラーがあるから。

つまりNovastar対応のディスプレイならVX16Sで扱える、ってことっぽい。

Novastarってどんなん？

沢山調べてたらYoutubeにNovastar系ビデオコントローラの動画が公式であった。

LEDビジョンはパネル単位のディスプレイをいくつも組み合わせて一枚のディスプレイにしているが、
なるほどビデコン毎の専用ソフト（NovastarならNovaLCT）でパネルの繋ぎ方などをコントロールしているのか。

こんなイメージかな？

Novastar側でパネルの組み方も変えれるからおそらく外部入力でも変えれる。
多分こういう構成にして、仮想環境は開発と本番を兼用してる感じある。

またNovastar側でEthernetに変換するため、入力はHDMIでよい。
これならUnityへの映像伝送も別のコンバーターをかませるだけなので、
スイッチャー以降をインターフェース化できる。

例えばこんな構成（ぶいすぽフェスの構成）

基本的には1, 6がサイド、2, 5が演出用、3, 4がメイン

こんな風に全てを1枚として使ったり

部分的に分けたり

グループごとに分けたり

こういう切り替えをどうしてるのかって、考えてみると分からなかった。

これらも、1~6ごとにブロックにしておけばスイッチャーから切り替えれる。
後は白四角の範囲で映像を作れば、一枚のディスプレイとしても、個別のディスプレイとしても扱える。

ここもビデコンに依存されず、HDMIとして出せる形式を終端にしておけばUnityにも出せる。

自作するとしたらを考える

LEDビジョンはたっけぇので無理。（うん十万レベル）

実務を想定するのであれば、先ほどの構成図でUnityに出せるようにしておけばおそらく大丈夫。
スイッチャー以降はインターフェースになってるからね。

手っ取り早いのは Unityカメラ → Touchdesigner → Unity というフォールバック構成
最初のUnityカメラは、本番でも使えるし、リアルステージを映す場合でも切り替えれる。
Touchdesignerは楽だから。スイッチャーもここに入れちゃうのが〇
最後のUnityは仮想環境。ここで指定したディスプレイに映れば本番想定でやれる。

実際はどうなの？

基本的にはLEDビジョンの取り扱い会社が機材設置まで請け負ってることが多そう
（サイト見ると大体そんな感じ）

自分みたく演出設計/実装側からしたら、最終的にHDMIで映像が送れる状態になれば良いのだから、
Novastarの操作方法自体はそこまで知らなくてもよさそう。

中身がEthernetと言えど独自規格だと手が出せないし。

ちなみにシースルーは単にピッチが広くなっただけ、という捉え方ができる。
LEDビジョンを扱う会社が持ってるのも納得。

今度作ってみよう。
今回はここまで。

※ 調べた限りで全く本職ではないので推測でしかないです。

ぶいすぽフェス2025に行ってきました！！

https://event.vspo.jp/vspo-festival-2025

ぶいすぽをちゃんと見始めてもうすぐ1年という浅いファンですが、沢山楽しめたし沢山感動した良いフェスでした✨

なんと楽屋トーク付きプロローグ、そして両日通しSSで当選したので大満足セットで楽しんできました！

DAY0 プロローグ

早朝(といっても9:30)、LaLaアリーナに到着

迎える大きなぶいすぽマークの看板！
気合い入ってて良い！

人数は数千規模くらいで程よい感じ

11:00から開会式で、特に回れる場所も無かったので早速アリーナへ
入場して大きなキービジュが見えて結構テンション上がった

アリーナ内撮影禁止なので何も上げれないんですが、
思ったより会場が小さく、どこにいてもしっかりステージが見える感じ。
ほんと程よい。

ステージ上にコメ欄とQRがあったが、
どうやらリアルタイムでコメントを送って表示出来る仕組みのよう。

https://visibby.com

↑これ使ってた。こんなサービスあったのね～
みんな思い思いにコメントしてて面白かった

𝕏のタグ投稿企画で、FAを募集していたのだが、
その画像がステージ上のスクリーンに沢山流れてた

あっ、見たことある！これ好き～！みたいな感情で見ながら開会待ち。

開会式後は楽屋トークまで時間あったのでキッチンカーへ
すんごい並んでたので列が短かったパンケーキだけ買って食べることに

まぁこういう系はクオリティがね……

って思いきや！！

分厚い！フルーツ美味しい！生クリームたっぷり！しかも2枚！

無事腹パン
フードちゃんと美味しいの好感良すぎ～

楽屋トークが長引いたみたいなのでドリンクへ
らむちのぱちしゅわドリンクと、ひねもすドリンクを買った

これもまた画像通りで綺麗だし美味しい！

さっぱりしつつもフルーツの主張がちゃんとあるバランスの良いひねもすドリンク
そしてちゃんとぱちしゅわしたらむちドリンク！

大満足です✨

そしていよいよ楽屋トークのお時間……

1分間の1on1トーク、私はあかりんとのトークに当たりました
最近あかりんの配信をよく見るようになり、明るい声に元気を沢山貰っていて、その感謝を伝えてきました

ブース入った時、開始したか分からないくておどおどしてたら、あかりんが同じようにおどおどしてくれて可愛かった

ありがとう─…

帰りに時間あったのでひなーのドリンクを買った！
あまあまで美味しかった

ドリンク売り場に手書き？のカードがあって嬉しかった

DAY1

9:00から物販ということでさらに早朝（5:30起きからの8:00現着）

某イベントでとんでもない待機列を経験しているのでため息つきながら向かってみると、
列形成すらなく近くの広場で待たされること50分。
8:50から入場で事前に購入リスト書いて9:10分くらいで列並べた。

購入リストがそのまま注文用紙になってるから、用紙渡して取ってきてもらうスタンス。
拍子抜けするくらいあっさり買えて良い運営だなぁと思いながら。

外出たら人人人！！！
会場間違えた？ってくらいの人！！！！！

サブアリ展示も飲食も諦めてすぐアリーナへ...

ゲームイベントは座ってわちゃわちゃでずっと笑って見れて楽しかった。
フォールガイズでしっぽ取られて体育館裏に呼び出されてギスってたのいつも通りすぎて面白かった

楽しみにしてたライブ！
SS席 アリーナA1 17列19席
A2が中央なんだけど、19席はほぼ中央だったからめっちゃいい席。

この為に謎の逆張りでアルバム一切聴かなかった。
ライブで初見の方が直感で好きになれるからね。

以下セトリと感想。

・DIAMOND in the ROUGH　DAY1メンバー
今回の全体曲。
盛り上がっていい曲～～！！

・たまには夢のえすけぃぷ　花芽すみれ
初手すみーでびっくり
かわいい

・オドループ　一ノ瀬うるは× 千燈ゆうひ
なんかへ、いせい
色々懐かしい動きだったｗ

・なずなぞわんだぁ～らんど　花芽なずな
なずちゃん可愛かった

・パンダヒーロー　橘ひなの×藍沢エマ
たしかどこかで聴いたことあったよね？
ひなーのの高音たかすぎ～

〜MC〜　花芽すみれ×花芽なずな×一ノ瀬うるは
ぐだぐだMCで後続も安心ｗ
これぞぶいすぽ

・ゆらゆらサマー　白波らむね
会場内で一生流れててお気に入りになってた曲
サビの最後が楽しくて好き

・毒占欲　八雲べに×如月れん
セクシー＆かっこいい、良い

・Sunset Explorer 千燈ゆうひ
うひ～～！！！いい曲やないかい！！
大分好き曲

・Deep in Abyss 白波らむね×花芽なずな
アビスアニメ追いついてたからすんごい胸が苦しかった
いい曲～

〜MC〜　神成きゅぴ×白波らむね× 千燈ゆうひ
きゅぴの盛り上げ方が良かった

・Thunderbolt 神成きゅぴ
かっこよい

・ねぇねぇねぇ。一ノ瀬うるは×橘ひなの
なんだよ、かわいいじゃねぇか...ってなった

・Temptation 八雲べに
思ったよりセクシーじゃない？感じだった。よかった

・打上花火　紫宮るな×如月れん
一生れんくんにメロついてたら、左側にメロつく一般ファンガがいて笑ったｗ
しのみやぶれなさすぎるｗ

〜MC〜 八雲べに×一ノ瀬うるは×紫宮るな
うるはさんとるなちゃん一生喧嘩してて笑ったｗ

・大♡大♡大♡大好き　橘ひなの
めっちゃ平成だなぁ？！ってなったｗ

・超最強　神成きゅぴ×藍沢エマ
（記憶があいまいな箇所）

・あのね　紫宮るな
無限に可愛かったのだけ覚えてる

・怪物　千燈ゆうひ×白波らむね
声が合っててよかった

〜MC〜　如月れん×橘ひなの×藍沢エマ
なんかてぇてぇかった

・Ever Blue 一ノ瀬うるは
うるはさん！！！かっこいいやんけぇ...

・動く、動く　花芽すみれ×紫宮るな
動く🎶動く🎶
かわいいなこの二人

・Slow Bloom 如月れん
一生メロついてた。かっこよすぎるだろ
この辺りからちょっと涙腺に来ていた。
（れんくん大変だった話聞くからね...）

・花になって　神成きゅぴ×八雲べに
この二人いいね、よかった

・藍染の空　藍沢エマ
めっちゃ良かったこの曲、えまたその声良い...
結構泣いてた

・だから僕は音楽を辞めた　花芽姉妹
色んな考察で頭爆発しますが？？
この曲好きだし胸がきゅっとなった...
めっちゃ泣いてた

〜MC〜　花芽姉妹
反則級のMC
すみーテンション低い時点で泣くの我慢してるなぁって思ったけど、
泣き出した時につられてもっと泣いた。
浅いファンでもこんなに泣けるのに初期のころからの人たちはもう膝から崩れ落ちるだろ...

・for Victory DAY1メンバー
もっともっと泣いた
いい曲やぁ...

と、大分しんみりDAY1だった。
こういう感動がいいんだよ。

DAY2

DAY1とほぼ同じ時間に起きて現地へ

DAY0, 1とめっちゃ込んでたサブアリ、会場後即ならんでさっと入れて本当によかった。

衣装展示良すぎ～！！
どれも出来が良すぎる！！

れんくんの服、意外とねこの要素あってかわいいギャップ良い

しらたまもいた。かわいい

あかりんのQRコードはちゃんと公式に飛ぶ

つむぎちゃんのスニーカー良すぎる欲しい。
こういう系の靴しか足に合わないから余計に欲しい。
是非に。

スマホなあたりJKか！
ガラケーじゃないんかい！ってなった

メンバーのイラスト展
ちゅなとくろむちゃん上手すぎ
もかさーんは...味しかない絵だなぁ...
プロローグで考察が捗るって聞いたけど、たしかに...

宝石モチーフのメンバー手作り石鹸
個性豊かで良い
（石鹸づくり楽しそう・・・）

ぬいもいます

さて今日もゲームイベ！
すみーの特大トロールとアリヤのエペが印象に残っている。

なんかゲームの感想薄いように見えてちゃんと記憶に残ってる。
ただ書きにくいんよなぁ、ｗ

終わって少し時間あったから隙を見てドリンク購入！
がちうまでした

さてライブ。
SS席 アリーナA0 7列7席
A0ってどこやねん！！って思ったら色々あって緊急増設されたブロックだった。
左端だったけど7列ってだけあってほぼ最前列。迫力がすごくて十分いい席。

DAY2はさすがに泣く予定ないですわ～

以下セトリと感想。

・DIAMOND in the ROUGH　DAY2メンバー
一生あかりんに向かってペンラ振ってた
何度聴いても良いこの曲

・君のいちばんになりたい　胡桃のあ
初手ですかぁ？！
王道アイドル曲、よい

・だいしきゅーだいしゅき　小森めと×夢野あかり
あかりんかわいいね・・・
めっさんさすがだったｗ

・ラビラビュ　兎咲ミミ
これも会場に沢山流れてて好きになってた曲
楽しい。たやかわいい
　
・フタリボシ　紡木こかげ×甘結もか
さわやかしっとりでおしゃれだった
この組合わせいいね

〜MC〜　小雀とと×兎咲ミミ×胡桃のあ
ゆるふわでかわいかった

・君がくれた羽　小雀とと
ととち～～
いい曲

・UNDEAD 猫汰つな×夢野あかり
2人ともかっこいいやん！！

・ひとくちの魔法　紡木こかげ
ね～お腹すいたね～って完全保護者気分になった

・いーあーるふぁんくらぶ　蝶結び
知ってる曲ってテンション上がるよね！

〜MC〜 小森めと×紡木こかげ×夜乃くろむ
ひねもす・・・？なんか違うぞｗ

・Ready set glow 夜乃くろむ
歌になると突然かっこいいうみんぐさん
かっこよすぎるだろ。

・D/N/A 空澄セナ×小雀とと
（あまり記憶がない）
難しい曲だなぁって思いながら聴いてた

・Everyday Party Time! 小森めと
めと！めと！コーレス楽しかった
　
・愛包ダンスホール　胡桃のあ× 猫汰つな
のあつな良すぎる

〜MC〜　夢野あかり×小雀とと×蝶屋はなび
お世話になっております～ってあかりんの挨拶おもろすぎなｗ

・蝶影繚乱　蝶屋はなび
フェス通しで見てもこれが一番楽しかった

・コネクト　兎咲ミミ×紡木こかげ
アビスと同じ気持ち。なんで胸苦しい曲選ぶん？ｗ
良い歌声でした。

・ビッグドリーマー　夢野あかり
あかりん～～～～～～！！！！
最初少しだけ会場で聞こえた時、某mkさんを感じる電波感で死ぬほど不安だった。
ちゃんといい曲ですやん・・・

・ロキ　空澄セナ×夜乃くろむ
ロキは楽しい！！かっこいい2人

〜MC〜　猫汰つな×空澄セナ×甘結もか
色々楽しい組み合わせだった

・適材適所ワンモアトライ！猫汰つな
ちゅな～！
ノリノリで楽しかった

・くりてぃかるぷりちー　兎咲ミミ×小森めと
一生みみたやかわいいしてた

・Next Page 甘結もか
もかさーん歌もいいですやん...

・RE:I AM 夜乃くろむ×小雀とと
いい曲だしいい歌い方だなぁ...
この曲どっかで...っておもったらユニコーンの曲だった。気づかんかった

・Momentary Light 空澄セナ
あしゅみ...
あれ？なんで泣いてるんだろう...
頑張ろうって思えるいい曲だった。これ好き

・ヒカリ証明論　蝶屋はなび×胡桃のあ
超しっとりの後にアゲ曲、風邪ひく

〜MC〜　胡桃のあ×兎咲ミミ
次の曲のコーレス練習ありがて～

・for Victory　DAY2メンバー
やっぱfor Victoryなんだよなぁ
サビを全員で手拍子しながらの合唱はずっと記憶に残るいい時間だった

DAY2は楽しいメインって感じ。
ゲームもライブも盛り上がってすごく良かった。

その他

全日あった等身大アクスタ
プロローグは全員統一衣装

DAY1, DAY2はそれぞれゲームイベ参加の人はジャケット衣装に。

リサちゃんはライブに出れなかったから、統一衣装版はプロローグだけの限定
いつか生歌聴かせてくれよな

想像を大きく超える良いFESだった。
本当に楽しかった。

また2年後くらいに開いてほしい。

JMS(Japan Mobility Show 2025)で見かけたとある透過ディスプレイ。
その詳細とメリデメ、制御方法等、詳しく掘り下げて考える会です。

JMSのレポートはこちら↓
https://irukanonedoko.com/japanmobilityshow2025-report

！お断り！
やっぱりEthernetだわってなってLEDビジョンの制御方法をこっちで考えてます。
https://irukanonedoko.com/consider_ledvision_control/

映像から見てみる

まずは会場で撮影した動画を見て考えていこう。

何といっても特徴的な完全透過。
と言っても、柱やLEDの光があるため完全な透明とは言えない。

通常のディスプレイより奥行きを強く感じる。
光っている箇所と光っていない箇所が背景の見えやすさで表現されるため、
より光っている箇所が目立ち奥行きを感じるのかもしれない。

機材ははっきり見えてしまうものの、空中に映像が表示されているように見えるため、
近未来的なインパクトがある。

反対に、ちゃんとした映像だと全体的に薄く見え、
また本来見せたくないだろう背景も映ってしまいノイズになっている。

表現的メリデメ

表現に対して感じたメリット・デメリット

【メリット】

• 背景透過のインパクトにより注目度が上がる
• 明暗による立体的な表現ができる

【デメリット】

• 黒が表現できない（黒 = LED offのため背景が映ってしまう）
• 背景が映り込むため映像全体にノイズが入る（背景 = 本来映像として見せる予定のない情報という意味のノイズ）

構造・制御方法

まず表面から。
LEDが並んでいるが、縦方向に間隔が空いている。
この間隔のおかげで透過が成り立っているよう。

小さめといってもディスプレイのLEDとして考えればかなり大き目なLED。

後ろから見るとこんな感じ。
40~50cm程度のブロックを1単位に、
複数のブロックを組み合わせて構成されているよう。
ここは通常の大型ビジョンと同様。

ディスプレイの後ろ側にはライトがあった。
ディスプレイ単体の光量は各LEDの間隔分下がってしまうため、
それを補うためのライトと思われる。

別のブースにも同様のディスプレイがあり、後ろ側に制御装置が見えた。
おそらくNovastar社のVX16sビデオコントローラと思われる。
https://www.novaprocessors.com/product-page/vx16

出力はメインがEthernet、モニター用でHDMIもサポート。
Ethernetでの大量LED制御と言えばArtnet。

すると考えられる制御方法は以下あたりだろう。

• Artnetを使用したDMX制御
  → ユニバース設定やデータ送信が大変そう？
• Monitor出力のHDMIを利用
  → ディスプレイがHDMIに対応するのか？

コスト考察

特に調べたわけではないためあくまで想像になるが...

先ほどのサイズが大体 200cm * 600cm と仮定して 約250インチ。

大き目(60インチ程)のモニターでも10万円を超えることを考えると、
LEDビジョンで行った場合は数十万後半 ~ 百万円台までかかりそう。

対してこのディスプレイは大きさの割にLED密度が小さい。
各LED間15mm程度の隙間と考えると、大体42インチ相当に当たる。
そう考えると大きさはあるものの、通常のモニターより遥かに安価なのかもしれない。

ここまでのまとめ

ここまでの見た限りの考察をまとめると、

• なかなか見ない透過ディスプレイ自体のインパクトが大きい
• 通常ディスプレイとは違った映像効果を狙える
• 通常ディスプレイより安価と推察される

と言ったように
珍しくて近未来的でおしゃれな上安価
というメリットがかなり大きい設備に感じる。

調べてみた

ここまでは見て感じたことからの考察だったが、
ちゃんと調べてみた。

正式名称

なんと既にあった。（しかも5年以上前からある...）
https://yamato-signage.com/transmissive-led-vision-features-benefits-and-effective-use/

透過LEDビジョンまたはシースルーLEDディスプレイと呼ばれるらしい。

これとか
https://www.cima-net.co.jp/sp-contents/14954

これとか
https://www.nisshintoaiwao.co.jp/materials/digital_signage/led.html

これとか
https://seibidou.jp/sledvision/products/sled_transparent/

思った以上に出てくる。
形状の自在さも強みっぽく特殊な形状でも低価格で提供している感じ。

コスト調査

LEDビジョンは以下の企業を参考にしてみる。
https://gloval-stage.com/
250インチ5日レンタルで約90万円

透過LEDビジョンは以下の企業を参考にしてみる。
https://www.cima-net.co.jp/sp-contents/14954
1パネル1000*500mm 5日レンタルで約6.6万円
これを2000*6000mmに換算すると約160万円（計算合ってるか？）

もちろん企業や要件によるため単純比較にはならないが、
コストは下がると思ったら2倍くらい高くなるみたい。

制御方法調査

会場で見たVX16sは透過関係なく、LEDビジョンのビデオコントローラとして採用されているみたい。
https://www.cima-net.co.jp/rental/led-display/ledcontroller/15163
https://www.arkbell.co.jp/equipment/vx16s/

概念的にはLEDビジョンと変わらないことを考えると、
透過LEDビジョンもHDMIと考えるのが妥当。

よっぽど特殊な形状以外はHDMIなんじゃないかなぁ。
（前使ったことある大型LEDビジョンがHDMIだったことを根拠にしてるけど、本当のところは謎）

その他用途

ちらっと書いたが、LEDビジョンと比べ形状のカスタマイズ性が高く、
オーダーを出せる企業もちらほらある。
特殊な形状に対応しやすいのはかなり長所な気がする。

また単純な映像表示とは別で、装飾としての用途にも使える。
少し違うが、お台場の階段とかこんな感じのLEDがあった記憶がある。

調べた感想まとめ

思ったより前から使われてたし、思い返せば色んな所で見かける一般的な技術だった。

思っていたよりコストが高いため
展示会等でも一定以上の規模を超えないと採用率が低下するのかもしれない。

初見ではArtnetや複雑な制御方法かと思っていたが、
純粋にLEDビジョンのピッチ広めverと考えるとHDMIに落ち着いた。
ここは作業コスト削減の意図もありそうだけど、
複雑な形状だとどうするんだろうって疑問は残る。

なんだこれは？！と思って調べてみて実は一般的だった、という結果だったが、
こうして身近な疑問に興味を持ち調べるのは楽しく、知見も広がり良い収穫だった。

備考

映像関係の人ではなく興味があって調べてるので、
実際の現場とは乖離がある可能性あります。

事象

・11/12 深夜
　寝る前に更新してシャットダウンを実行
　再起動しています...で停滞（30分経っても画面変わらず）
　寝たいので電源ボタン長押しで強制シャットダウン
　もっかい電源ボタン押して起動
　更新進んでるような画面になる
　自動再起動
　...再起動せず。電源ボタン押して起動
　ログオン画面になる（壁紙含めいつもの通り）
　おっけ～と思ってログインせずシャットダウン
　すやすや...

・11/13 夜
　仕事から帰ってきて電源ボタン押して起動
　いつものログオン画面が出てきてログイン
　なぜか初期画面に。
　次いで
　　サインインに失敗しました。サインアウトして再起動すれば直ることがあります。
　というダイアログが表示される。
　従ってサインアウト、再起動する。
　初期画面のログオン画面になる。
　ログインする。
　初期画面のまま。
　なおっとらんやんけ！！！
　設定→アカウント 押しても無反応な ヘルプを表示 のみ。終わった。

修復

取り合えず調べたら回復環境から直りそうと判明。
この際壊れてもいいからやってみることに。（若干メンタル逝っててちょい自暴自棄）

Shift押しながら再起動押す。
F12押しながら待つ。
回復環境に入った。
トラブルシューティング → 詳細オプション → システムの復元

11/12 9:58 のWindowsUpdateイベントが最新イベントとして表示されてる。
どうやらこのイベントより前のシステム状態に戻せるらしい。

一応復元によって消えるデータの確認ができるので実行。
特になし。
じゃあいっかってことで復元開始

～10分くらい待つ～

復旧しました。再起動してください。
というダイアログ。
再起動ボタンがあるのでボタンぽち。

いつものログオン画面ちゃん！！
ログイン
いつものデスクトップちゃん！！

結果：復元できた

後書き

画像0なので役に立ち度激低だけど、記憶力ないからいつか同じ事象が起きた時のために、
回復環境からシステムの復元で直ることもあるってことの実績をメモ。

あと再起動中の電源ボタン長押しもやめようね。危ないね。
でもさぁ！寝たかったんだもんさぁ！（自業自得）

お腹すいたのでこれで終わり。

https://www.japan-mobility-show.com

JapanMobilityShow2025に行ってきました！！
なんだかんだ今でも車に関わる仕事してるのでつい興味が湧いてしまう。

まとめ・感想

恒例の結論を先にシステム。

所謂コンセプトカーやモック品より、既に発表して投入予定の新型が多く、
更にそれらがこれまでモックとされてきたようなデザイン、機能を搭載してて
思っていた以上に市場の進化が進んでいたことを知れた。

近未来的・SF的なデザインがもはや現代のデザインになる日も近いと思うとワクワクする。

全体を通して車椅子や一人用小型車など、一人向け・屋内向けなどの軽移動用の乗物も多く、
車の形そのものの変化もあるのかなと感じた。
（去年を知らないから増加傾向かは分からない）

安価で一人用の移動乗物が今後普及すると生活がもっと豊かになるから、
この取り組みは進んでほしい。
将来に期待！

お仕事的な話で考えると、
そういった一人用乗物のUIや連携装置は今後必ず需要が出るからマークしておいた方がよさそう。
アシストデバイスとか、ARデバイスとか、組合せ次第で色々できそうだし考えてみようかな。

東館: 車体関連

三菱重工

車両を自動で搬送するロボット。
商業施設の駐車場とかに使って、駐車をこのロボットに任せることで手間を減らしつつ駐車効率を高める施策。
帰る時はアプリで車を運んできてもらう仕組み。

既に一部の地域で実証が進んでいるらしい。
普通に便利。

SusHiTech TOKYO

一人用の車。
こういうの50万くらいで売ってくれたらいいよね。
某特殊小型原動機付き自転車よりこっちが普及してくれ。

TIRE IV

自動運転のOSS。
どっかで聞いたことあるんだけど思い出せない（仕事でちらっと聞いたことあるかも？）

https://tier4.jp
https://github.com/autowarefoundation/autoware
...いつか中身見よう()

ナンバープレート

皇居様式なんて存在初めて知った・・・

ナンバープレートも歴史があるって知ると不思議な気持ちになる。
車が出始めた時とか、様式がころころ変わった時って結構カオスだったんだろうな。

色んな県のナンバープレート。
ミャクミャクが可愛く長崎がとてもおしゃん

昔の車展

いっぱいあったけどほぼ分からんかった。
むかしのくるまだ～！くらいのゆんるり感覚で見てた。

SHARP

SHARPの多分コンセプトカー
部屋みたいになるのは面白い。

AGC

日光とか光が強い所でも見やすくするフィルム（Smoke AR Film）
CIDとか全部これ入れてほしいよね。

曲面ディスプレイの特徴として、見る方向によって色が変わってしまう問題があるらしい。（画像下側）
その色の変化を起きなくするようなフィルム。（画像上側：カラーシフトレスコーティング）

上下とも同じ真っ直ぐな物体の上に曲面ディスプレイを置いて、フィルムだけ違う状態。

「色の違いはなくなってますけど、なんかカクカクしてますね」
って説明してくれたお姉さんに言ってみたらなんと7日目にして初指摘だったらしい。
ずっと「たしかに...そうですね...」って呟いてた。相当衝撃的な気づきだったんだろう。。。
（人通り多いとこの展示だったから尚更かもしれない）
また開発の役に立ってしまった。

HINO

poncho dotっていう未来？の多分コンセプトバス。
中は折り畳み式の椅子が両サイドにある。

後ろがガバっと開くので人も物も出入り楽ちん。
自動運転が進むと人輸送の他に物輸送も兼任できる方が強そうって思った。

Mercedes-Benz

いったい何千万すんの？って感じの超高級仕様。とんでもねぇ。
お顔がちょっと残念感あるのは庶民故（だと思う）

とにかく内装がえげつない。

後部座席広すぎる。
リア席ディスプレイは最近の高級車向けでよくあるのは知ってるけど、
こんなでかいのは初めて見た。
しかもDolby対応...パーティー仕様すぎない？

ついでに左側に一切の切れ目が見えない辺り、もしかして右側しか開かないのでは。
歩道側だけ開くってことだと思う。しゅごい。

多分最新モデルのCLA。かっこええ～～～

もちろんコックピットもおしゃん。

Mercedes Benz Operation System(MBOS)を積んだ初めてのモデルらしい。
どう違うのか気になる。

YAMAHA

トライアルバイク。
トライアルっていうバイク乗りながらポーズしたりぴょんぴょんしたり、
かなりアグレッシブな競技？パフォーマンス？があるらしい。
前輪後輪をよく上げる関係でお腹側に見せる用のプレートが付いてる。
なんてえっちなこだわりなんだ・・・

どう乗るのかまったく分からなかった。絶妙なフォルムしてる。

水素エンジンの2輪。
正直水素関連はあんまり信じてないんだけど、結構真面目に進めてるのね。
水素タンクってエナドリ見たいな形してるんだってことを知れた。

何かの記念バイクっぽい？かっこいい。

車いす。
未だ不便に見える車椅子に手掛けるのは好印象。
便利になるといいね。

操作デバイスは不思議な感じ。
ターゲット年齢が高齢なのか、ずいぶん簡単なインターフェース。
将来この辺りに需要が出るかもしれない。

SUZUKI

謎の4足移動型。
な、何用なんだ・・・

HONDA

コンセプトカーにしか見えない本当に発売されるHONDA 0シリーズ。
内装もすごく近未来的。
こういうコンセプトカーは沢山見てきたけど、実際に発売するってすごいよね。

個人的にはSUVタイプが好み。スマートなお顔がかっこいい。

移動用の乗物。障害を持つ方向けかと思いきや、一般人向け。
車椅子ではなく、歩く代わりにこれ乗って楽に移動しようってコンセプトの乗物。
ほ、ほしい！！

スマホをセットして車体操作可能。
といいつつ昇降程度で、運転は体重移動だから直感的。

まだ実用化に至ってないらしいけど、こういうの普及して欲しい反面、足がどんどん退化しそう。
とはいえ商業施設とかで皆これ乗って周る未来は見てみたい。

プレリュードもいた。
カタログで見るよりかっこいい...気もする。

Acura RSX Prototype 北米市販予定の新型。
内装見えなかったけど外装いい感じ。国内はありますか？

ロケット！足元しっかり見えるの珍しいのでぱしゃり。

MicroEV。1~2人用の小型車。かわいい。
ハンドルの真ん中にスマホ置けそう。自動運転想定かも？

船にジェット。HONDAなんでもやってんな笑

西館: モビリティ・部品関連

SCSK

今回一番見たかったSCSK Car。
SIerが車作ったらどうなるの？ってコンセプトカー。
なんと、実際に走れる。（公道は申請降りてないけど、敷地内なら十分走れるレベル）

CIDはクラスターと完全一体のディスプレイ。
真ん中の青いのは謎。
後部座席は安定のディスプレイ付き。

結構ぬるぬる動く。Androidだけど強めのSoC使ってるからかな。
上から下にスライドすると、スライドした位置からメニューが出てくる。
よく実装したなぁ...って感じ（動画撮り忘れた）

最初車作ったって聞いた時、何言ってんだぁ？って噛みつきに行こうと思ってたんだけど、
説明聞いてると外装や車体本体には力入れる気なくて、あくまで内装メインの提案を行っていくために作ったらしい。
確かに今後自動運転が進むにつれ内装の高級化や需要が増えるから、
それを見据えて実際に動く内装コンセプトを作ってるなら納得。いい施策だね。
（こういうコンセプトカーでおもちゃ大量に見てきたから、ちゃんと作ってあるのすごく印象がいい）

三菱

新型。ディスプレイ遠くね？

BMW

多分新型。ところでシフトレバーどこですか？
トグルスイッチ式のシフトチェンジ怖～。
他の展示車の一部が同じタイプだったからBMWはよく採用してるのかな。

MINI

円形ディスプレイ。

がちゃがちゃしてきた。
正直触りずらいし、円形の四象限がどの操作かって直感できるわけないからただただ触りにくい。
温度のUIはスライドすると操作方向側が大きくなるから、
下から上になぞった時に、下を触ってるはずなのに上が大きくなって気持ち悪かった。

番外：透過ディスプレイ

展示には全く関係ないけど、完全透過型ディスプレイがあった。
な、なんだこりは・・・！！！とても革新的じゃないかっ！！

見た感じはDMX。少なくともHDMIではない。
大型ディスプレイってすごい高いし重いし設置大変だしデータ量多いしで高コストだけど、
この方式なら安価で且つおしゃれだからすごくいいアイディア。
これは制御方法を紐解きたい・・・

別のとこにも同じのがいくつかあって、内一つの裏側が見えたので撮影。
NOVASTAR VX16Sっぽい。
Ethernetでディスプレイと接続だからArtNetだと思うけどどうだろうなぁ。

ベンチャーエリア

SmartMat Cloud

下に敷いてあるのが該当IoTデバイス。
これで重さ測ってサーバに送信、Web画面で在庫数の管理ができるシステム。

これあれば大抵の在庫管理が楽にできるじゃんって思ったけど、
1つあたりの重量でキャリブレーションするはずだからネジとか軽量すぎるものには使えなさそうだし、
単純にデバイス単価が高そうだねって連れと話してた。

工場でネジがなくなったからアンドン引くとかよくあるからね～
こういうので管理できたらいいのにね。

CUEBUS 自動物流道路

パレットが動くのではなく、道路を制御しちゃおうってやつ。
小さい四角の所が電磁石になってるんじゃないかな。

保守性やコスト面ではパレットに劣るけど、収納効率は高そう。
あと事故率低そう。

DUNLOP

自動車タイヤ国産第一号（のレプリカ）
珍しかったのでぱしゃり。
意外と細かったのね。

BRIDGESTONE

エアレスタイヤ。
ホイール側で衝撃吸収してタイヤに空気を入れないってタイプ。
そんなのあるんすね～

世界最大級のタイヤ。でかすぎんだろ。
鉱山用の重機につくらしい。でかすぎんだろ。

Tokyo Feture Tour 2035

もっと未来へGOって感じの展示。

小型の運ぶ車がお出迎え。かわいい。
一家に一台の時代になったらいいね。こぼしたら大変そうだけど。

SKYDRIVE　電力駆動型のヘリ。
車体持ち上がるレベルのトルクが出る小型モータがプロペラ部分にあるってこと？

MOBILARIA　瞬足のもっとバネな靴。
履いてみたい。

進化版車椅子？
こういう支援車が全体的に増えてていい傾向だね。
健康な人も楽して移動できる未来がいい。

芝刈り機。今日も元気に草刈りしてた。
ハウステンボスにいるらしい。これを見に行くって名目で行きたい（）

コライドンとミライドン。
乗りたかったが整理券がなく断念。

コライドンは瞬きもしてて可愛かった。

コライドンはHONDA、ミライドンはTOYOTAが作ったってマークが乗り口にあった。
こういう主張好き。

このエリアにいくつかあったAIナビゲーター（デザイナー？）
といいつつ普通のチャットボット＋絵

他の人が会話してたけど特に革新的でもなかったのでスルー。

南館: 高級車・Kids関連

TOYOTA

AIガーディアン・・・？
子供幽閉装置にしか見えないんだけどこれいつどこで使うやつなんだろう。
かわいいはかわいい。

座ってる。かわいい。四脚型の動く椅子。
単体だと大分怖い。

新型カローラ。言われないとカローラだと分からない。

内装は若干見えてこんな感じ。
CIDがなくなってクラスターに集約、助手席が補助モニターって感じかな？
真ん中の机っぽいところのインターフェースが気になる。

LEXUS

一人用の自走車・・・かな？
皇帝感が高まりそう。

シンプルにかっこいい。

内装がとにかくおしゃれ。
自動運転の先は車室空間を部屋と見立てた快適空間なのかなって感じの木目調。
考えてみれば採用率少ない割に一気に部屋感出るからいいかもね。

コックピットがはちゃめちゃにかっこいい。実用的かは謎。
2層になってるけど裏側はどう操作するんだろう...
左右にも広がってるのは操作しやすそうだけどね。触ってみたい。

ぴかぴかしてておしゃん。

ハイエースの新型らしい。
すごい高級ホテル感。これで送迎されたい人生だった。

もしかして下に光が出てる？かっこよい。

これまたかっこいい。スポーツフォルムかっこいいね。
多分2人用かな？

これから本当に流行るんですか？って感じのクラスター。
これまたCIDレス。

曲面ディスプレイおしゃれだけど無駄な領域もありそうでなんだかなぁという感じ。
動きを見たいので触らせて下さい。

DAIHATSU

1人用車。
かわいい～欲しい～～

おまけ

再びYAMAHAへ、そこには・・・

一通り周った後、連れの知り合いに会うためにもう一度YAMAHAへ。
そしたら聴きなれた歌声が・・・

ミク！ミクじゃないか！！

さらにバイクトライアルまで！！かっこよい～！
バイクのお腹側見せるのえっちすぎる。

そしてラストパート
私の大大大好きなTell Your Worldのブラスバンド版
ミク・・・；；

嬉しさと普通に演出良くてひっそり泣いてた。とてもえがった。。。

真後ろにエンジンふかす体験できる展示あったんだけど少しは空気読めやってキレてはいた。
真正面のSUZUKIのステージはこれ終わった直後に始めてたんだし見習え。
（↑仕方ないし何も言えないんだけどね。内心ね。）

YAMAHAさん、ありがとう・・・

さらにおまけ。JMSの後に食べるものと言えば・・・

知ってた。
ラーメン二郎 松戸駅前店。

いつも通り小ラーメン ヤサイニンニクアブラ

微乳化で私の好きなタイプの二郎の味。
上に乗ってるのはとろっとろのほぐし豚。
これだけでも十分な豚量なのに中に2枚いる。

ストレートで太目なもっちり麺が微乳化とマッチしていておいしかった。

珍しい先買いタイプなので並ぶ時に若干グタったのは反省。
あと量が多く2日連続だったとはいえ結構きつかった。
でも超美味しかったので満足。

来年もJMS行きたいな～！

今までUnityやら組み込みやら比較的フロントエンドに近い開発を行ってきた私。

突如「簡単なAWS連携するバックエンドシステムの開発してくれない？」と。
いうて今までも未経験領域ばっかりだったし、いけるやろ！と思い、
「いいですよ！やってみますね～！」
そう答えた。

これが悪夢の始まりと知らずに─

リポジトリ

今回の説明用に作成したサンプル。
https://github.com/shinyshinpy/backend_sample

取り扱い内容

前段の茶番は置いておいて。

まじで安請け合いしてがっつりバックエンドにぼっこぼこにされてトラウマになったので
どんな構成で、どう組んだのかをまとめようと思います。

• バックエンド初学者
• フロントいけたしバックエンドいけるやろ！と考えた人
• バックエンドってどう作るんか分からん

↑こんな人にピッタリな記事になると思うので、よかったら読んでくださいね～
トラウマを追体験しましょう！

※ AWSは今回は触れません。

構成

構成はこんな感じ

デバイスからデータが飛んできて、それをDBに保存。
外部からAPIでそのデータを吸い上げ。

”簡単”そうですね！
（実際簡単なシステムではある）

開発環境

ここからが本題。
python書いてSQL書くくらいなら簡単ですわ～

え？環境ごとノーヒントで作れ...？

ということで後任とか保守性とか分からないなりに考えた結果、
以下の環境で作ることに。
（会社なんだからサポートつけてくれ～～）

• WSL2
  • Windows上でLinux使えて開発に便利！
• devcontainer
  • 開発環境そのものがリポジトリに保存できて人依存の問題が減って便利！
  • VSCode上でしか使えない？けど開発環境統一できて便利！
  • 依存性の他、拡張機能もコンテナ毎に設定できて環境ずれが起きなくて便利！
• docker compose
  • よく分からんがビルドする時に便利！
  • ビルドイメージとかビルド方法とか、ビルド関連の設定が色々できて便利！

一応VirtualBox上のUbuntuでDocker使ったことはあるが、
当然開発環境が出来上がった上で実装書いてたもので...

バックエンド開発ってみんな環境ごと作るの？すごいね...

事前準備

色々準備します。

WSL

WSLはWSL2です。
Linux用Windowsサブシステムを有効化して

ターミナルで wsl --install って打つだけです。

具体的な方法はいくらでも載ってるので適当に調べてください。

dockerの準備

本当はDockerDesktopを使う方が楽らしいんですけど、これ商用利用ライセンスが必要なんですよね。
大体の記事は皆個人開発なので↑使ってるんですけど、商用使えないの、困りますよねぇ...

ということで無償のDockerEngineを使います。

基本的には公式の手順に従ってコマンド打っていくだけです。
https://matsuand.github.io/docs.docker.jp.onthefly/engine/install/ubuntu

よっぽどリポジトリからのインストールで問題ないと思います。

$  sudo apt-get update
$  sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o 
/usr/share/keyrings/docker-archive-keyring.gpg

$ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

docker -v でバージョンが出ればOKです。

環境構築

さて構築していきましょう。

作業フォルダに入る

まずWSLに入ります。

入れたら作業フォルダを選びます。

こうなっていればOK

devcontainerに入る

次にdevcontainerの準備をします。

ホスト側（Windows側）でもよいので以下の拡張機能を入れます。

Shit+Ctrl+Pでコマンドを開きます。

開発コンテナー：開発コンテナー構成ファイルを追加　を選択

今回はpythonで開発する環境が欲しいので、
pythonと入力して一番シンプルな python3 を選択。

pythonのバージョンはお好みで。今回は既定の3.12
実務ではpythonバージョンによって仕様が変わるので、関係者と相談して決めよう！（一敗）

今回はmysql使うことが確定しているのでこのタイミングで追加。

こうなればOK

この時点でdevcontainerの環境を作ることはできましたが、まだコンテナに入ってません。
左下の><に入っている環境が表示されています。
devcontainerに入ると、ここがコンテナ名になります。
今はWSLなので、まだWSL上でフォルダを開いているだけ、という状態です。

もう一度 Ctrl+Shit+P でコマンドを開き、
コンテナーでリビルドして再度開く を選択します。

[981117 ms] Start: Run in Host: docker version --format {{json .}}
[981208 ms] {"Client":{"Platform":{"Name":"Docker Engine - Community"},"Version":"28.3.3","ApiVersion":"1.51","DefaultAPIVersion":"1.51","GitCommit":"980b856","GoVersion":"go1.24.5","Os":"linux","Arch":"amd64","BuildTime":"Fri Jul 25 11:34:04 2025","Context":"default"},"Server":null}
[981209 ms] Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

[981210 ms] Exit code 1

$ sudo service docker status
 * Docker is not running

$ sudo service docker start
 * Starting Docker: docker                                                                                                                   [ OK ] 

こうなっていればOK
コンテナ名は .devcontainer.json の name に書かれている名前。

devcontainer設定

devcontainerは開く度に環境がリセットされます。

なのでこの状態でいつも通りタブから拡張機能入れたり、pip installしたりしても、
次開いたらそれらがなかったことになります。

しかも手動でやっちゃったら開く人によって環境変わっちゃうので
devcontainerの環境統一の恩恵が受けれません。

それら必要なものは全て .devcontainer.json に書くことで、
コンテナを開いた時（入った時）に自動的に全てインストールしてくれます。

{
	"name": "Python 3",

	"image": "mcr.microsoft.com/devcontainers/python:1-3.12-bullseye",
	"features": {
		"ghcr.io/devcontainers-extra/features/mysql-homebrew:1": { }
	},
	"customizations": {
		"vscode": {
			"extensions": [
				"ms-python.python",
				"VisualStudioExptTeam.vscodeintellicode",
				"mhutchie.git-graph",
				"ms-python.black-formatter"
			]
		}
	},
	"postCreateCommand": "apt-get update && (apt-get install -y docker-ce-cli || apt-get install -y docker.io); pip install --no-cache-dir -r .devcontainer/requirements.txt"
}

fastapi
uvicorn
sqlalchemy
pymysql
pytest
numpy
freezegun
black

詳しく見ていきます。

拡張機能の設定

	"customizations": {
		"vscode": {
			"extensions": [
				"ms-python.python",
				"VisualStudioExptTeam.vscodeintellicode",
				"mhutchie.git-graph",
				"ms-python.black-formatter"
			]
		}
	},

extensionsの中には拡張機能IDを記載します。

欲しい拡張機能を右クリックして 拡張機能IDのコピー を押して、
jsonに貼り付けるだけです。

依存系の設定

pip installとかで入れる必要があるものを全て requirements.txt 内に記載します。
（ファイル名は自由です）

fastapi
uvicorn
sqlalchemy
pymysql
pytest
numpy
freezegun
black

これでdevcontainerを開いた時点で、コンテナ内にインストールさせることができます。

後述する個別のコンテナにも同様にインストールさせる必要があるので、
このようにファイルにまとめておくと便利です。

バージョン指定なども fastapi==0.45.0 など、通常のpip installと同様の記法が使えます。
未記載なら最新版が入ります。

インストール設定

前述のrequirements.txtに加え、開発環境自体に必要なライブラリを入れます。

"postCreateCommand": "apt-get update && (apt-get install -y docker-ce-cli || apt-get install -y docker.io); pip install --no-cache-dir -r .devcontainer/requirements.txt"

postCreateCommandを使用することで、引数のコマンドを実行されることができます。
ここでは、以下のことを行っています。

• dockerEngineに必要な docker-ce-cliとdocker.ioの明示的なインストール
• requirements.txt のインストール

本来、一つ目のものは不要のはずですが、
まれにdocker-ce-cliが無くてビルドできない、という状態に陥るので明示的に入れてます。（一敗）

インストール確認

構成(json)を変更したらリビルドして開き直しましょう。
ターミナルにログが残るので、正常に入ったかはターミナルを監視して確認しましょう。

Dockerコンテナ作成

ここまででdevcontainer上での開発環境構築が完了しました。

さて！開発するぞ～！

...

ど こ に ど う や っ て ？？

ここに直接pythonファイル置いて動かすこともできるんですけど、
冒頭に示した構成をどう実現するのか？ってところが本題なんですよね。
（なのにその辺の記事がほとんどないという）

コンテナ作り

Dockerコンテナとして、アプリサービス用コンテナ、DB用コンテナの2種類に分けて開発することとします。

その際に、Dockerコマンドを使ってコンテナを立てるのではなく、
DockerFileに構成を記載し、docker composeコマンドで立てます。

こうすることで、コンテナの構成やビルドも統一することができ、
保守性が大きく向上します。

wikiとかreadmeにコマンド手順書けばよくね？

ありがちなんですけど、こんな風に思うと思います。
　docker composeいる？
　Dockerコマンド使って個々に作ってもらう方が速くね？

まぁ大体記載されたコマンドは間違っていたり、環境依存なことが大きいことが大半です。
つまり、

書いてある通りにやってもコンテナできなくて開発できない！！！！

って声が”自分以外の人から”やってきます。
困りますねぇ～

docker composeならコンテナ作りが1つのコマンドで済み、
更にどんな構成でコンテナ作ったかがファイルにまとまっているので管理しやすいです。

構成が変更されても、git管理するのでいつだれが変えたか分かるので保守しやすいです。

そんな訳で、docker composeで構成する方が良いです。
（ただ記事あんまりないので一人でやるの大分むずかしいです。）

コンテナ構成

docker-compose.ymlにコンテナ情報を記載
Dockerfileにビルド情報を記載

docker-compose.ymlをdevcontainer.jsonから呼び出すようにすれば
開いた時にコンテナ作成、マウントなどをやってくれる。

（始めたばかりすぎて合ってるかは不明...）

docker-compose.yml

services:
  mysql:
    image: mysql:8.4
    container_name: mysql_container
    environment:
      - MYSQL_ROOT_PASSWORD=root_password
      - MYSQL_DATABASE=my_database
      - MYSQL_USER=user
      - MYSQL_PASSWORD=user_password
    ports:
      - "3306:3306"
    volumes:
      - ./database:/docker-entrypoint-initdb.d
      - mysql_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      timeout: 20s
      retries: 10

  app:
    container_name: app_container
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: mysql_pymysql://user.user_password@mysql_container/my_database
    depends_on:
      mysql:
        condition: service_healthy
    build:
      context: ../
      dockerfile: .devcontainer/Dockerfile
    volumes:
      - ../:/app

volumes:
  mysql_data:

順番に見ていく

  mysql:
    image: mysql:8.4
    container_name: mysql_container
    environment:
      - MYSQL_ROOT_PASSWORD=root_password
      - MYSQL_DATABASE=my_database
      - MYSQL_USER=user
      - MYSQL_PASSWORD=user_password
    ports:
      - "3306:3306"
    volumes:
      - ./database:/docker-entrypoint-initdb.d
      - mysql_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      timeout: 20s
      retries: 10

image: mysql 8.4を使用する。
mysql_container内にmysql8.4のイメージを展開するという意味。

environment: 環境変数。
ユーザーとかパスワードとかはここ以外でも設定できる。

volumes: マウント設定
一行目の./databaseにinit.sqlやら.envやら構成に必要なファイルを入れておく。
docker-entrypoint-initdb.dは魔法の言葉。ここにsqlとか置くと起動時に勝手にテーブル作ってくれる。
※ 既にテーブルがあると作成してくれないため、再作成時は削除してから。

healthcheck: ヘルスチェック
なくてもいいがあった方が良いやつ。
pingが通ればコンテナが作成されたことを示す。

  app:
    container_name: app_container
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: mysql_pymysql://user.user_password@mysql_container/my_database
    depends_on:
      mysql:
        condition: service_healthy
    build:
      context: ../
      dockerfile: .devcontainer/Dockerfile
    volumes:
      - ../:/app

environment: 環境変数。
使用するDBの依存設定。
デバッグ時などはここをデバッグ用DBに変えるといい。

depends_on: 起動順の設定
mysqlコンテナが健康状態で生成されてからappコンテナを生成する。

build: ビルド設定
context: ルート。.devcontainerに置いているためプロジェクトルートにする。
dockerfile: Dockerfileの在処

volumes: マウント設定
プロジェクトルートから全部appコンテナにマウントさせる
　→ appコンテナ内で作業するための設定

Dockerfile

FROM python:3.12-slim

WORKDIR /app

COPY .devcontainer/requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000

CMD [ "uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000" ]

python3.12-slimというコンテナを使用する。

最後コマンドでuvicornを実行している。
今回の構成がFastAPIを使用する構成のため、ここでサーバーを立ち上げてる。
（構成が違ったらここはなくてもいい）

.devcontainer.json

// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/python
{
	"name": "Python 3",

	"dockerComposeFile": "./docker-compose.yml",
	"service": "app",
	"workspaceFolder": "/app",
	"features": {
		"ghcr.io/devcontainers/features/docker-outside-of-docker:1": {
			"moby": false
		}
	},
	"containerEnv": {
		"COMPOSE_FILE": ".devcontainer/docker-compose.yml"
	},
	"customizations": {
		"vscode": {
			"extensions": [
				"ms-python.python",
				"VisualStudioExptTeam.vscodeintellicode",
				"mhutchie.git-graph",
				"ms-python.black-formatter",
				"ms-azuretools.vscode-docker"
			]
		}
	},
	"postCreateCommand": "apt-get update && (apt-get install -y docker-ce-cli || apt-get install -y docker.io); pip install --no-cache-dir -r .devcontainer/requirements.txt"
}

image: コンテナイメージの設定
Dockerfileで設定するため削除。

dockerComposefile, service, workspaceFolder: appコンテナマウント設定
appじゃなくてもいいはず。
docker-compose.ymlの在処の設定。
imageがない場合はどこにマウントするか記載する必要があるためこれを書く。

features: 追加設定
mysqlは別コンテナにするため削除。
docker-outside-of-dockerでホスト側dockerコマンドの実行権を取得。
（なくても良い）

関連ファイル作成

init.sql: DB初期化テーブル設定
　→ .devcontainer/database/init.sql

CREATE TABLE sample(
    id VARCHAR(10) PRIMARY KEY,
    info VARCHAR(50)
)

今回はサンプル用。
ここに初期化時点で持っておきたいテーブルを記載する。

main.py: fastAPIエントリー
　→ app/main.py

from fastapi import FastAPI


app = FastAPI()

fastAPIを使うため書いてる。使わなかったら不要。
ここにFastAPIのメソッドを書いていくと、URLアクセスでそのメソッドに応じた内容を返せる。

ビルド / 確認

ビルドは docker comopse build もしくはdevcontianerリビルドで可能。

docker compose buildした場合以下のようにビルドできる。
appコンテナにマウントしているため、mysqlコンテナのビルドはできない
mysqlコンテナのビルドは、devcontainerリビルドかホスト側でdocker composeする。

今回はappコンテナをポート8000で開いているため、
localhost:8000にアクセスすれば何かしら開く。
※ fastAPIメソッドの ("/") がないためエラーメッセージが返る。

MySQLテーブルができたか確認。

MySQL workbenchを使う。
https://www.mysql.com/jp/products/workbench

⊕マーク押して追加。
username, passwordをdocker-compose.ymlに書いた内容に合わせて記載
※ 今回は user, user_password

TestConnectionでOKが出るか確認

OKで作成し、開くとテーブルがあることが分かる。

SQL打ったり、DB状態を見たりできるためMySQL使う分には便利。
（ちょっと操作しにくいけど...コマンドよりはこっちの方が好き）

ここまでできれば開発を開始できる。
やったね！

まとめ

え？これバックエンド見たこともない初心者にやらせるんですか？？
フロントに帰りたい。

まぁ～～サンプルがなくて大変困った。
だってどのパラメータがどこに絡んでて中どうなっててとか分かんないんだもん！！！

最初ClaudeCodeに作らせて必要なファイルが何か理解して（当然動かし方分からないから動かない）
一つ一つ調べて理解してってやるの大変だった...

”簡単な”システムなのはコードの方であって、環境構築は難しいど。
車で10分の目的地に連れてって！（車は自作してね）って言われてる気分。
簡単なアプリ作ってね！（Unityとかフレームワークは自作してね）って言われてる気分。
お願いだから環境は知ってる人が作ってくれ～～～初学でやるの辛すぎるよ...

これインフラだろふざけんなって調べたら、環境構築もバックエンドの仕事らしい。
バックエンドの手広すぎだろ。

バックエンドエンジニアが見ればツッコミどころしかないだろうけど、
何も知らん！！！な人の足掛かりになればいいな。
（その前にそんな仕事振られたら逃げてくれって感じ）

バックエンドたのしいね！！！！（白目）

PBR

PS4辺りからトレンドになった技術。

処理能力向上により、Phongの反射モデルでは取り入れられなかった物理的に正しいライティングができるようになった。

以下を満たすことで物理的に正しい処理になる。

• エネルギー保存の法則
  　→ 入射光より強い光を跳ね返さないこと（入射光の一部を吸収し反射する）
• ヘルツホルツの相反性
  　→ 入射方向と射出方向が入れ替わっても射出量が変化しない

Phongの反射モデルはエネルギー保存の法則を満たしていないためPBRではない。

正規化Lambert拡散反射

Lambert拡散反射によるエネルギー総量を積分すると入射エネルギーのπ倍になる。
よってこれではエネルギー保存の法則が満たせない。

Lambert拡散反射の計算結果にπを除算することでエネルギー保存の法則を満たしPBRなライティングになる。
この、πで除算した拡散反射の計算モデルを正規化Lambert拡散反射という。

diffuse /= 3.1415926f;

左が除算前、右が除算後

ディズニーの論文によるPBR

ディズニーの論文(Physically Based Shading at Disney)
https://media.disneyanimation.com/uploads/production/publication_asset/48/asset/s2012_pbs_disney_brdf_notes_v3.pdf

元々ラプンツェルの髪の表現で作ったけど、
服などその他の部分はPBRじゃないから沢山ライティングいるし髪と大幅に反射が違うから不自然だし不便だよねってことで全部PBRのシェーダーが進んでいったらしい。

とにかくこの論文が今のPBRのベースになってるらしい。

パラメーター

物理的なパラメーターを調整することで多くの表現ができることを目的としている。

元が映画制作のためというのもあり、
映像を作成するのに効果的な、1個のカラー情報と10個のパラメーターに絞られた。

割とBlenderのBRDFそのままって感じ。

ゲーム使用のPBRで使われるパラメータ

アルベドカラー

これまで使用していたテクスチャはディフューズテクスチャ。
PBRで使用するテクスチャはアルベドテクスチャ。

違いはライティング結果による陰影が描かれているかどうか。

ディフューズは陰影を描かれているため、そのまま使っても陰影があった。
アルベドは陰影を描いてはいけないため、そのまま使うとのっぺりする。

サーフェイスカラー(baseColor)に該当。

スペキュラーカラー

鏡面反射用のテクスチャ。
アルベドと同義で扱われる。

稀に分かれてる。
その際はアルベドカラーの方にブラーがかかってる。
（拡散反射光は物体内部で拡散して反射するため）

baseColor = サーフェイスカラー = アルベドカラー = スペキュラーカラー と覚えておけばひとまず大丈夫。

メタリック

鏡面反射光の色を物体のカラーか光源のカラーどちらの割合を多くするかの設定。

金属は物体の色を返すが、非金属は光源の色を返すため。

粗さ

物体表面の目に見えない小さな凹凸を表す。

レンダリングエンジンによって粗さ(roughness)、マイクロサーフェイス、滑らかさ(smooth)など名称が変わるが意味は一緒。

※ Unityでは滑らかさ、UE4では粗さ

ワークフロー

使用するエンジンによりPBRのパラメータからテクスチャの作り方まで変わってくる。
PBRだからこう！というわけではなく、エンジンのワークフローに従うことが大事。

実装

ディズニーの論文をベースにした今回独自のPBRを組む。

• 拡散反射: 正規化Lambert拡散反射 + フレネル拡散反射
• 鏡面反射: Cook-Torranceモデル
• ワークフロー: Unityメタリックモード(アルベドカラー、メタリック、滑らかさで表現)

メタリックマップはワークフローの関係でrにメタリック、aに滑らかさが格納されてる

// step-1 各種マップにアクセスするための変数を追加

// アルベドマップ
Texture2D<float4> g_albedo : register(t0);

// 法線マップ
Texture2D<float4> g_normalMap : register(t1);

// メタリックマップ
Texture2D<float4> g_metallicSoothMap : register(t2);

前述の通り、正規化Lambert拡散反射とフレネル拡散反射を求め、それをアルベドに混ぜて拡散反射光とする。
※ フレネル拡散反射の詳細については後述

// step-3 シンプルなディズニーベースの拡散反射を実装する
DirectionalLight light = directionalLight[ligNo];

// フレネル拡散反射を算出
float diffuseFromFresnel = CalcDiffuseFromFresnel(normal, -light.direction, toEye);

// 正規化Lambert拡散反射を算出
float NdotL = saturate(dot(normal, -light.direction));
float3 lambertDiffuse = light.color * NdotL / PI;

// 拡散反射を合成
float diffuse = albedoColor * diffuseFromFresnel * lambertDiffuse;

Cool-Torranceについては詳細を割愛。

メタリックは金属である割合のため、これを利用し金属と非金属それぞれの反射を表現する。
※ specColor = アルベドカラー

• 金属: 色が付く
• 非金属: 色が付かず白っぽくなる

// step-5 Cook-Torranceモデルを利用した鏡面反射率を計算する
float3 spec = CookTorranceSpecular(-light.direction, toEye, normal, smooth) * light.color;
spec *= lerp(float3(1.0f, 1.0f, 1.0f), specColor, metallic);

滑らかさが高いほど拡散反射が弱くなる。

// step-6 滑らかさを使って、拡散反射光と鏡面反射光を合成する
lig += diffuse * (1.0f - smooth) + spec;

PBRと言ってもワークフローでかなり変わるみたい。
今回のだとUEとUnityの中間くらいな印象？

実はUnityBRPもURPもHDRPも全部PBR。
ただワークフローやレンダーパイプラインの違いによってあれだけの見た目の差が生じているだけで、基本原理は同じ。

今回のフレネル拡散反射

今回の実装は「フレネル反射率が低い時に拡散反射率が高くなる」という箇所に着目した簡易式で表現。

本来の計算式は更に後述で記載。

フレネル反射は鏡面反射のこと。
光の入射角が大きい(面に対して水平な)ほど鏡面反射率が上がる

エネルギー保存の法則に則り、光の総量は拡散反射量 + 鏡面反射量であることを考えると、
光の入射角が小さい(面に対して垂直な)ほど拡散反射率が上がる と言える。

更に、実際に目に入る光(カメラの位置)を考慮すると、
「光の入射ベクトル」「法線ベクトル」「カメラまでのベクトル」のなす角が小さい程強いと言える。

float CalcDiffuseFromFresnel(float3 N, float3 L, float3 V)
{
    // step-4 フレネル反射を考慮した拡散反射光を求める
    float dotNL = saturate(dot(N, L));
    float dotNV = saturate(dot(N, V));
    return dotNL * dotNV;
}

実際のフレネル拡散反射

\( f_d = \frac{\text{baseColor}}{\pi} \left(1 + (F_{D90} - 1) (1 - \cos\theta_{l})^5 \right) \left(1 + (F_{D90} - 1)(1 - \cos\theta_{v})^5 \right) \)

ただし、光が面に対しほぼ平行に入射してきたときの拡散反射率を \( F_{D90} = 0.5 + 2 \times {roughness} \times \cos^2\theta_{d} \) とする。

ここで、それぞれ以下に分解できる。

• アルベドカラー: \( \frac{\text{baseColor}}{\pi} \)
  　正規化するためπで割る。
• 法線と入射光ベクトルとの拡散反射率: \( \left(1 + (F_{D90} - 1) (1 - \cos\theta_{l})^5 \right) \)
• 法線とカメラベクトルとの拡散反射率: \( \left(1 + (F_{D90} - 1)(1 - \cos\theta_{v})^5 \right) \)

今回使用した式は以下。
Nはベクトル、Lは入射光ベクトル、Vはカメラべクトルを示す。
(dotは内積を求める関数として省略)

\( f_d = \frac{\text{baseColor}}{\pi} \left(dot(N, L)\right) \left(dot(N, V)\right) \)

法線と入射光・カメラベクトルの拡散反射率の詳細

法線と入射光の式を基準に考える。
\( \left(1 + (F_{D90} - 1) (1 - \cos\theta_{l})^5 \right) \)

一番左の1とその次の1は、垂直入射した際の拡散反射率(100%の意)。

\( F_{D90} \) は、平行入射した際の拡散反射率。
基本的に1より小さくなる。
そのため \( (F_{D90} - 1) \) は基本的にマイナスになる。

\( (1 - \cos\theta_{l}) \) は、法線と光源に向かうベクトルの内積。
5乗してる理由はカーブをつけるため。
（現実世界の現象は指数関数的な変化をするため）

カメラの場合はこれがカメラに向かうベクトルに変わるだけ。

この式を実装に変換すると以下のようになる。

// 垂直入射した時の拡散反射率 (一番左の1)
float f0 = 1.0f;

// 平行入射した時の拡散反射率 (Fd90 - 1の結果)
float f90 = 0.5f;

// 法線との内積
float t = pow(1.0f - dot(N, L), 5.0f);

// 拡散反射の算出
flaot diffuseRate = lerp(0f, 90f, t);

結局何してたかというと、
垂直反射率と平行反射率とのバランスを、法線との内積を利用して算出しているということ。

この言葉が最初にあればすんなり理解できたのに...()

Fd90について

光が面に対しほぼ平行に入射してきたときの拡散反射率
\( F_{D90} = 0.5 + 2 \times {roughness} \times \cos^2\theta_{d} \)

基本1より小さい値になると前述したが、最大で2.5になるらしい。
そりゃそうで、roughnessは0~1, cos2θも0~1なのだから、
0.5 + 2 * 1 * 1 で 2.5になるね。

だから範囲は 0.5 ~ 2.5 となる。

これにより、面が粗さを考慮した拡散反射を求めることができる。

実装

ディズニーの論文からの式ではエネルギー保存の法則が満たされていないことがあるが、
これを解消するEA DICEによる改良版コードを使用する。

float CalcDiffuseFromFresnel(float3 N, float3 L, float3 V)
{
    // step-1 ディズニーベースのフレネル反射による拡散反射を真面目に実装する。

    // 光源へのベクトルと視線へのベクトルのハーフベクトル
    float3 H = normalize(L + V);

    // 粗さ
    float roughness = 0.5f;

    float energyBias = lerp(0.0f, 0.5f, roughness);
    float energyFactor = lerp(1.0f, 1.0f / 1.51f, roughness);

    // Fd90の算出
    float dotLH = saturate(dot(L, H));
    float Fd90 = energyBias + 2.0f * roughness * dotLH * dotLH;

    // 法線と光源との拡散反射
    float dotNL = saturate(dot(N, L));
    float FL = (1 + (Fd90 - 1) * pow(1 - dotNL, 5));

    // 法線と視線との拡散反射
    float dotNV = saturate(dot(N, V));
    float FV = (1 + (Fd90 - 1) * pow(1 - dotNV, 5));

    return FL * FV * energyFactor;
}

今回版

実際版

...わ、わからん！！
けどフレネル反射が強い位置の面でも拡散反射が強く出てるらしい。

EA DICEの改良版コードについて

DICE 論文「Moving Frostbite to PBR」および GDC 等で発表された、“Frostbite Disney Diffuse” モデルで使用される式。

float FD90 = 0.5 + 2.0 * roughness * dot(h, l) * dot(h, l);
float3 diffuse = baseColor / PI * (1.0 + (FD90 - 1.0) * pow(1.0 - dot(l, n), 5.0));

数式にするとこう。

〇 ディズニーの論文から導出される式

\( f_d = \frac{\text{baseColor}}{\pi} \left(1 + (F_{D90} - 1) (1 - \cos\theta_{l})^5 \right) \left(1 + (F_{D90} - 1)(1 - \cos\theta_{v})^5 \right) \)
\( F_{D90} = 0.5 + 2 \times {roughness} \times \cos^2\theta_{d} \)

〇 EA DICEの改良版

\( f_d = \frac{\text{baseColor}}{\pi} \left(1 + (F_{D90} - 1) (1 - \cos\theta_{l})^5 \right) \)
\( F_{D90} = 0.5 + 2 \times {roughness} \times \cos^2\theta_{h} \)

\( \left(1 + (F_{D90} - 1)(1 - \cos\theta_{v})^5 \right) \) は処理に対し得られる効果が少ないため省略。

Fd90で使用するcos2θがハーフベクトルに変わっている。
調べる感じ、元は \( F_{D90} = 0.5 + 2 \times {roughness} \) らしい、、

これ以上は論文読まないといけなくなるからここで撤退。
基本はEA DICE使っておけば良いと思う。

テクスチャ

テクスチャの種類は以下のようなものがある。

• ディフューズマップ: 模様を表現する（一般にテクスチャって言われたらこれ）
• 法線マップ: 凹凸を表現する
• ハイトマップ: 高さを表現する
• 透明度マップ: 透明度を表現する
• スペキュラマップ: 鏡面反射を表現する
• AO(アンビエントオクルージョン)マップ: 環境光の強さを表現する

他にもさまざまな用途で使われる。
用途が違うだけで、基本は各ピクセルにRGBが書き込まれている。
書き込まれたRGBの値をどう使うかによって名称が変わる。

法線マップ

法線マップはPS3あたりから登場。
目的はローポリで細かなディティールを表現するため。

細かい凹凸表現を頂点で表現すると極端にデータ量が増え、パフォーマンスに影響が出るため。
　...なのだが、UE5のNanite(ナナイト)機能によると法線マップが不要になる、らしい。

公式: https://www.unrealengine.com/ja/blog/a-first-look-at-unreal-engine-5
参考: https://soysoftware.sakura.ne.jp/archives/2314

し、知らなんだ...UEしゅごい...

実際の開発現場がどうなっているのかは分からないが、
UE専用で作る時やNaniteに制限がなければ本当に法線マップ不要だし、頂点数削減もLODも不要っぽい。

ただモデル単位で考えると、UE5以外の環境ではやはり従来のローポリモデルが必要なケースが多いため、完全にはなくならない、、と思う。

Unityにもくれんか？

法線マップの仕組み

目で凹凸を認識する時、最も重要なのは光の陰影。
この陰影の表現は、ライトの方向と頂点の法線によって決まっていた。（これまでに学習した内容）

つまり、法線の計算が出来さえすれば頂点がなくとも同様の陰影を表現することが可能という理論。
テクスチャのRGBに法線XYZを書き込むことで法線マップとして使える。

法線マップにはデータ形式によって次の2種類が存在する。

オブジェクトスペース法線マップ

オブジェクト空間の法線マップ。

法線が-1.0~1.0なのに対し、テクスチャRGBは0.0~1.0の範囲のため、
計算の際は (RGB値 - 0.5) * 2 で復元する。

この法線はオブジェクトの回転がかかっていない場合の法線のため、
使用する際はさらにワールド空間行列をかけてワールド空間に直してから使用する。

疑似コードは以下。

// オブジェクトスペース法線マップを読み込み
float3 normal = normalMap.Sample(sampler, In.uv).xyz;

// 復元
normal = (normal - 0.5f) * 2.0f;

// ワールド空間へ変換
normal = mul(worldMatrix, normal);

この方式だと法線マップテクスチャはモデル基準点からのベクトルになるためカラフルになる。
また変形の際に法線向きが固定されてしまい、意図しない法線になるため変形に弱い。
そのため、一般には使用されない。

タンジェントスペース法線マップ

法線マップを貼り付けるポリゴンの法線座標系から見た法線が書き込まれた法線マップ。
法線座標系は、以下の3つの直行するベクトルを規定軸とした空間のこと。

• ポリゴンの法線ベクトル
• 法線と直行している接ベクトル(タンジェントベクトル)
• 法線と接ベクトルの外積で求めた従法線ベクトル

なおこの空間をタンジェントスペースとも呼ぶ。

タンジェントスペース補足

まｔｔｔｔｔったく分からなかったので調べた。

参考: https://coposuke.hateblo.jp/entry/2020/12/21/144327

タンジェントスペース(TBN空間)では、各RGB値は以下のように扱われる。

• R = X = タンジェント方向(U方向)の成分
• G = Y = バイノーマル方向(V方向)の成分
• B = Z = 法線方向(垂直な長さ方向)の成分

まず基準はメッシュ平面に垂直な法線である。
そのため、特に何も変更がない法線の場合、(0, 0, 1)になる。
これはUV方向に対し傾きがなく、メッシュに対して垂直なベクトルが法線に当たるためである。

次に、僅かにV方向に傾いた時の値を考えてみると、(0, 0.1, 0.995)となる。
法線は単位ベクトルのため、合成すれば必ず1となる。

これを逆手に取ったのがこの方法。
上記の場合、合成すれば僅かにV方向に傾くベクトルになることが分かる。

XY成分はUVであることから、メッシュのUV展開によって値が変わってくる。
オブジェクトスペースの場合は回転0の時を基準にしているためUVに影響されないが、TBNではこれを考慮する。
これにより、メッシュ変形によりポリゴン自体のTBNが変化したとしても、それに合わせて法線を再計算できるため常に正しい法線を得ることができる。

反対に、オブジェクトスペースの場合はメッシュが変形した際に法線マップの計算が合わなくなり、法線が崩れやすくなる。
これがTBNが原理的に変形に強い理由。

もう少し深堀をすると、
オブジェクトスペースはUV展開、メッシュの局所的な変形を考慮していない。

オブジェクト固有のローカル空間で表現されているため、例えば(0.7, 0, 0.7)の頂点に垂直な法線は(0.707, 0, 0.707)になるが、
この頂点が変形した時、面がどの方向に向いたのかを一つの行列から再計算することができない。

つまり、変形を考慮して法線を復元する際にTBNを使用するため、結果的に初めからTBNで保存した方が有利という見方ができる。

理論上はオブジェクトスペース法線マップから復元した法線をTBNに分解し、変形メッシュのTBN計算をすることで同様の結果を得ることができる、はず。

法線空間からワールド空間への変換

法線 * 基底軸 で求まる。

TBN空間における法線は各基底軸(メッシュから垂直なベクトル)が元になるため、これを掛けることでワールド空間にすることができる。

ワールド空間のベクトルをV、法線マップからのベクトルをVx,Vy,Vz、各頂点のTBN基底軸をT,B,Nとすると、以下の式で表すことができる。

V = (Vx * T) + (Vy * B) + (Vz * N)

TBN法線マップの場合、xyzの各成分はTBNに順ずるため、頂点からTBN情報を取得すれば復元することができる。

hlslで表すと以下の通り。

// 法線マップから読み込み
flaot3 localNormal = normalMap.Sample(sampler, In.uv).xyz;

// 復元
localNormal = (localNormal - 0.5f) * 2.0f;

// ワールド空間へ変換
float3 worldNormal = mul(localNormal, float3x3(tangent, binormal, normal));

この方式はメッシュから垂直なベクトル(Z方向に1なベクトル)が基準のため、
全体的にZ成分が多くなり青みがかる。

基本的にはこの方式が採用される。

実装

タンジェント、バイノーマルは頂点データのためセマンティクスで取得できる。
法線はNORMAL、接ベクトルはTANGENT、従ベクトルはBINORMALで取る。

struct SVSIn
{
    float4 pos : POSITION;  // モデルの頂点座標
    float3 normal : NORMAL; // 法線

    // step-1 頂点シェーダーの入力に接ベクトルと従ベクトルを追加
    float3 tangent : TANGENT;
    float3 binormal : BINORMAL;
};

法線適用前後。
適用後の方が細部の陰影がはっきりしているのが分かる。

スペキュラマップ

鏡面反射の強さを制限する。

例えば、1マテリアルで金属面と非金属面が共存するようなモデルで、
反射させたくない非金属面の箇所だけ黒く、金属面だけを白くすれば、反射箇所の制御ができる。

基本的にグレースケールのテクスチャになる。

実装

グレースケールのためRGBどの値を取得しても同じなため今回はR成分だけで判断。

float specPower = g_specularMap.Sample(g_sampler, psIn.uv).r;

反射光に直接掛ければ良いだけ。

specLig *= specPower

金属部分だけに鏡面反射が加わったことが分かる。

アンビエントオクルージョンマップ(AOマップ)

環境光の強さを制限する。

顎の下、首元など、環境光を受けやすい場所、受けにくい場所の環境光の強さを調整する。

大体はグレースケールのはず。

実装

テクスチャ読み込んで環境光に掛けるだけ。

float3 ambient = ambientLight;

// AOマップ読み込み
float ambientPower = g_aoMap.Sample(g_sampler, psIn.uv);

// 乗算
ambient *= ambientPower;

わずかに陰影がついたのが分かる。
この陰影を生み出すための光源調整を不要にし、意図した陰影をシンプルな環境光で表現するのが目的。

ポイントライト

ディレクショナルライトと比べ、考慮しないといけない点は以下

• 入射してくる光の方向
• 光源との距離による光の減衰

入射光の方向

各頂点毎に入射方向を求める必要がある。

純粋に頂点と光源とのベクトルで良い。
　→ 頂点座標 - 光源座標

距離による減衰

距離は前述のベクトルの長さが該当する。

距離をD, 影響範囲をRとした時、頂点毎の影響力Aは以下で求まる。

A = 1 - (1 / R) * D [%]

※ 影響範囲はポイントライトの光の強さのイメージ。
ただし、このまま結果を使用すると距離と影響力が比例してしまい非現実的になるため、
影響力を2乗した値を使用し、緩やかになカーブにする。

実装

今回はディレクショナルライトと同様のモデルで実装する。

フローは以下。

• 光源座標と頂点座標から入射光のベクトルを算出
• 入射光ベクトルを使用し、拡散反射光、鏡面反射光を求める
• 入射光ベクトルの長さから影響力を求める
• 影響力を反射光に乗算し、最終的な反射光を算出する

cpp側

構造体を作る。

ptColorの次のfloatに必要な変数を入れているが、パディングじゃなくていい理由はなに？
　→ （後述で説明）

// step-1 ライト構造体にポイントライト用のメンバ変数を追加する
Vector3 ptPosition;     // ポイントライトの位置
float pad2;
Vector3 ptColor;        // ポイントライトのカラー
float ptRange;          // 影響範囲

hlsl側

拡散反射光、鏡面反射光を算出する処理は関数化しておくと便利。

// step-8 減衰なしのLambert拡散反射光を計算する
float3 diffPoint = CalcLambertDiffuse(ligDir, ptColor, psIn.normal);

// step-9 減衰なしのPhong鏡面反射光を計算する
float3 specPoint = CalcPhongSpecular(ligDir, ptColor, psIn.worldPos, psIn.normal);

動かすとちゃんとポイントライトしてることが見える。

構造体定義にパディングがいらないことの調査

パディングを入れてみる。

// step-1 ライト構造体にポイントライト用のメンバ変数を追加する

Vector3 ptPosition;     // ポイントライトの位置
float pad2;
Vector3 ptColor;        // ポイントライトのカラー
float pad4;　// ☆ 追加
float ptRange;          // 影響範囲
Vector3 eyePos;         // 視点の位置
float pad3;
Vector3 ambientLight;   // アンビエントライト

色がおかしくなった。

なんでptColorの後のptRangeをパディングなしで取れるのだ？

これに関してパディングとcpp-hlsl間のデータ連携の前提を間違えて理解している。

Vector3の受け渡しにパディングが必要なのではなく、その本質はスロットを整理するためのもの。

基本的に、データはスロットを跨いで取得することはできない。

1スロットあたり16バイトで構成されている中で、
例えば以下のような構造体の場合、cpp側では連続したメモリにデータが格納される。

struct sample
{
    Vector3 a;
    Vector3 b;
}

HLSLが1スロット(4バイト)ずつ読む際に、
float3 bの読み始めはb.xの位置(12バイト目)ではなく、次のスロットの16バイト目からになる。

だからデータがずれる。

この、スロットの調整のためにパディングを設け、
スロットを跨ぐようなデータ配置になった時、次のスロットからデータが始まるようにするのがパディングの本質。

// step-1 ライト構造体にポイントライト用のメンバ変数を追加する
Vector3 ptPosition;     // ポイントライトの位置
float pad2;
Vector3 ptColor;        // ポイントライトのカラー
float pad4;　// ☆ 追加
float ptRange;          // 影響範囲
Vector3 eyePos;         // 視点の位置
float pad3;
Vector3 ambientLight;   // アンビエントライト

cbuffer DirectionLightCb : register(b1)
{
    // step-6 定数バッファーにポイントライト用の変数を追加
    float3 ptPosition;      // 位置
    float3 ptColor;         // カラー
    float ptRange;          // 影響範囲
    float3 eyePos;          // 視点の位置
    float3 ambientLight;    // アンビエントライト
};

今回の場合、pad4を追加したことで、pad4がHLSL側ptRangeとして読まれたためデータがずれた。

だからpad4は不要だった。

スポットライト

今回はコーンの表示はなし。残念。

実装はポイントライトのデータに放射方向と角度を追加するだけ。
処理手順は以下。

• スポットライトの位置を光源として、ポイントライトを計算
• そこから頂点へ向かうベクトルを計算
• そのベクトルとスポットライトの放射方向ベクトルとの内積から角度を算出
• その角度から影響率を算出

内積の特性

角度の算出には、内積のこの性質を利用する。

単位ベクトル同士の内積は、なす角の余弦の値になる

計算式は以下。

float angle = acos(dot(v1, v2));

内積の公式が a·b = |a||b|cosθ であることを考えると納得。

実装

// step-11 入射光と射出方向の角度を求める
float angle = abs(acos(dot(ligDir, spDirection)));

// step-12 角度による影響率を求める
affect = 1.0f - 1.0f / spAngle * angle;
if(affect < 0.0f) affect = 0.0f;
affect = pow(affect, 3.0f);

// step-13 角度による影響率を反射光に乗算して、影響を弱める
diffSpotLight *= affect;
specSpotLight *= affect;

step11は前述したとおり。absで符号を外す。
角度の影響率はポイントライトと同様の考え方。

wtf
思ったように光らない...

修正

after品を使ったら正常だったので何かが違う。

変数の型が違った。

// step-6 サーフェイスに入射するスポットライトの光の向きを計算する
float ligDir = normalize(psIn.worldPos - spPosition);
　↓
float3 ligDir = normalize(psIn.worldPos - spPosition);

これだとx成分しか残らず、以降float3として扱う時に{x, 0, 0}の状態になっていたっぽい。

これでもコンパイルエラーが出ないことが驚き...
C#ほど親切じゃないことに注意した方が良い。

コーン表示

せっかくなのでコーン表示に挑戦...
したかったが、3Dモデルを追加せず実装するには深度テクスチャが必須になる。

今のエンジンに深度テクスチャを取得するシステムがなく、かなり時間がかかりそうなので今はスキップ。
全部終わってからか、余裕ができたらやってみる。

リムライト

頂点法線と光の入射方向・視線方向を考える必要がある。

法線と入射方向

光の向きと頂点法線が垂直に近い箇所で強く光る。

これは、2つの単位ベクトルの内積となす角の関係が以下のようになる性質を利用して制御できる。

• 0°: 1.0
• 90°: 0.0
• 180°: -1.0

拡散反射光の演算とほぼ同様に影響度を制御できる。

拡散反射: 内積 * -1
　↓
リムライト: 1 - max(0, 内積)

法線と視線

入射方向と同様だが、方向が逆向きのため符号反転させる

1 - max(0, 内積 * -1)

ここまでの状況をまとめると下図のようになる。

最終的にはこれらを乗算する。

実装

常にカメラを視線中央とするため、法線はカメラからの法線になるよう演算する。

SPSIn VSMain(SVSIn vsIn, uniform bool hasSkin)
{
    ...
    // step-2 カメラ空間の法線を求める
    psin.normalInView = mul(mView, psIn.normal);
    ...
}

カメラを視線中央にしている場合、視線ベクトルは(0, 0, 1)になる。
この場合、内積は常にz成分と同じ値になるため内積の計算は不要で、z成分を直接内積として扱える。

// step-4 サーフェイスの法線と視線の方向に依存するリムの強さを求める
float power2 = 1.0f - max(0.0f, psIn.normalInView.x * -1.0f)

結果

今までリムライトとかどうやって端の検出してたんだろうって思ってたけど、
法線との内積でやってたのは意外でびっくりした。

半球ライト

シンプルな計算だがディレクショナルライトよりリアルな光源。

PS3、スマホなどGPUの計算速度が心もとない環境で有効的。
今でもスマホゲーで採用されることがあるらしい（Unityにはなかったよね？）

考慮するのは地面の色（照り返しの色）と空の色の2種類。
計算は頂点法線と地面との内積を求めるだけ。
（ここまでくると内積だろうな～って予想がつくくらい内積大活躍）

計算

内積が1の場合は空、-1の場合は地面を向いていることになる。
それぞれ0~1に揃えるため、(内積 + 1) / 2 をする。

実装

空の色と地面の色の合成はLerpで良い。

float3 hemiLight = lerp(groundColor, skyColor, t);

左が地面の色、右が空の色の設定値。

light.groundColor = { 0.7f, 0.5f, 0.3f };
light.skyColor = { 0.15f, 0.7f, 0.95f };

結果

おそらく他のライトとか元のモデルの色に影響を受けて緑っぽくなってる。

実際には空の模様とか地面の模様とかで変わってくるだろうけれど、
最低限の処理であればここまでになる。

概要

NHK放送技術研究所にて開催された技研公開を偶然にもTwitter(X)で知ったためふらっと行ってきた。

放送関係技術の他、様々なUXに関する展示やディスプレイなどハードウェア関係の展示などがあり、
興味をそそられる内容がそれなりにあり楽しかった。

各種展示

(1) 広がるコンテンツ体験

XRグラスによるAR表現と、付属カメラによるジェスチャー操作、
専用デバイスによるアイテム表示、香り、色・温度制御などの展示。

温度制御によって冷たい・暖かいなども伝えれるのは新しい。

XRグラスはNTTのミルザらしい。
https://www.devices.nttqonoq.com/mirza

専用デバイスからの香りは、デバイスから出ているのではなくデスク下に別デバイスを仕掛け、
そこから6種のカートリッジ式で出してるらしい。残念。

デバイス上に穴が開いており、そこから香りが出るのかと思いきや
温度制御の仕組みにより冷却が必要なためらしい。

(3) イマーシブメディア体験

高画質360°撮影の展示。

表示デバイスは...人テク2025のある企業の展示で見たような...

カメラよくわかんないけどすごい！ｷｬｯｷｬ

(5) 自由な曲面を可能にするディフォーマブルディスプレイ

今回個人的に一番気に入った展示。
フレキシブルディスプレイ。

フレキシブルディスプレイ自体は現行品があるはずだが、それより柔軟に動く。
半分に折りたたんでも大丈夫なくらいぐにゃぐにゃ。

伸びは2倍まで問題なく、耐久性は数万回試験を合格、さらにゴム状の膜で覆うため耐水性もありとのこと。
中の導線に液体金属を使用しているため、伸びきって一時的に断線しても元に戻せば自然と戻り再導通するらしい。

今は画素が64*32と低いが、LEDの問題ではなく導線を細くすることができないためらしい。
将来的にはテレビと同じくらいの画素までもっていきたいらしい。

これ服とか色んなとこに使えるからめちゃええやんと思って見てた。これ好き。

応用品。

下に距離検知センサを付けておけば、押した分だけLEDを光らせる箇所を変えれるというデモ。

シンプルだが色んな応用が思いつく良いデモ。普通に欲しい。。。！！

(8) Webベース放送メディア③ コンテンツナレッジ

検索する際に入力する "米 高い なぜ" みたいなワードに対し、
検索者が真に知りたい情報をAIを用いて抽出する技術。

各記事の右側に色のついた〇があるが、
入力されたワードから引っ張られた記事がグレー、
それ以外は、AIが抽出した他のキーワードに関する記事。

グレー以外の記事を抽出できる = 検索者が知りたい可能性はあるが、自力ではたどり着けない情報
これをサポートする目的のモデル。

(12) 縦型動画自動切り出し技術

通常横型で編集され放映されるが、近年縦型の需要に伴い、増えた編集工数を削減する目的。

単に縦に切り抜くだけではなく、AIを用いて編集者の癖やその動画の趣旨などをモデルから選定し、
見せたいカットやカメラワークを崩すことなく縦型に収めるよう自動編集してくれるらしい。

YouTubeとかでも需要ありそう。

(13) イマーシブコンテンツ提示のための映像・音響の連動技術

360°カメラで撮影し、3D空間にボリュメトリックモデルとしてモデルを置き、
それとは別で収録した360°音声をシーンに配置。
コントローラー（視聴者）の任意の位置に移動し、その位置に応じた映像と音声を返す技術。

撮影範囲は現状1~2人程度で、
多人数だと映像の重なりにより影が出てしまい、ボリュメトリックに影響が出るため難しいらしい。
モーキャプと合わせてCG補正しても良いが、今はしてないらしい。

収録スタジオ。

カメラ12台、単一指向性マイク38台くらいらしい。

アクターにはピンマイクも持たせ、細かい音声はそっちでひろい、
音の広がりを周囲のマイクで取るらしい。

アクターをポイントライトと考えると分かりやすいかも。
各マイクで取れる音はポイントライトからの光ベクトルと考えれば補正するイメージも湧く。

今は技術的に映像と音声を別撮りせざるを得ないらしいが、将来的には同時収録可能にしたいらしい。

ちなみにこのデモの他に演奏者が並ぶデモも聴いたが、
なんで音量バランスの調整が大切な演奏において自由に動いて一つの楽器を集中的に聴くだの言われないといけないんだって気持ちでいっぱいで何の用途で開発してるのかまるで分からなかった。
多分デモが悪い。

一応用途を聴いたが、将来的にはユーザーが映像内を自由な位置で視聴できる環境にしたいらしく、
それに備えて開発しているらしい。
先のXRグラスのジェスチャー操作とかも含めればまぁ分からなくはないが、
例えばドラマの撮影をこれでしたとして、意図的なカットとか映像効果が多いはずのドラマに対し視聴者が自由に動いて視聴するってマッチしてなくないかと、テレビで放送する映像においてこの技術により得られる体験がある専用の番組以外はよほどマッチしないんじゃないかという気持ちしかなかった。

否定してはいないが、デモをするなら想定される用途で撮影した映像でやってほしかったところ。
残念。

N5 黎明期の貴重な機器に見る放送技術の原点

なかなかお目にかかれない1950年代の映像機器。
歴史を感じた。

その後

もんじゃFoooooo!!

実はDUOだったので同伴者と一緒にもんじゃへ。
明太バターもんじゃ、ネギ塩豚もんじゃ、丸ごとイカ焼き肝付、ホタテじゃがバタ。
ちゃんとしたもんじゃ初めてだった、とてもおいしかった。
めっちゃ気さくな店員さんがすごく話しかけてきたけどわいわいできて楽しかった。

店員さん曰くイカ墨もんじゃが美味しいらしいのでまた行きたい。

ノイズテクスチャ混ぜていい感じにまばらな見た目が作れたけど、
やっぱりメッシュ自体がまばらになっててほしいなぁ。

...これGeometryNodeで楽に作れんか？？

制作

虫食いを作る

とりあえず平面を作り、GeometryNodesタブから新規にGeometryNodeを作成する。

言うてほとんど知らないけれど、
Unityのシェーダーグラフとか、BlenderのシェーダーやCompositとかと一緒で
InputとOutputが成立してれば大丈夫だと思う。

ということでChatGPTに頼りつつ作っていく。

フローはこんな感じ

• ランダムな配置点を生成する
• そこにスフィアを置く
• 平面と重なっている箇所を消す

GeometryNodeで表現するとこんな感じ。

NoiseTextureのScale、Detail、UVSphereのRadiusを調整して虫食いのサイズを変えていく。

ちなみにRealizeInstanceのノードを直接Outputに入れるとスフィアが表示される。

まばらにする

上記のRealizeInstanceの先に重複している箇所だけを表示するようにノードを組んでいく。

• ランダムな配置点を生成する
• そこにスフィアを置く
• 置いたスフィアをまとめて、重複を消す（New！）
• 平面と重なっている箇所を消す
  平面と重なっている箇所以外を消す

以下のことに注意する。
・RealizeInstanceのRealizeAllにチェックを入れる
・最後マージするMeshBooleanをIntersectにする

重複箇所を消しておかないと、最後Booleanが上手く動いてくれない。

位置が気に入らない場合は冒頭のDistributePointsOnFacesのSeedをいじっていい感じの場所を探すと良い。

後書き

何となく頂点シェーダー見たいな感じで触れるのがとても良い。
複雑な編集をできるうえに修正が容易なのはとても良い。

スフィアの各頂点にノイズを入れて歪ませたかったけど、
思ったように動かなかったからまた次の機会に。

GeometryNode、楽しい。

ライトの種類

ディレクションライト

現実世界の太陽に近い存在。
位置、影響力の減衰が存在しない。
シンプルで高速。最も基本的なライト。

以下の要素で構成される。

• 方向：3次元ベクトル
• カラー：RGB

ポイントライト

位置と距離を考慮するライト。
複雑で処理も重い。

PS3, Xbox360辺りの時代だと1シーンに大量におけなかった。
　→ TBR系アルゴリズムによって大量配置が可能になった。

※ TBR系アルゴリズムはChapter16で紹介のため、そういうアルゴリズムによって変化があったことを覚えておく。

以下の要素で構成される。

• 方向：3次元ベクトル
• カラー：RGB
• 影響範囲：メートル

影響範囲は光が届く距離の調整のための減衰率に関与する。

スポットライト

シンプルなものであればポイントライトを元に実装できる

以下の要素で構成される。

• 方向：3次元ベクトル
• カラー：RGB
• 放射方向：3次元ベクトル
• 放射角度：rad or deg（多分rad）
• 影響範囲：メートル

一時期スポットライトのコーンを表示するシェーダーを書こうとした時期があって結局書けなかったが、構成要素を知ることで何となく書けそうな気がしてくる。

反射モデル

ライトによる反射モデルはいくつかあり、今回はPhongの反射モデルを使用する。

反射モデルとは、

物体の表面がどのように光を反射するかを数値的に表現し、
コンピュータグラフィックスなどで視覚的な表現を可能にするためのモデルのこと。

光の入射方向と反射方向の間の関係を表す関数 (BRDF (Bidirectional Reflectance Distribution Function)) を用いて光の反射の特性を表現する。

Phongの反射モデルとは

https://ja.wikipedia.org/wiki/Phong%E3%81%AE%E5%8F%8D%E5%B0%84%E3%83%A2%E3%83%87%E3%83%AB

ユタ大学の理学博士 ブイ・トゥオン・フォン により開発され、1973年に "Illumination for Computer Generated Pictures" という学位論文として発表された反射モデル。

同論文内で法線ベクトル補間手法も提案されており、Phongシェーディングとして知られている。
一番有名な反射モデルって覚えておけばよさそう。

その他の反射モデル

"Phongの" って言うことは他にもあるのか？
ということで調べてみた。

...多っ！！

用途別にまとめると以下。

• ゲームで軽量な表現: Phong、Blinn-Phong、Lambert
• 映画・VFXなど高品質表現: Cook-Torrance、Disney BRDF
• マットな材質: Oren–Nayar
• 金属、光沢面: Cook-Torrance、Ward
• 異方性素材(髪、布など): Ward、Ashikhmin–Shirley

こう見るとPhongが一番基本的な反射モデルに見える。
Phong自体も1973年とかなり前からあったのを考えると反射一つ取っても奥が深いことがよく分かる...

今回使用する反射モデル

Phong反射モデルは 拡散反射光、鏡面反射光、環境光 のそれぞれを合成したものになる。
今回は以下のように計算していく。

• 拡散反射光 → Lambert拡散反射モデル
• 鏡面反射光 → Phong鏡面反射モデル
• 環境光 → 近似モデル

当然、各光要素を求める方法全てがPhongモデルに含まれているが、
今回は各要素ごとに別のモデルを使用する。

Lambert拡散反射光

光が当たっていれば明るく、当たっていなければ暗くするモデル。

計算は 法線とライト方向との内積 で行う。
※ 法線：面の向きを示す単位ベクトル

a･b = (ax * bx) + (ay * by) ...
    = abcosθ

上図の様な関係の際、それぞれの内積は以下のようになる。

• a: 0
• b: -1
• c: 0
• d: 1
• e: -0.7

この結果を全て-1すると、光（-1, 0, 0）により当たっている箇所が1に、当たっていない箇所が0以下になることが分かる。

• a: 0   → 0     → 暗い
• b: -1   → 1    → 明るい
• c: 0 → 0    → 暗い
• d: 1   → -1   → 暗い
• e: -0.7 → 0.7 → やや明るい

つまり、Lambert反射モデルにおける反射光の求め方は

　法線と光の内積が1な程明るく、0な程暗くする

ということ。（単位ベクトルという前提）

cpp側

modelInitData.m_expandConstantBuffer = &directionLig;
modelInitData.m_expandConstantBufferSize = sizeof(DirectionalLight);

ディレクショナルライトもGPUで参照するため、定数バッファーを使用して渡す。
CPU側ではモデルデータ、シェーダーパス、ライトデータ（方向と強さ）を渡すだけで、
実際の陰影計算はGPU側で行う。

Vector3とfloat3の扱いについて

今回のディレクショナルライトは方向と色のデータをVector3で送っている。
その際に定義した構造体は以下。

struct DirectionalLight
{
    Vector3 ligDirection;
    float pad;
    Vector3 ligColor;
};

HLSL側で定義した定数バッファーは以下。

cbuffer DirectionLightCb : register(b1)
{
    float3 ligDirection;
    float3 ligColor;
};

この、cpp側で定義していたpadはパディングという、意図した変数である。

HLSLでは、定数バッファーのデータは16の倍数のアドレスに配置される。
対して、cppでは4の倍数のアドレスに配置されていく。

すると下図左側の表のように、2つ目の変数からcppとhlslでデータの不整合が起きる。

ここで、cpp側に2つめのVector3変数の前にfloat変数を挟むと4バイト分ずれるため
hlslとの不整合が起きなくなる。（上図右側の表）

UnityなどでHLSLを触る場合は意識しなくていいはずなので知識程度かな。
もし自分でcpp側を組むことがあれば覚えておくと過去の自分にとても感謝しそうな内容。

頂点法線の補正

SPSIn VSMain(SVSIn vsIn, uniform bool hasSkin)
{
    SPSIn psIn;

    // step-6 頂点法線をピクセルシェーダーに渡す
    psIn.normal = mul(mWorld, vsIn.normal);
}

モデルの回転に合うようにするには、頂点毎の法線にワールド行列を掛けることが必要。
頂点座標の配置空間を直す際もワールド行列を掛けたが、今回は回転を直すために掛けている。
　→ なんでこれで回転が直る？

法線は座標を無視し、回転と拡大だけで十分であるため、
ワールド行列を掛けることで位置、回転、拡大をまとめてワールド空間に直している。

なお、拡大については(1.0, 1.0, 1.0)である前提のため無視できる。
この通りでない場合（非等方スケーリング）は別途計算が必要。

反射光の演算

// step-7 ピクセルの法線とライトの方向の内積を計算する
float t = dot(psIn.normal, ligDirection);
t *= -1.0f; // 符号反転

dotで内積を求めることができる。
反射光から色を算出し、テクスチャカラーの乗算することで反射を組み込むことができる。

鏡面反射光 (Phongモデル)

金属のような反射を表現するためのモデル。
「反射した光がどれだけ目に飛び込んでくるか」を計算する。
　→ 屈折率を考慮した反射光って理解でいいと思う。

鏡面反射の強さに必要な処理

• ライトが面に反射したベクトルを算出
• 面から視点に向かって伸びるベクトルを算出
• 上記2ベクトルの内積を算出 (これが鏡面反射の強さ)
• 上記の値を絞り、最終的な反射値を算出

反射ベクトルの演算

光源ベクトルL、法線Nとした時の反射ベクトルRは以下で求まる。

R = L + 2(-N･L)N

これはHLSLのreflect関数の内部処理であり、通常はこのメソッドを使用すれば良い。

視点へのベクトルの演算

視点座標から光が入射した座標を引いた値。
入射した座標から視点座標へ移動すると考えると自然な式。
求めた値は正規化するのがベター。

反射ベクトルと視点へのベクトルとの内積

ここまで下図のような状態

当然、光は視点に届いて初めて明るさとして認識されるため、
内積、つまりどの程度反射ベクトルが視点ベクトルと重なるかを求めれば
その値をもって反射値を算出できることは理解できる。

そういえば反射ベクトルはreflectで勝手に正規化されるって理解でいいのかな？
それとも法線が単位ベクトルって前提だから？
　→ 法線、光源ベクトル共に正規化されてる前提っぽい。

反射値の絞り

反射値を累乗して絞りを付けて行く。

累乗することで1未満の値を減少させることができ、
きれいな反射(1の値)以外の強さを調整できる。

定数バッファーの別の書き方

拡散反射の時もしれっと出ていたが、
定数バッファーは以下みたいにも書けるらしい。

// 今まで
flaot3 pos : register(b1)

// ☆ 別の書き方
cbuffer DirectionLightCb : register(b1)
{
    float3 ligDirection;
    float3 ligColor;
    float3 eyePos;
};

絞りの実装について

絞りの指数は5
大きいほど減衰が増す。

// step-7 鏡面反射の強さを絞る
t = pow(t, 5.0f);

実際は調整できるように変数化した方が良い気がする。
（今回はなんとなく5になってると思う。）

試しに2にしてみる。

想定通り僅かに明るい部分が増えた。

環境光

地面・壁などの跳ね返りの光(2次反射)などの間接光を加える。
ただし一般に2次反射の計算は対象が多く膨大になりパフォーマンスに大きく影響が出てくる。
　→ 物体は一律で同じ間接光を受けている として計算する。

この近似計算モデルを環境光(アンビエントライト)という。

rgb全てに一定の値を加算して底上げする。

実装

拡散反射と鏡面反射を足した光に対し、一律な値を加算するだけ。

// 拡散反射光と鏡面反射光を足し算して、最終的な光を求める
float3 lig = diffuseLig + specularLig;

// step-1 ライトの効果を一律で底上げする
lig.x += 0.3f;
lig.y += 0.3f;
lig.z += 0.3f;

一律で加算するアンビエント値は定数バッファーでcpp側から渡してもOK
エンジン固定ならこっちの方が編集しやすいかも？

float3 ambientLight : register(b1)

// step-9 拡散反射光と鏡面反射光を足し算して、最終的な光を求める
float3 lig = diffuseLig + specularLig + ambientLight;

コーヒー飲みながらプルして開いて確認していた昼過ぎ。
確認のためシェイプキーを動かしてみた。
すると。。。

な、なんだこれは～～～！！！

事象

分かっていることはシェイプキーを動かすと顔の一部に意図しないシャドウがかかる。

目と口周りが怖いことになっとる...

結論

結論を先に。

UnityのFBXインポート設定で、ブレンドシェイプの法線をインポートに変更する。

Blenderを見てみる

とりあえず元のFBXをBlenderで開いてみる。

大丈夫そうやな。。。

目と口周りがおかしくなるけど、どんなメッシュになっとる？

なるほどシャープがかかっているみたい。

ついでに法線も。
これも大丈夫そう。

一旦シャープ外してみる。

お？なんとなく事象と同じような見た目になったぞ？？

シャープ処理について

普段モデリングする時クリースばっかりだからシャープって何してるんだろう。

GPT質問

「シャープをマーク」は、選択したエッジに「シャープ」属性を付与し、そのエッジを境に法線の補間を分断します。これにより、エッジの両側の面で異なる法線が設定されるため、視覚的に「鋭い角」が生まれます。

根拠として若干薄いが、法線がシャープによって変わったことに起因するみたい。

ということはFBXに正常に法線情報が渡っていないか、Unityでインポートする際に正常に処理できてないかの2択になる。

Unityインポート

一度FBXのインポート設定を見てみる。

この項目・・・

モデル自体の法線とシェイプごとの法線は別処理扱いになってる？？

調べてみる。

https://docs.unity3d.com/ja/2022.3/Manual/FBXImporter-Model.html#blendshapenormals

やはり別々で処理されているみたい。

今回はモデル側で作られた法線を使いたいのでImportにしてみる。

直った！

まとめ

冒頭の結論でも書いたが、ブレンドシェイプの法線をインポートに変えることで直った。

デフォルトでCalculateなので知らないと引っかかるトラップ感がすごい。

3Dモデルを複数ソフトで使う時はシャープとか法線に影響する設定はあまりやらない方がいいのかも？
私がクリース派だからな気もするけれど。

（クリース使うとサブディビジョンが必須だからメッシュ数増えるのが嫌でシャープ選ぶとかもあるから一概には言えないね。）

ちなみに今回のモデルは再現用にBlenderで作ったものだが、事象発生時はMayaで作られていた。

あまりないと思うけど制作ソフトによっても変わるかも？

追記

もしインポートにしても変な時はNoneにしてみるのもあり。

レンダリングパイプライン

描画する手順のこと。

必要最低限の手順

• 入力アセンブラー
  　頂点バッファー、インデックスバッファーなどをグラフィックスメモリからロード
• 頂点シェーダー
  　頂点データをスクリーン空間に変換
• ラスタライザー
  　塗りつぶすピクセルを決定
• ピクセルシェーダー
  　ピクセルカラーを決定

この後にドローコールをすれば描画できる。

頂点シェーダー、ピクセルシェーダーは自由なプログラミングが可能。
ラスタライザーはカリング設定の選択程度。

Chapter2 はじめてのシェーダー

VisualStudio2022でビルドする際のエラー解消

VisualStudio2022でビルドする場合、altbase.hが見つからない。
（本書はVisualStudio2019が前提）

ATLをインストールすれば解決する。

頂点シェーダー

// HLSL

VSOutput VSMain(VSInput In)
{
    VSOutput vsOut = (VSOutput)0;

    // step-1 入力された頂点座標を出力データに代入する
    vsOut.pos = In.pos;

    // step-2 入力された頂点座標を2倍に拡大する
    vsOut.pos.x *= 2.0f;
    vsOut.pos.y *= 2.0f;

    // step-3 入力されたX座標を1.5倍、Y座標を0.5倍にして出力
    vsOut.pos.x *= 1.5f;
    vsOut.pos.y *= 0.5f;

    return vsOut;
}

代入した出力用データは演算していじれる。

セマンティクス

// HLSL

// 頂点シェーダーへの入力頂点構造体
struct VSInput
{
    float4 pos : POSITION;
};

// 頂点シェーダーの出力
struct VSOutput
{
    float4 pos : SV_POSITION;
};

: の後はセマンティクス
頂点が持つデータの中で、どのデータを扱う変数なのかを決める  

頂点データは座標、色、法線、UVなどを持つ

これを引数で渡されたデータからどう取るかを指示するのがセマンティクス

以下代表例（他にもregisterとかある）

やっててよかったBlender。

出力の時はSV_が付く。多分DirectXの決まり事？
　→ 今の所POSITONのみSV_POSITIONでなければならず、他はそのままでよさそう。

// cpp

// パイプラインステートの初期化
void InitPipelineState(PipelineState& pipelineState, RootSignature& rs, Shader& vs, Shader& ps)
{
    // 頂点レイアウトを定義する
    D3D12_INPUT_ELEMENT_DESC inputElementDescs[] =
    {
        { "POSITION", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, 0, D3D12_INPUT_CLASSIFICATION_PER_VERTEX_DATA, 0 },
    };

ここでやってるからセマンティクスを定義してる？っぽいからもしかしたらパイプライン毎かも。分からない。

定義してるのか、HLSLが定義しているセマンティクスを、セマンティクスとして扱うための処理なのか、多分後者かな？

シェーダーメソッドのエントリー

// HLSL

// 頂点シェーダー
VSOutput VSMain(VSInput In)

// ピクセルシェーダー
float4 PSMain(VSOutput vsOut) : SV_Target0

こいつらのコールはどこから？

// cpp

// 2. シェーダーをロード
Shader vs, ps;
vs.LoadVS("Assets/shader/sample.fx", "VSMain");
ps.LoadPS("Assets/shader/sample.fx", "PSMain");

ここ！！！

パイプライン（エンジン？アプリ？）毎に設定されるシェーダーロードの第一引数でファイル、第二引数でメソッド名が指定される。
　→ Shaderクラスが今回用のエンジンのクラスのためエンジン毎って理解でいいはず。

逆にいうとパイプラインが隠蔽されている場合はエントリーポイントとなるメソッドは必ず一定の名称になるということ。
　→ Unityとかがそう。

引数、戻り値で使ってる構造体(VSInputとか)はユーザー設定だから名称は自由かも？まだ分からない。

コール順はパイプラインが決めてる（DirectXかも？）から、頂点→ピクセルの順で呼ばれるのはそういうものと思った方がよさそう

まぁそういうステージ順になるよねって理解でいいと思う。

コール回数

頂点シェーダー、ピクセルシェーダー共に一回のドローコールで頂点数と同じ回数だけコールされる。
　↑間違い。
　　頂点シェーダーは頂点数、ピクセルシェーダーはピクセル数に応じる。

3頂点ならそれぞれ3回ずつという理解でいいらしい。
　↑間違い。
　　3頂点なら頂点シェーダーは3回、描画が640*480ならピクセルシェーダーは307200回呼ばれる。

頂点シェーダーの引数には、おそらく頂点バッファー配列の要素を一つずつ入れてるんだと思う。

だから頂点シェーダーは↓みたいに単に入力座標を返すだけでも異なった座標を出力できるんだと思う。

// hlsl

// 頂点シェーダー
// 1. 引数は変換前の頂点情報
// 2. 戻り値は変換後の頂点情報
VSOutput VSMain(VSInput In)
{
    VSOutput vsOut = (VSOutput)0;
    vsOut.pos = In.pos;
    vsOut.color = In.color; // カラーの情報を出力する
    return vsOut;
}

ピクセルシェーダー

ピクセルシェーダーが色を決定する場所。

典型例は陰影。

シェーダーと言われてぱっと思いつくのはここ。

頂点カラーとピクセルカラー

頂点カラーとピクセルカラーは別物。

特に、頂点シェーダーで設定した色はあくまで頂点毎の色。

各頂点違う色が設定されていれば、頂点間のピクセル色はラスタライザーによって補完される。

// hlsl

float4 PSMain(VSOutput vsOut) : SV_Target0
{
    // 赤色を出力している
    return float4(1.0f, 0.0f , 0.0f, 1.0f);
}

つまり↑みたいな処理はせっかく入ってきた頂点情報 vsOut（厳密にはラスタライザーによって補完された各ピクセル情報のはず？）を使わず赤色に上書きしているという解釈で良い。

だから↓みたいに入力情報をそのまま出力すればラスタライザーによって補完された色を見ることができる

// hlsl

// ピクセルシェーダー
float4 PSMain(VSOutput vsOut) : SV_Target0
{
    // step-4 頂点シェーダーから受け取ったカラーを出力する
    float4 color;
    color.x = vsOut.color.x;
    color.y = vsOut.color.y;
    color.z = vsOut.color.z;
    color.w = 1.0f; // α値は固定
    return color;
}

ピクセルシェーダーに渡るデータ

じゃあVSOutPutとして入ってきたposには・・・？

// hlsl

// ピクセルシェーダー
float4 PSMain(VSOutput vsOut) : SV_Target0
{
    // test 頂点座標のデータを色にするとどうなる？
    float4 color;
    color.x = vsOut.pos.x;
    color.y = vsOut.pos.y;
    color.z = vsOut.pos.z;
    color.w = 1.0f; // α値は固定
    return color;
}

黄色（1, 1, 0）?!
一定の値が入ってきているってことっぽい？

いや、色は0.0~1.0で正規化されてるからそれ以上の値が入ってきたときに1.0になるからだ。

最大値分かんないけど適当に1000で割っておけばいい色になりそう。

// hlsl

// ピクセルシェーダー

float4 PSMain(VSOutput vsOut) : SV_Target0
{
    // test 頂点座標のデータを色にするとどうなる？
    float4 color;
    color.x = vsOut.pos.x / 1000;
    color.y = vsOut.pos.y / 1000;
    color.z = vsOut.pos.z / 1000;
    color.w = 1.0f; // α値は固定
    return color;
}

できた！

上左右の順に(0.5, 0)(0, 1)(1, 1)のイメージっぽい？

やっぱり各ピクセルごとの座標が入ってくるみたい。

Chapter3 シェーダープログラミングの基本

座標の求め方

座標は ワールド行列、カメラ行列、透視変換行列 の乗算で求めることができる。

変換順序

• モデル空間（モデル毎が基準の空間）
  　↓ 全頂点にワールド行列を乗算
• ワールド空間（ワールド基準点からの位置）
  　↓ 全頂点にカメラ行列を乗算
• カメラ空間（カメラからの位置）
  　↓ 全頂点に透視変換行列を乗算
• スクリーン空間（2次元平面に変換）

頂点数が多く計算量も多いため乗算はGPUが担当する。
ただし、行列の作成はCPUが担当する。

行列作成がCPUの理由

• 行列作成のための情報がメインメモリにあるから
• 1フレーム当たりの計算量が少ないから

定数バッファー

CPUで作った行列をGPUに渡すシステム（定数バッファー）を使用する。

定数バッファーに関連するAPIをDirectXが提供している

定数バッファーを使用するための仕組み → ディスクリプタヒープ

イメージ

• 行列：ご飯
• 定数バッファー：お椀
• ディスクリプタヒープ：お盆

サンプルコードのエンジン

サンプルコード中のMainEngineは著者さんが作成したエンジンっぽい。

実際に一から作るのであればDirectXのAPIをラップするようなエンジンが必要なことは覚えておいた方が事故らなさそう。

セマンティクスが使用できるカ所

セマンティクスは構造体宣言時以外でも使える！！

// hlsl

float4x4 g_worldMatrix : register(b0);

↑ がメソッド外にあっても大丈夫。

この場合、float4x4（float行列）のg_worldMatrix変数をbレジスタ0番目（CPU側で設定した定数バッファー）へのアクセス変数として定義する という意味

テクスチャロード

テクスチャは本体の画像データをCPUで読みこんでグラフィックスメモリに入れる。

定数バッファーでbレジスタに入れた時と同様に、tレジスタに入れる。

bはバッファのb、tはテクスチャのtらしい。

定数バッファ同様、テクスチャはディスクリプタヒープに入れる

// cpp

// ディスクリプタヒープに定数バッファを登録
ds.RegistConstantBuffer(0, cb);

// step-3 テクスチャをディスクリプタヒープに登録
ds.RegistShaderResource(0, tex);

つまり正確には以下の関係性

• データ：ご飯（行列、テクスチャなど）
• レジスタ：お椀（bレジスタ、tレジスタ）
• ディスクリプタヒープ：お盆

テクスチャマッピング

// hlsl

// ピクセルシェーダー
float4 PSMain(VSOutput vsOut) : SV_Target0
{
    // step-5 テクスチャカラーをサンプリングして返す
    float4 texColor = g_texture.Sample(g_sampler, vsOut.uv);
    return texColor;
}

各ピクセルごとにテクスチャからUV座標と一致するテクセルの色を取得して返却することでマッピングできる。

3Dモデルのデータ構造

3Dモデルの描画も結局は三角形の集合で可能
　→三角形の描画フロー（頂点バッファー、インデックスバッファー、テクスチャ）で行える

1頂点当たりのマテリアル情報、頂点バッファー、インデックスバッファーが全頂点分あれば3Dモデルデータとして役割を果たす

wogli様のBlenderで始めるセルルック風キャラクターモデリングを受講しました。

https://coloso.jp/products/cgdesigner-wogli-jp

MMDモデルの操作も慣れてきた、モデリングもそこそこできるようになってきた、そろそろ人型モデル挑戦するか～！

ということで私の大好きなe-LarningサイトColosoで講座を探していた所ビビっと来たこの講座を受けてみました。

※ 使用Blenderバージョンは4.4です。

完成図

基本的に模様はメッシュかシェーダーです。
やや簡易的な部分が多いですが、全体的に違和感は出ない程度のクオリティにできて良かったです。

もちろん講座で丁寧に解説頂いており、それを真似て作っているわけですが、自分で手を動かしてここまで作れたのは嬉しいです。

所感

〇 よかったところ

・人型モデル素体の基本がわかった
・モデルの作り方、構造的に意識しないといけない箇所がわかった
・モデリング力が向上した
・今まで触っていなかった(知らなかった)Blenderの機能を知れた
・講座の手順に対する疑問点から自身の知識の正誤が更新できた

〇 よくなかったところ

・Blenderで扱うことが大前提の作成方法だったため他移植を考慮すると配慮不足な点が多かった
・イラスト調以外で見た時にクオリティが不足している箇所が多かった

当然ですが、人型モデルの作り方は分かりました。
ただこの方法が絶対ではなく、あくまで手順の一つという解釈をしています。
例えば肘、膝などの曲がる個所のメッシュ構造について、曲げても違和感のないような作り方があると思いますが、今回は特に言及されずとりあえず破綻しない程度でした。

この辺りはイラスト調という前提だからか、受講ターゲットが初級なのか不明ですが、逆に最低このメッシュでも大丈夫、というラインが分かったのは良かったです。

模様が全てメッシュだったのは個人的にあまり嬉しくありませんでした。

そもそも模様をメッシュで作る理由ってあるんですかね？

メッシュに沿ってシェーダーかけたい？
　→別にその模様でマスクすれば済むのでは。

テクスチャ作れるほどイラスト力がない？
　→分かるけどウェイトとか調整とか難しくなるデメリットの方が大きいのでは。

一番嫌なのは後から模様を変える時にすごい手戻りが起きることですね。（この辺は業務に当ててるからなせいですが。）
後から突然 模様変えて！ なんてざらに言われるのにいちいちメッシュでやってたらその度にウェイトし直し、最悪対象のオブジェクト全体の再作成になりますよね。
そのデメリットを取ってまでメッシュにすることは嫌ですね。

講座として、一つの方法として、今回はそう思って進めました。

髪については完成後も疑問が残りました。

まぁ角度つけても大して違和感がないのでいいのかな。とも思いましたが、ちょっと雑過ぎるのでは...？

インナーカラーが内側メッシュなのはいいとして、後頭部との接続が一切ないのはどうなんですかね。
今まで見てきた3Dモデルがちゃんと後頭部から生えてるのに対し今回は違ったので違和感を感じているだけかもしれませんが。

分かったことはこの方法では風などの髪の表現に制限がかかることです。

今回は外側の髪だけにリギングしていますが、これでは大きく揺らすと内側の作り込んでいない部分が丸見えになるので良くないです。

これではダイナミックな表現に制限がかかることになるので良くないのではと思いました。

これも一つの方法としてはありと思いますが、使いどころは難しい気がします。
自分用ならこれでいいのかな？

最後に

"一通り人型モデルを作れた" という経験自体に価値があると思った今回の受講でした。

やはり人型モデルとなるとクオリティや方向性によってピンキリなので独学だと難しいイメージがあります。
今回の講座は私の好きなセルルック調で、初級向けの講座だったので丁度良かったと思っています。

一部不満はありますが、"ここはこうだとこうなってだめだな"と気づけるのはいいことと思っています。
次作るときは今回の不満点をなくしつつ作れればと思います。

（やるなら推しのモデルか自身のモデルかなぁ、イラスト依頼...してみる？？）

追記：Blender4.4の補足

レンダリング周りを4.2辺りで一新したみたいですね。
https://wiki.blender.jp/Dev:JA/Ref/Release_Notes/4.20/eevee/eevee_migration

その影響でBloomの項目が消滅してます。
変わりすぎだよ～～～困った。

ということでCompositingからGlareを混ぜて出力させました。

他にも所々困る個所はありましたが記憶に残っている大きく困った点はこれだったので残しておきます。