Vibe Coding でワイヤーレベルの図示化に Playground を書かせてみた

週末ふと思いついたアイデアを、Claude Code を使ってかたちにしてみようと思った。

仕事でも Claude Code を使っていて、実装は99%手で書くことがなくなったのだが、どのように指示しているかというと、まず要件レベルのドキュメントを Claude に与え、詳細設計レベルの仕様書に落とし込んでもらい、それをもとに質疑を交わしたり認識合わせを経てから、コーディングに落とし込んでもらっている。

いっぽう個人開発は、よりふわっとしたアイデアからスタートするので、数行のアイデアメモから始まる。これを実現するために、AIにとっての不足情報を質問形式で引き出し、それに答えながら構想を詳細化していく。

ちなみに筆者の場合、この質疑応答はチャット上ではなくテキストファイル上で行っている。質問が書き出された .md ファイルに筆者が回答を記載し、追加で質問があればさらに書き込んでもらい、、というラリーをひたすら繰り返す。質疑以外のコミュニケーションもコンテクストに溶けないよう、かたちに残るファイル上で行っている(特別な方法ではないはずだ)。

ドキュメントベースでレビューできる内部ロジックに限らず、外見の画面イメージがAIと認識が揃っているかも、本実装の前にきちんと把握しておきたい。そこでAIに図示を依頼すると、大抵ASCIIアートで描いてくるきらいがある。しかし文字列で表現できるレベルなんてたかが知れているし、そもそも表示が崩れまくるので使い物にならない。

そこで Swift Playground でモック実装させてみたら、これがうまくいった。例えばオーディオデータを扱う筆者のアイデアは、波形を描画して、範囲選択をし、編集操作を行う要件がある。これを人間の手でサクッと作るのはガワだけでも結構大変だ。だがAIなら、アイデアの壁打ちを始めてからたった10分足らずで次のような絵に仕上がった。ほぼ一発で、バシッと筆者のイメージを具現化してくれた。

あとはボタンの配置がどうの、配色がどうのと細かい部分を指示し、随時 Preview 上で反映を確認しながら、ワイヤーレベルのデザインを固めていった。


ちなみにこのアイデアだが、アプリとしてきちんと形にしようと思うと、音声処理に関する実装知識が必要だし、インタラクションや機能の複雑さもあるため、日曜大工感覚で1ヶ月くらいは掛かるだろうと見込んでいた。が、Claude Code を使えば日曜の夕方2時間程度でほぼほぼ完成形までこぎつけられた。(といっても、今更このスピード感に驚くこともないのだが、、)

この時点でバグは多いものの、実際に手に取って動かせることで、UIやインタラクションの課題が浮き彫りになり、アイデアのブラッシュアップに繋げられた。まさに Vibe Coding 的な体験だった。

Screenshot

claude コマンドの実行に失敗

これまで Cursor を使っていたが、仕事が Claude Code 1本なので、個人開発でも使おうと Claude をインストールしたが、claude コマンドの実行時で失敗してしまった。

$curl claude
warn: CPU lacks AVX support, strange crashes may occur. Reinstall Bun or use *-baseline build:
  https://github.com/oven-sh/bun/releases/download/bun-v1.3.6/bun-darwin-x64-baseline.zip
error: Invalid DNS result order.

Terminal.app が Rosetta で起動する設定になっていたのが原因だった。チェックボックスを外して再度実行したら成功した。

聴講メモ:RAKUS AI Meetup Vol.2

楽々精算のRAKUSさんが自社のAI活用ナレッジを共有。開発利用にとどまらず、組織浸透における課題や施策であったり、プロダクトへの組み込みであったりと幅広いテーマでとても聞き応えあった。特に組織内のAI活用を活性化するための試行錯誤は、巷では中々聞けない内容で、今後取り組んでいきたい課題のひとつでもあったので知れてよかった。

イベントページ:https://rakus.connpass.com/event/378121/


