作業環境
- Windows 10
- Unreal Engine 5.3
- Unity 2021.3.37f1
- Core RP Library 12.1.14
- Universal RP 12.1.14
- Visual Studio 2022 (17.8.3)
- Visual Studio Code
- RenderDoc v1.32
始まり
Unity URP を RenderDoc でキャプチャした時のことです。
むむむ。
何故でしょうか。
筆者の記憶ではシェーダーとアセンブリを切り替えられた気がしたのですが Source debugging Unavailable となっています。
――結論としては（たぶん）記憶違いでした。
PackageCacheからURPをPackagesにコピーしてenable_d3d11_debug_symbolsディレクティブを立てれば余裕で見れました。
Unreal EngineもConfigを書き換えないとアセンブリしか読めないので同じですね。
最近はUnreal Engineばっかり使っていたので完全に記憶が飛んでいました。
別にUnityを触っていない訳ではなかったのですが、ピクセルデバッグするほど深掘りすることはなかった。
さて、本題。
手順としては単純ですが、プロジェクトを用意した初期段階やバージョンアップした時にしか触らない手順って大体忘れます。少なくとも筆者は覚えていた試しがないです。
そんな訳でメモ帳代わりに残しておきます。
Unreal Engine
Lightsシェーダーをピクセルデバッグする場合
Lightsパスをピクセルデバッグすると有効化手順を踏んだにも関わらずほぼほぼアセンブリが出力されます。
これはUpdateLightDataColor関数が計算に含まれると発生します。
発生箇所と抑制方法は把握していますが、その理由については調査したことないので不明です。
抑制方法は以下の2行をコメントアウトします。
コメントアウト後にUEを再起動してキャプチャすると見れるようになっていると思います。
コメントアウトすることで現象は抑制されますが、UpdateLightDataColor関数内の処理が適用されないため、一部描画表現が適用されません。面倒ですがデバッグする時だけコメントアウトするのが無難でしょう。幾つかの組み合わせを調べれば簡単に直せそうですが、筆者の環境だと本関数では1.0が乗算されるだけで、見た目に影響を及ぼしていない要らない子だったので、調べる気が起きなかったです。
Unity URP
メモ
画像ではcom.unity.render-pipelines.universal@12.1.14もコピペしていますが不要です。
シンプルに筆者がURPのコードを編集しながら確認したいことがあったので、一緒にお引越ししているだけです。
大体はCommon.hlslをインクルードしているので、ここにシェーダーデバッグのディレクティブを立てておくと楽々です。
ディレクティブを立てたのにSource debugging Unavailableから変わらない場合は、Package ManagerからCore RP LibraryがCustomになっているか確認しましょう。変わっていなければ引っ越しミスしています。それ以外の理由は遭遇したことないので知らんです。
雑談
UnityはSceneColorに書き込んだ数値が素直に出力されていいですね。
とっても親切で且つ直感的な挙動で好きです。
対してUnreal Engineは、PBR向け＆UE独自機能で中間層が複雑になっているので、全く持って素直じゃありません。その複雑な対価を払うことでLumenやSubstrateなどが提供されているので一概に悪いとは思いませんが、想定環境に反したセル・トゥーン開発を強行すると度々喧嘩になる印象です。Unityなら簡単に出来るのにUEだと複数の手順を踏むというケースが多すぎます。
マジでリアル調な開発においてはおそらく最強のゲームエンジンだと思うんですけど、セル・トゥーン開発においては障害が多すぎると思う。
ルックに合わせて使い分けるのがストレスフリーなんでしょうが、描画都合だけで決められる問題でもないでしょうから、色々と難しいんでしょうね。
ここから先は年齢制限のかかっている作品を取り扱うページとなります。
表示する
恋愛アドベンチャーゲームの読み上げツールの進捗状況
今年の後半からゲームプレイを3年ぶりに本格的に再開しようと意気込んでから完成に向けてちまちま書いておりますわ。
諸々の機能は揃っているので後はTkinterでそれっぽいツールを作れば完成ですわ。
見た目的にはWPFを使いたいところですが、目標の7月をオーバーしそうなので一旦は諦めました。
それにしてもGUIって難しいね。少なくとも筆者はセンスないわ。配置が訳分からん。
コレジャナイ感に苛まれて苦しかったので、天使騒々のボタンを再現して気分転換してたわ。
ちなみに検出と分類精度は領域特化なデータセットを突っ込んでいるので割と最強です。
各作品の共通ルートまでなら失敗なし。
面倒な筆者の拘りとして実作品のスクショデータをデータセットに含めることは一切していないの。
それでこの精度という自己満足も達成。
筆者が頑張ったというよりはアーキテクチャを公開している天才方のお陰なんですけどね。
筆者もそっち側に行きたいけど、それにはまだまだ勉強が足りませぬわ。
オトメきは体験版が公開されているっぽいので、必要なフォントだけ確認して学習済みモデルを作りますかね。
セレオブの体験版公開もゆっくり待っていますわ。正直体験版はまだいい、店舗特典画像は流石に公開してくれと思った。見切り発車過ぎるでしょ。業種が違うから事情知らんけどさ。
思ったけど世界観の構成にスラム街ってベター or 流行っているんですかね。セレオブもオトメきほどじゃないけど、荒れたところ出身だよね。低層から這い上がる系は話が組みやすいと思うから分からなくはないけど。
片方は湊くんに容姿が似ていて一目惚れな作品、片方はシナリオさんと声優さんが同じで且つ部分的な設定が同じで期待している作品。
個人的には新作を遊ぶよりも積みに積んだ100本以上の既存作品を遊ぶべきなのですが、まぁ、今後の楽しみが待っていると考えればいいか。
オトメきの体験版ページ見てきたけど、キャラクター名が特殊なパターンかい。検出的に面倒なのよねぇ。
でもご安心、オトメドでそれは踏んだので、キャラクター名の識別には画像の絶対値差分による原始的な分類もあるのですわ。なお、GUIの実装が面倒すぎて機能だけで各画像パスと分類後のキャラクター名はコード直埋め込みという愚行。
くっ。いま思うと半年前に湊くんの音声データを元にTTSモデル作っておけばよかった。。。いやー分からんじゃん。こんなに出演者が似たような作品がまた出るなんて。にゃはー。割と楽しみ。
世間はGPT-4oとかで盛り上がっていますが、プログラマ的にはこういうものは使うよりも、自分で作ることが楽しいのですよね。同業なら気持ちわかるっしょ。んで且つよ、それを趣味に活かせる瞬間、マジ最高よ。脳汁どばーよ。
あくまで趣味の話ね。業務で必要な場合は当然別の話。とはいえGPTとかSDはデータセットが完全なクリーンじゃないだろうから表立って使ってますとは言いにくいだろうけど。扱える知見があることは大事とは思う。
さてと。
体験版を取ってきて、学習済みモデルを作って、OCR精度結果に一喜一憂する時間を作りたいので、ばいばい。