全エンジニアのAI活用状況を可視化する~LookerStudioを用いたアンケート分析と今後の推進策~

  • AIネイティブ開発化の促進ミッション
    • データの持ち方〜意思決定プロセスまでAIを全面活用する
    • 当初戦略:理想定義と現状とのギャップを埋める
    • 挫折要因:技術進歩が早すぎ、数日で陳腐化
    • 合意形成の難しさ:メンバー間で目指すべきレベル感が異なる
  • アプローチを変更:理想の定義から、現在地の定義へ
    • 次の一手を打つために、意思決定に役立つ情報を届けること
  • 300人開発組織の見える化、誰でも使える分析基盤
    • サーベイ設計は3つの観点に着目
      • ヒト(ユーザー属性)
      • コト(開発工程)
      • キモチ(自己評価、環境整備度合い、成果物への貢献割合)
    • Google Forms でサーベイ実施
  • 分析基盤の作成:Google Looker Studio
    • 無償範囲でも使える
    • 開発部だけでなく役員の利用も想定
    • メンテしやすさ
    • 閲覧者のドリルダウンしやすさ
  • 可視化重視ポイント
    • 分析対象の傾向を見える化:若手が多いとか、バックエンドが多いとか
      • 対象者を絞って不可ぼれるように(もっと知りたくなる仕掛け)
    • プロダクト横串で比較しやすく
      • 自分のプロダクト・チームが他所と比べてどうか?を知りやすく
      • どのチームが何に長けているか見やすく、ナレッジ共有の促進に繋げる
    • プロダクトごと俯瞰して見える化
      • リーダー陣が自担で把握できるよう
  • 定性的評価の曖昧さ
    • 定量に比べて入力者の感覚でばらつきあり
    • 自己評価の低さから、実態より不当に低く入力されたり
    • 定性的値は、時系列でウォッチして軌道修正にりようすべし
      • 経過観察を前提にしたサーベイ設計、分析基盤を準備するべし
      • 施策の成功度合いの計測に利用、など
  • 強みと弱みから、どこから手をつけるべきか?打ち手の優先順位をつける
    • 現場との対話に重きを置いた
      • 立ち止まっている人に、障壁をヒアリングし特定
      • 使い倒している人に課題と改善案を共有し、クリティカルな課題を選ぶ
        • 解消していくことで、協力的になるスパイラルを産む
    • 具体的な一手の例
      • Quick Wins (即効性重視)
        • 市街ツールの利用申請フロー短縮
        • 開発作業動画の共有
      • Systematic (組織的整備)
        • AI特化ポータルを公開
        • プロダクト組み込み時のセキュリティルールの策定
  • Q&A
    • 現状を可視化して想定外だった気付き
      • 特定部署のとある人の全社への共有が多い一方、意外とチームの利用状況が連動していない:周囲への実践レベルの共有に至っていない?という仮説
    • 可視化が入ったことでマネジメントの意思決定への変化
      • アンケート可視化+ヒアリングがエビデンスになり、踏み切れなかった決断の後押しになった

仕様駆動開発の組織的定着に向けた取り組み~『楽楽電子保存』開発チームの事例~

“聴講メモ:RAKUS AI Meetup Vol.2” の続きを読む

Blue Note Tokyo の臨時席はどうなのか

昨夜はじめてブルーノート東京の臨時席を体験してきた。事前にネット検索してどんなものか調べてみたが、あまり情報が出てこなかったので、これを機に記しておく。結論としては、普通にオススメできる。


先日ロン・カーターの公演を観にブルーノート東京へ行った際、クラブ会員特典で来場ポイントが7貯まるごとにもらえる招待状(インビテーション)をいただいた。この招待状で(条件付きだが)1公演のミュージックチャージが無料になる。

いちいち、あと何公演で招待状もらえるかなんて数えていないので、いつも不意打ちで受け取ることになる。また招待状の期限はその日から2ヶ月間なので、その限られた期間の中で行きたい(し行ける)公演を探すことになる。今回は翌週にケニー・ギャレットのステージがあったので幸運だった。

基本的にいつもはステージに近いアリーナを選ぶし、加えて会員特典で先行予約するためたいてい最前テーブルを割り当てられることが多い。しかし今回は公演直前で、さらにケニー・ギャレットともなると当然空席はない。というわけで、唯一の空席であった(電話では最後の1席と告げられた)臨時席を、50回近いブルーノート歴で初めて選ぶことになった。

招待状の予約は電話で行う必要がある。電話口の予約ではウェブにはない「2階席」を予約することも可能で、今まで2階で観る機会もなかったし、どちらにしようか迷ったのだが、電話口のオペレータは暗に臨時席の方を勧めてきた。話によると「臨時席を好んで選ばれる方もいる」と言うが、会場最奥で椅子しかない席だ、本当だろうか、、?

と半信半疑で当日迎えたが、結果としてオペレータの助言は確かだった。

臨時席は、入り口側のレジ脇に6つほどスツールが並べられているエリア。実はここはカウンターを背にしているので(カウンターがあることを知らなかった)、ドリンク・フード置き場は必然的にステージ向かって真後ろ側になる。つまり、飲食を置いたり取ったりするには、都度背を捻る必要がある。そこは難点。とはいえスツールの座り心地は申し分なく、1時間半の公演で座り疲れることもなかった(30代後半男性の感想)。ちなみに、老若男女、カップル客もいたので、誰でも馴染めそう。

席からの光景。通路の突き当たりで、これは運が良かった。なぜならアーティストの通り道で、入退場時に間近で見ることができたからだ(握手は叶わず)。

この席位置で特に恩恵を得られるのは、遮るものなくステージを一望できることだろう。これまでアリーナを積極的に選んできた筆者だが、今回改めてその欠点に気がつくことができた。アリーナは、席によっては前の客に遮られてまともに演者が見られなかったり(ハズレ席)、角度によっては譜面台やピアノの天板でですら演者の姿が隠れることも珍しくない。また前すぎても、その迫力と引き換えに音のバランスが偏ったり、ステージを一望できず演者同士の掛け合いを見失ったりすることもある。一方臨時席は、アリーナより高くステージから離れる分、基本的にその心配は不要だろう。

また今回のようなセクステット編成だと、なおさらステージを俯瞰できた方が、その全体像を余すことなく味わえたと思う。今回はなかったが、アーティストによっては客席外周を練り歩いてパフォーマンスすることもあり、その時は間違いなく臨時席の前を通るので得である。席料払ってアリーナで観るより、場合によってはむしろ体験を上回る可能性がある。(ちなみに2024年のケニー・ギャレットはアリーナ中央最前で観て、もちろんそれはそれで素晴らしかった。が、体験としては今回と比べても甲乙つけ難い。)

いくつか注意点(予約時オペレータからの案内を含む):

  • 入場は開演の5-10分前(と電話で案内されたが、15分前に通していただけた。ここは入場の状況にも依りそう)
  • 席は先着順ではなく、指定席同様事前に決定される(公演前日のメール案内はなく、フロントでシート番号を渡される)
  • ふつうにオーダーは必須
  • 席の目の前は基本スタッフらが慌ただしく行き来する

最後のスタッフの行き来については、個人的にはまったく気にならなず、それどころかバー特有の活気ある雰囲気を楽しめたし、普段見ることのないスタッフの(公演開始前、開始後〜終盤と変わり行く)動きを知れて、むしろプラスだった。


まとめると、臨時席といえども、まったくあなどれないということ。カジュアルに肩肘張らず楽しみたいなら、むしろ全然アリだと思った(もちろんテーブル席で余裕ある時間を料理と共に楽しみながら過ごすのも◯)。

ちなみに「臨時席」という名前だが、調べた限りだとすべての公演に臨時席が用意されているように見えた。

Happy People

二酸化炭素濃度測定器を購入した:日本精機 CO2Lamp

昨年末暖房をつけ始めたあたりから、仕事中のコンディションが非常に悪い日が続き、その原因のひとつに部屋の二酸化炭素濃度があるだろうと考えていた。二酸化炭素濃度の計測は前々から興味あったが、計測器を買ったことがなかったので、これを機にアマゾンで購入してみた。

二酸化炭素濃度測定器[CO2ランプ]|CO2Lamp|CO2濃度測定器|日本製|日本精機|新潟県感染症対策認証制度対応製品

二酸化炭素濃度測定器で調べると無限に製品が出てきて何を選べば良いか分からないのだが、この日本精機 CO2Lampは、他の計測器と異なって数値ではなく青黄赤の3色カラーランプだけで現在の状態を示すのに惹かれて、かつメイドインジャパンだったので選んだ。およそ6千円が、ポイント使って半額以下で買えた。

届いてさっそく自室で計測しみたら、すぐさま真っ赤(2000ppm以上)に点灯して、換気の悪さが露呈した。

真っ赤なランプは、10分ほど窓を開けたら青(400-1000ppm)に戻った。青に戻っても窓を閉めると割とすぐに黄色(1000-2000ppm)に戻るため、自室で青ランプを持続するのは難しそう。

手のひらサイズで軽く、バッテリーは内蔵していない。そのため、基本は USB-C で給電して使用する。単四電池x2 も同梱されていて電池で駆動もするが、取扱説明書に書いてある通り、乾電池での連続使用はせいぜい8時間程度で、あくまで予備に留めるのがよいらしい。

使い勝手だが、3色ランプで示してくれるのは一目瞭然で分かりやすい。が、現状を知ると欲が出て、3段階以上の精度で知りたくなってくる。そういう意味では、400-1000, 1000-2000ppm と刻みが広いのは難点。

また、本製品サイトの紹介だとユースケースがオフィスや教室に偏っており、意外にも家庭用途が示されていない。実際に使ってみてその点は、仕事部屋やリビングだと問題はないと思った。が、

  • ランプの明るさが、最弱でも(3段階で調整可能)そこそこ明るい
  • 青→黄、黄→赤 と段階が上がるたびに電子音が鳴り、OFFにできない

という点で、寝室で使うには難がありそう。


とはいえ、一目瞭然のわかりやすさから早速寝起きに1度換気するようにはなったし、午後イチにも空気を入れ替えるなど、換気の習慣作りにはさっそく役立ち始めている。

手のひらサイズ

2025年を振り返る

大晦日なので振り返ってみる。

あらためて2025年始にたてた目標を思い返すと、こんな感じで2025年を締め括った。

  • 2024年の転職を機に始めた勉強会参加継続(月5回ペース)
    • 👍できた
  • これまでしてこなかった勉強会への登壇(理想は年5本)
    • 👍4回登壇、1本プロポーザル補欠採用
  • アプリリリース(理想は3つ)
    • 😭せず
  • ビッグバンドへの参加
    • 👍できた
  • 楽器毎日練習、毎週どこかしらでセッション参加
    • 😐後半は練習もセッションもサボりがち

2024年10月に現職転職するまでは、開発コミュニティに顔出すことはほぼなく、登壇なんて恐ろしくてできない、と思っていたところから、try! Swift スタッフ参加をきっかけに人とのつながりが増えて、今年後半から登壇にもチャレンジできた。

新技術である Foundation Models や visionOS を使った個人開発がはかどったのが良かった。登壇駆動開発とはよく言うが、まずは登壇にエントリーしてしまって、そこに向けて平日夜や休日も返上で学習や開発にいそしむのは案外苦ではなかった。また WWDC 後は Apple が自社主催でワークショップを開催したことも、学びに弾みがついてありがたかった。

こうした技術キャッチアップが手元のプロトタイプに閉じてしまったのは、登壇ありきだとまずはプレゼンとして形にすることが、プロダクトとしてリリースすることよりも優先度高くなったためで、実際にリリースは二の次に考えていた。が、visionOS TC での主催服部さんの言葉が、アイデアをかたちにしてデリバリすることにも意義があると捉えなおすきっかけになった。来年こそは作りっぱなしでなく他者に体験してもらえるかたちに落とし込むまでもっていきたい。

他にも、今年は仕事では Android 開発にも手を広げられたのが良かった。あと想定していなかったが、ブログ更新が習慣化して年間150本に迫る勢いで投稿できた点も自分を褒めたい。


音楽趣味は、昨年足繁く通っていた高田馬場イントロも体調不良をきっかけに足が遠のいてしまった。が、その分ビッグバンドに加入してしたり、よそのセッションには通い続けていたので、演奏機会自体は逆に増えていたかも。

さらに、ビッグバンドでは秋頃にはお褒めいただくことが増えたり、チャージありのステージで演奏する機会をいただいたり、どちらもふんわり目標にしていたことが叶えられたので。客観的にも上達の兆しを感じられた1年だった。


数年前から、こんな感じで年始に目標立てて、年末に振り返る、みたいなことをしているが、中々良い感じに回っている実感もあるので、2026年も何かしら掲げてみたい。ここまでの話とまったく関係ないが、ずっと行ってみたいと夢見ている国に来年こそは海外旅行したいなーと思っている。

ブログを習慣化するコツ

今年2025年は、記事数が150に迫るほどブログ更新できたので、そのコツについて書いてみる。

そもそも、筆者のブログをつける目的は、インプットーアウトプットのサイクルを回すためで、それ以外の承認欲求だとかマネタイズだとかはない。むしろ誰にも読まれずひっそりと書いていたいとすら思う。

誰にも読まれたくないのなら、外部公開しなくてよくない?と思われるかもしれないが、誰かに読まれるからこそ一定の品質と正確性を担保する原動力にもなるし、そのレベルで積み重ねた結果が、個人的な備忘録的価値だけでなく、他者に向けた取り組みの可視化としても、結果的に自分に返ってくると思っている。

昔つけてた Medium の記事 も今見返すと面白いテーマに取り組んでいたと思えたりする。

こうした期待値のうえでブログを継続するには、書き出し時の障壁や心理負荷をいかに軽減できるか、だと思っている。その変数になりうる要素をいくつかピックアップする。

投稿媒体

技術ブログの媒体には、Qiita や Zenn をはじめとした専用のプラットフォームや、技術ブログとして人気の高いはてなブログがある。

こうしたプラットフォームには、すべてでないにしろ新着エントリなどプラットフォーム側の機能で記事をキュレーションすることがあり、筆者はこれが苦手だ。あくまで自分のペースで記事を投稿したり編集したり削除したりしたい。そこで WordPress を使っている。

上述のサービスは書き出しのセットアップが不要で、技術ブログに不可欠なコードブロックもブログエディタに採用しているからとても使い勝手が良い。WordPress にも、デフォルトエディタ Gutenburg にコードブロック機能があったと思うし、プラグインを使えばより高度なカスタマイズが可能なので、今の所困っていない。

Highlighting Code Block の使い方 | LOOS,Inc.

文体

文体には、<ですます、である>といった文末表現や、<私、僕、筆者>に挙げられる主語の選び方が含まれると思うが、地味にこれらも自分にとってしっくりくるものを選ぶと、書き出しがスムーズでよいと思う。

筆者は上述の通り、他者に意識的に何かを伝えるというテイで書いていないので、敬体でなく常体を使っているし、僕、私といった人格をなるべく排除したいから「筆者」という仰々しい主語を選んでいる。

こうした選択は過去いくつもブログを作っては消し、を繰り返す中で収斂していったもので、学生時代につけていたはじめてのブログは全然スタイルが違う。

フォーマット

ある程度固定しておけば、書き出し時に悩まなくてよいのでおすすめ。このブログの場合、勉強会参加時のレポート(聴講メモ)や WWDC のセッション要約はほぼフォーマット固定としてるので、テンプレをコピペ改変して書けるようにしている。

勉強会といえば、参加時にフォーマットに沿ってサマリを書き綴って、帰宅してほぼほぼそのまま投稿できるようにもしているので、さらに手軽。

シリーズ化

フォーマットに似ているが、たとえばある題材を扱う時、シリーズ化して複数回に分けて投稿すると、日々続けるモチベーションにもなって良かった。最近でいえば Shader Graph についてノードごとに調べたりしていた。

インプット計画

WWDC のセッションもそうだが、シリーズ化することで明日の題材が自ずと定まるので習慣化もしやすい。そこでシリーズ化した時点で、何をどのペースでインプットするかをリスト化して書き出しておくことで、次やることに悩まなくなるので、より習慣化しやすくなると思う。

例えば、WWDC の観たいリストをこのように書き出して、毎朝ひとつずつ消化するようにしていた。

おまけ:可視化

心理負荷とは関係しないが、このブログの右ペイン(モバイルだと最下)に、月毎の投稿数やカレンダーが表示されていると思うが、これによって投稿ペースを可視化できてモチベートできる効果があったので、習慣化したい場合はおすすめ。


で、ここまでしてブログへのアウトプットを習慣化してみてどうだったかというと、いくつかメリットがあったのでやって良かったと思う。

  • ブログ投稿を軸にしたインプットーアウトプットが習慣化した
  • 学習の過程やとりくみが可視化されることで自己肯定感が向上した
  • 勉強会などで知り合った方にブログを読んでいただけ、会話のタネになった

特に3つ目は、読んでくださっている方の存在がはげみになるのだと気が付けて良かった。会話の中で、ブログで表にしている技術以外のテーマも認知いただけただけて、書いた甲斐があった。

が、こうしたアウトプット・ドリブンな方法はネガティブな側面もあった。

  • アウトプット偏重になるとインプットに時間が割けなくなる

ブログひとつサクっと書ける方ならよいが、筆者は物書きが苦手で、ひとつひとつにかなり時間を割いている(だからこそ上述のような省力が必要)。投稿数を追うと、自分で手を動かす試行錯誤がおろそかになってしまい、完全に本末転倒だった。

というわけで、個々人にあったちょうどよい投稿ペースも見定めた方が良さそう。筆者の場合は週2-3くらいだろうか。


いまのところプラスが大きいので、来年もほどほどに継続していきたい。

Reality Composer Pro の Share Graph で使えるノードを眺めてみる(Math編)

続き:
Reality Composer Pro の Share Graph で使えるノードを眺めてみる(2D/3D Procedural/Texture 編)
Reality Composer Pro の Share Graph で使えるノードを眺めてみる(Adjustment 編)
Reality Composer Pro の Share Graph で使えるノードを眺めてみる(Application 編)
Reality Composer Pro の Share Graph で使えるノードを眺めてみる(Compositing 編)
Reality Composer Pro の Share Graph で使えるノードを眺めてみる(Data 編)
Reality Composer Pro の Share Graph で使えるノードを眺めてみる(Geometric 編)

Math は演算用のノードで、名前を見たら分かるものが多い。その中でも個人的にぱっと見わからないものや興味をそそられたものだけピックアップしてみる。線形代数は概念は知っていても英単語になると分からないことがわかった。

  • Atan2
  • Clamp
    • In が Low-Hight の範囲を超える場合、最小値 or 最大値それぞれの側に値を丸めて、範囲を超えないようにする
    • 概念は Adjustment 編 にも登場した
  • Magnitude
    • ベクトル長さ
  • Dot Product / Cross Product
    • 2ベクトルの内積/外積
  • Transform XXX
    • スペース間の値の射影
  • Transpose
    • 転置行列
  • Determinant
    • 行列式
  • Place 2D
    • UVテクスチャ座標系の変換、テクスチャにアフィン変換掛けたい場合に使うっぽい?(例示あり)
  • Safe Power
    • 普通の Power は X の累乗で結果の符号は乗数が偶数か奇数かによって左右されるが、Safe Power は X の符号が必ず反映される
    • Safepow(X,Y) = sign(x) * pow(abs(x), y)
  • Hyperbolic XXX
    • 双曲線関数
    • Hyperbolic Tan (tanh) は、0を中心としたsigmoid関数のようなかたちで、イージングなどに利用
    • Inverse Hyperbolic Tan は 逆双曲線関数

ここまででグループごとに ShaderNode について調べてきたが、どんな役割のノードが存在し、どんな知識が足りていないのか、おおまかにイメージが掴めたので、このシリーズはいったん終わりにする。

Apple Watch Hermès Faubourg Party クリスマスバージョン

Hermès 版の Apple Watch にはこの秋に追加された文字盤 Faubourg Party があるのだが、不意に見慣れない文字盤が表示され、クリスマス・イブであることを思い出した。

Apple Watch の画面録画はアクセシビリティ機能のひとつ「Apple Watchミラーリング」で可能。

スヌーピーにもクリスマス限定の文字盤が表示される。


Hermès Faubourg Party は、誕生日も祝ってくれた。

粋な遊び心がアップルらしい、こうした限定文字盤は登場が不意すぎて見逃してしまいそうになるし、気付けたとしても二度目は中々お目にかかれない。ただし次の法則がありそうで、繰り返し表示を再現することが可能。

  • 対象日の文字盤初表示時に現れる
    • ただし、天気などに応じた文字盤が優先されることもある
    • その時は、一度画面をオフにして(待つか、手で覆う)、画面を再点灯すれば良い
  • 文字盤を2、3度別のものに切り替えることで、対象文字盤の状態がリセットされる
    • 一度表示し終えても、2、3隣の文字盤に切り替えて、再び戻すと、上述の条件に従って再出現させることが可能

Reality Composer Pro の Share Graph で使えるノードを眺めてみる(Geometric 編)

続き:
Reality Composer Pro の Share Graph で使えるノードを眺めてみる(2D/3D Procedural/Texture 編)
Reality Composer Pro の Share Graph で使えるノードを眺めてみる(Adjustment 編)
Reality Composer Pro の Share Graph で使えるノードを眺めてみる(Application 編)
Reality Composer Pro の Share Graph で使えるノードを眺めてみる(Compositing 編)
Reality Composer Pro の Share Graph で使えるノードを眺めてみる(Data 編)

Geometric Shader Graph group は、説明文をそのままに理解すると、GPU がグラフを適用する際に現在処理しているデータ値を取得するノード。座標や法線ベクトル、接線などが取得可能。Reflect や Refract ノードは、現在の値を元にベクトルを修正することもできる、とのこと。

つまり、モデル表面の各点ごとに取得した幾何属性から、何を描画するのか(色など)を決定できそう。


  • Normal:法線ベクトル
  • Tangent:接線ベクトル
  • Bitangent:Normal × Tangent (Normal, Tangent それぞれに直行するベクトル)

Bitangent のイメージが掴めずに調べてみると、法線はモデル表面に対して一意に決まることが分かりやすいが、Tangent は UV の U 方向、Bitangent は UV の V 方向らしい。(バイタンジェント、かと思ったら ビタンジェント と読むっぽい)

Normal、Tangent、Bitangent から得られるTBN行列を用いて、ノーマルマップをワールド空間に変換する、らしい。

UV座標系 | CG・映像の専門情報サイト | CGWORLD.jp
📐TBN行列の作り方|タンジェント空間と法線マップをGLSLで理解する|批評テレビ/文学フリマ東京42出展

そして、そのままだと平すぎるポリゴンに、詳細なでこぼこ(凹凸や傷など)を与えるのがノーマルマップ、ノーマルマップはあくまで接線空間のローカル座標なので、これをワールド座標に変換するために使うと。なんとなくイメージできた。

で、Texture Coordinates は、テクスチャのUV座標をそのまま返す。モデル表面の各点が、テクスチャ画像のどの座標に対応するかを知るためのノード。


Geometry Color は、モデルのジオメトリに埋め込まれた頂点カラーを取得するもの(マテリアル色ではない)。

Geometry Property は、ジオメトリに定義されたカスタム属性を読み取るもの。
Data グループにあった Primvar Reader に似ている気がした。

ChatGPT によると、

結論から言うと、この 2 つは 「同じものを見ているが、立ち位置と責務が違う」 です。

Primvar Reader は「primvar を読むための専用ノード」
Geometric Property は「ジオメトリ属性を“汎用的に”引くためのノード」

両方とも「ジオメトリにぶら下がったデータ」を読む点は同じですが、用途・安全性・設計思想が違います。

Primvar Reader は、読む対象が明確に USD の primvar に限定されるのに対して、Geometry Property はこれに Geomprop や Custom property を含むカスタム属性全般を読み取れる、という違いがあるらしい。


Reflect, Refract (RealityKit) は、処理中の天の法線ベクトルに対して、物理的法則に基づいた変換を加えるもの。

  • Reflect:反射方向を算出。鏡や金属、水面の表現に使用
  • Refract:屈折方向を算出。Eta が屈折率 (屈折率の比)。ガラスや水面など透明な物質の表現に使用

屈折と聞いて、ばんじゅん🍓さんのこのプレゼンを思い出した。Refract はここでは使っていなさそう?ちゃんと見てみる。