[UE5.8.0][Maya][Retarget] TposeのキャラクターモデルをAposeのMannequinのモーションにリターゲットする方法

MM_T_Pose をエクスポート

Export Optionはこう

MayaにFBXインポートした状態で保存する SKM_Quinn_Simple_Tpose.ma

Tposeのキャラクターモデル(ここではfanModelのサイトからダウンロードしたものを用意した)

https://www.deviantart.com/d-presso/art/Nier-Re-in-carnation-Levannia-XPS-DL-880627377

を開いて


先ほどのTposeのFBXをインポートして

Root ( SKM_Quinn_Simple_Tpose:root_Quinn_T_pose ) のトップ のjointをスケールしてキャラクターにあわせる。

複製してフリーズする

以下ツールでスキンウェイトをコピー

SkinWeightCopy_First_Select_MeshGroup_to_Second Select_MeshGroup.mel

// SkinWeightCopy First Select MeshGroup to Second Select MeshGroup 
string $selectedArrFUllPath[] = `ls -long -sl`;
print($selectedArrFUllPath);

string $FirstSelect=$selectedArrFUllPath[0];

string $SecondSelect=$selectedArrFUllPath[1];

string $rejectArr[];

//string $inputNodes[] = `ls -type transform -long -dag $FirstSelect`;
//string $destNodes[] = `ls -type transform -long -dag $SecondSelect`;

string $inputNodes_mesh[] = `ls -type mesh -long -dag $FirstSelect`;
string $destNodes_mesh[] = `ls -type mesh -long -dag $SecondSelect`;

$inputNodes_meshlong=size($inputNodes_mesh);
$destNodes_meshlong=size($destNodes_mesh);

string $inputNodes[];
string $destNodes[];
clear $inputNodes;
clear $destNodes;
string $mesh;
string $parent;
for($d0 = 0; $d0 <$inputNodes_meshlong;$d0++){
    $mesh=$inputNodes_mesh[$d0];
    string $parentS[] = `listRelatives -parent -path -type transform $mesh`;
    $parent=$parentS[0];
    $inputNodes[size($inputNodes)] = $parent;
}
for($d0 = 0; $d0 <$destNodes_meshlong;$d0++){
    $mesh=$destNodes_mesh[$d0];
    string $parentS[] = `listRelatives -parent -path -type transform $mesh`;
    $parent=$parentS[0];
    $destNodes[size($destNodes)] = $parent;
}

print("$inputNodes= ------------------------------------------------ \n");
print($inputNodes);

print("$destNodes= ------------------------------------------------ \n");
print($destNodes);



$inputNodeslong=size($inputNodes);
$destNodeslong=size($destNodes);

string $buffer[];
string $buffer_i[];
$finded = 0;
for($d = 0; $d <$destNodeslong;$d++){
    string $destNode_name=$destNodes[$d];
    
    if($destNode_name==$SecondSelect){
            
    }else{
        print("$destNode_name= "+$destNode_name+"\n");
        
        $numTokens = `tokenize $destNode_name "|" $buffer`;
        $bufferlong=size($buffer);
        string $destNode_name_Short = $buffer[$bufferlong-1]+"";
        print("$destNode_name_Short= "+$destNode_name_Short+"\n");
        $finded = 0;
        for($i = 0; $i <$inputNodeslong;$i++){
            string $inputNode_name=$inputNodes[$i];
            $numTokens_i = `tokenize $inputNode_name "|" $buffer_i`;
            $bufferlong_i=size($buffer_i);
            string $inputNode_name_Short = $buffer_i[$bufferlong_i-1]+"";
            print("$inputNode_name_Short= "+$inputNode_name_Short+"\n");
                
            //$index=`gmatch $inputNode_name $destNode_name_Short`;
            //if($index > 0){
            if($inputNode_name_Short==$destNode_name_Short){
                //$blendShapeName = $blendshapeRet_name;
                print("$destNode_name= "+$destNode_name+" isHit!! "+"\n");
                select -r $inputNode_name;
                select -add $destNode_name;
                copySkinWeights  -noMirror -surfaceAssociation closestPoint -influenceAssociation closestJoint;
                //copySkinWeights -noMirror -surfaceAssociation closestPoint -influenceAssociation closestJoint -sourceSkin $inputNode_name -destinationSkin $destNode_name;
                $finded = 1;
            }//if
        }//for
        if($finded==0){
            $rejectArr[size($rejectArr)] = $destNode_name;
        }//if
    }//if
}//for
print("----rejected_list---start"+"\n");
print($rejectArr);
print("----rejected_list---end"+"\n");
select -r $FirstSelect ;
select -add $SecondSelect ;

適当にスキンウェイトを確認

rootとMesh 選択してFBX出力

UEへインポート

IKRig作成

IKRig設定

マネキンのほうはこう

IK Retargeter 作成

SounceにCreate>Import From Animation Sequence

MM_T_Pose選択

ポーズがそろう

Op Stack >Add Default Ops 押す とそろった

あとは必要なアニメーションを選択してエクスポート

追加で調整した作業 RootMotionを切ってエクスポートしないとだめだった

そのあとは以下を参考にしてください。

[ZBrush]ローポリからハイポリを作成する基本ステップ

ローポリからハイポリを作成する基本ステップ

ローポリモデルの準備外部ツール(Mayaなど)やZBrushで作成したローポリメッシュを読み込みます。この時点でUV展開を済ませておくと後々スムーズです。

◆間違ったインポート手順
ファイルを開くときファイルを開くでOBJ開くと「2.5dモード」がおきる。

◆正しいインポート手順は
ライトボックスからDynaSphreかなんか開いといて ツールからインポート
OBJ選択するとOK

◆右側のメニューから「ジオメトリ(Geometry)」を開きます。

◆トポロジー編集>頂点結合(頂点結合距離0.01)

◆サブディビジョンの適用(細分化)「ディバイド(Divide)」 ボタンを押すたびにポリゴン数が4倍になり、メッシュが滑らかに 1回が妥当

zbrush の2.5dモードの抜け方 

2.5Dセクションに2つありますね。だから、全部消すためにCTRL+Nをして、それからライトボックスからDynaSphreかなんか開いといて Tを押せばいいんだよ。

助けて!2.5Dにハマっちゃった?普通の3D設定に戻す方法がわからないんだよね
https://www.reddit.com/r/ZBrush/comments/19e5wvd/help_stuck_in_2d5_not_sure_how_to_get_back_to_the/?tl=ja

[UE5.8]UEをログ付きで起動

Shell

Start-Process -FilePath ‘D:\Program Files\Epic Games\UE_5.8\Engine\Binaries\Win64\UnrealEditor.exe’ -ArgumentList @(‘D:\Sandbox\BookAnimation_Codex\UE574Book\UE574Book 5.8\UE574Book.uproject’,’-log’)


Start-Process -FilePath 'D:\Program Files\Epic Games\UE_5.8\Engine\Binaries\Win64\UnrealEditor.exe' -ArgumentList @('D:\Sandbox\BookAnimation_Codex\UE574Book\UE574Book 5.8\UE574Book.uproject','-log')

UE4の場合 ログを出すので、これでShader Compileが止まってるか見えるようになる。

Start-Process -FilePath ‘D:\Program Files\Epic Games\UE_4.26\Engine\Binaries\Win64\UE4Editor.exe’ -ArgumentList @(‘D:\Sandbox\UE426ArchVizInterior\UE426ArchVizInterior\UE426ArchVizInterior.uproject’,’-log’)

[UE5][Shader]furcraeaToonLock — UE5で作る Unlit + MPC ベースのトゥーンシェーダ

Material Parameter Collection(MPC)を使ってライト方向を制御する Toon Shader

最近、UE5でセルルック表現を色々試しているのですが、今回は Forward Renderer でも比較的安定して見える Toon Shader を作ってみました。

名前は furcraeaToonLock。

このシェーダでは、UE標準のライティングモデルに強く依存せず、Unlit + Emissive ベースで独自にライティングを計算しています。

そのため、

  • Forward Renderer
  • Deferred Renderer

の違いによる見た目の変化をかなり抑えられる構成になっています。

今回の記事では、

  • なぜ Unlit ベースで作ったのか
  • どうやって Toon Band を制御しているのか
  • ライト方向をどう扱っているのか
  • なぜ RampTexture 方式を考えているのか

などをまとめてみます。


なぜ Unlit + Emissive 構成にしたのか


■ Lit版 vs Unlit版 比較画像

左:

  • UE標準 Lit

右:

  • furcraeaToonLock

UE5の標準ライティングは非常に強力ですが、セルルックでは環境によって見え方が変化しやすいという問題があります。

特に、

  • Forward / Deferred の差
  • GI
  • Reflection
  • Specular
  • ポストプロセス

などが強く影響すると、「狙ったトゥーン感」が崩れやすくなります。

そこで今回は、

  • PixelNormalWS
  • DirectionalLight の方向
  • 独自の NdotL 計算

を使い、自前でセルシェーディングを行う構成にしました。

最終的な色は Emissive に出力しています。


ライト方向は Blueprint + MPC で制御

  • DirectionalLight
  • GetForwardVector
  • SetVectorParameterValue

が見える範囲

ライト方向は、Blueprint から Material Parameter Collection に渡しています。

今回使っているのは、

DirectionalLight -> GetForwardVector

です。

取得したベクトルを、

MPC_LightDir

LightDir

パラメータにセットし、マテリアル側で参照しています。

これによって、

  • ライト回転
  • Toon境界
  • ハイライト方向

などがリアルタイムに更新されます。


2Band / 3Band の Toon 制御

今回のシェーダでは、2Band / 3Band を切り替えられるようにしています。

最初は smoothstep ベースも試しましたが、グラデーション感が強くなりすぎて、セルルック特有の「段差感」が弱くなってしまいました。

そのため、最終的には step ベースで制御しています。

2Band はかなりグラフィック寄りで、強いアニメ感があります。

3Band は少しリッチで、柔らかいアニメ表現になります。


アウトラインについて

  • ON / OFF 比較

アウトラインは、別メッシュ + 別マテリアル構成で作っています。

今回は、

  • TwoSided
  • TwoSidedSign
  • OpacityMask
  • World Position Offset

を使って背面のみを描画し、法線方向へ膨らませる方式にしました。

最終的には、かなり軽量で扱いやすい構成になっています。


Material Graph 構成


■ Material Graph 全体スクショ

必須:

  • PixelNormalWS
  • MPC_LightDir
  • NdotL
  • Emissive

が見える範囲

マテリアル全体はかなりシンプルです。

基本的には、

PixelNormalWS

NdotL

step

Shadow Color / Light Color

Emissive

という流れで構成しています。

現在はさらに次の展開として、

RampTexture

を使った Toon Ramp Shader 化も進めています。


RampTexture ベースの次世代版について

現在制作中の次バージョンでは、RampTexture を使って Toon 色自体を制御する構成を試しています。

通常の toon shader は、

step(NdotL)

だけで明暗を切り替えることが多いですが、RampTexture を使うことで、

  • 暖色系
  • 紫系
  • 夜景風
  • アニメ風

など、絵作り全体をコントロールできるようになります。

現在は、

furcraeaToonRampShader

として開発中です。


Forward Renderer でも比較的安定した Toon 表現

おすすめ内容:

  • ライト回転
  • 2Band ↔ 3Band
  • Outline
  • Rim
  • Highlight

今回の構成では、ライト方向を Blueprint + MPC 経由で渡しているため、Forward Renderer 環境でも比較的安定した Toon 表現を維持できます。

特に、

  • Toon境界
  • 段差感
  • アウトライン
  • 色のコントロール

などが崩れにくい点が気に入っています。


Download / BOOTH

今回紹介した内容は、BOOTHで公開中の furcraeaToonLock をベースにした実装メモです。

  • 2Band / 3Band
  • Outline
  • Rim
  • Highlight
  • MPC Light Direction

などを含めた構成になっています。

BOOTH:
https://furcraea.booth.pm/

商品ページ:
https://furcraea.booth.pm/items/8219556

次はさらに、RampTexture を使って色味自体をコントロールできる

furcraeaToonRampShader

も作っていく予定です。

[UE5.7.3] Deferred ShadingかForward Shading設定によって変わるもの変わらないもの

Unreal Engine 5(UE5)におけるディファード(Deferred)とフォワード(Forward)レンダリングの設定は、プロジェクトのターゲット端末(PC/コンソールかモバイルか、VRか)によって異なります

設定方法とそれぞれの使い分けを解説します。

Deferred ShadingかForward Shading設定

1. 設定の変更方法 (Forward Shading)

UE5はデフォルトで「ディファードレンダリング(Deferred Rendering)」が有効になっています。フォワードレンダリングに変更したい場合、以下の手順で行います。

  1. [Edit (編集)] > [Project Settings (プロジェクト設定)] を開く。
  2. [Engine] > [Rendering] セクションを選択。
  3. [Forward Shading] カテゴリを探す。
  4. [Forward Shading] チェックボックスをオンにする(フォワード)、またはオフ(ディファード)にする。
  5. プロジェクトを再起動する。

2. ディファード vs フォワードの使い分け

特徴 [1, 2, 3]ディファード (Deferred)フォワード (Forward)
主な用途PC, コンソール, ハイエンドVRモバイル, 軽量VR, VR軽量化
光源数制限なし、大量のライト少ない(主要ライトのみ)
機能Lumen, Nanite対応基本非対応(機能制限)
メモリ/負荷大容量、パスが多くメモリ転送多MSAAが利用可能

ディファード(デフォルトDeferred Shading)

  • メリット: 高品質なライティング、多数のライト、LumenやNaniteなどの高機能。
  • デメリット: フォワードに比べてGPU・メモリ負荷が高い。

フォワード(Forward Shading)

  • メリット: 高いパフォーマンス(軽量)、MSAA(高品質なアンチエイリアス)が使える、VRなどで負荷を下げたい場合に有効。
  • デメリット: 多数のライトや複雑な影の表現が苦手。

3. モバイル向けの設定 (モバイルフォワード)

モバイルでは、さらに専用のレンダリングパイプラインが推奨されます。 [1]

  1. Project Settings > Platforms > Android/iOS > Rendering
  2. [Forward Shading] を有効にするか、[Mobile Deferred] を選択。
  3. 負荷を抑えるため、[Local Lights Buffer] などの詳細設定を調整。

まとめ

  • 高グラフィックPCゲーム: デフォルトのまま(ディファード)。
  • VR / 軽量化したいプロジェクト: Forward Shadingをオン。
  • モバイルゲーム: Mobile Forward または Mobile Deferred を選択。 [1, 2]

設定変更後はシェーダーの再コンパイルが発生するため、少し時間がかかります。

左がDeferred 右がForward

今回の場合

UE標準のライティングモデルに乗せるのではなく、UnlitのEmissive側でNdotLを計算してRampを参照しているため、DeferredかForwardかによるGBufferやライト計算の差分を受けにくい構成にしています。一方で、標準の影やGIを使う場合はLit系に寄せる必要があり、その場合はレンダリングパス差分を考慮します。

Unlit自前ライティングなら、Deferred / Forward差はほぼない。Litに乗せるなら差が出る

[UE5.7.3][RenderDoc]RenderDocでGPU計測する方法

https://renderdoc.org

Latest Stable Build(.zip) を選ぶ

それは初回起動時の匿名データ収集の確認画面
一番下を選べばOK

「Do not gather or submit any statistics.」

起動する

Executable Pathに UEのパスを入れる

D:\Program Files\Epic Games\UE_5.7\Engine\Binaries\Win64\UnrealEditor.exe

Command Line ArgumentsにUEプロジェクトのパスを入れる


D:\Sandbox\UE573petit25Cl\UE574petit25Cl_Lighting\UE574petit25Cl.uproject

Lunchで起動すると

RenderDoc経由でUEが起動する

UE開いたら

UEにフォーカス当てて👉 F12押す

出てきたキャプチャをダブルクリックすると

Filterを使って描画やCompute処理だけに絞って確認しています。
DrawCallはDrawIndexed DrawInstanced Dispatch Clearなので

Dispatch をFillterしてみると見えた。

Filterはこう使う👇

■ ■ 重い描画だけ見たい

Draw

■ ■ Computeだけ

Dispatch

■ ■ 特定のPass

BasePass

どのDrawCallを見るべきか?

見る順番はこれでOK。

1. まず「大きいPass名」を見る

UEならこのあたりを探す。

ShadowDepths
影が重いか見る。

BasePass
メッシュ本体の描画。マテリアルやテクスチャ参照を見る。

Lighting / DeferredLighting
ライト計算を見る。

Translucency
半透明。重くなりやすい。

PostProcess
Bloom、Tonemap、DOF、独自ポストを見る。

2. 次に、その中のDrawを見る

Passを開いて、こういう行をクリックする。

DrawIndexed
DrawInstanced
Dispatch

クリックしたら右側で見る場所は3つ。

Texture Viewer
→ 何が描かれているか見る。

Pipeline State
→ どのShader、Texture、Blend設定か見る。

Mesh Viewer
→ どのメッシュを描いているか見る。

まずShadow、BasePass、Translucency、PostProcessなどの大きいPass単位で見て、次にDrawIndexedやDispatchを選んで、RenderTarget・Shader・Texture参照を確認します。

最初に見るおすすめ

迷ったらまずこれ。

BasePassのDrawIndexed  や  PostProcessのDraw/Dispatchだが
→ マテリアル、テクスチャ、メッシュが確認しやすい。
BassPassが出たらクリックしてフラッグを立てるそして、Filterを解除

フラッグが立っている場所までスクロールすると中が見える状態

ExecutecommandListに入ってるのが見えないので。設定を変えてキャプチャし直し。

DX12ではExecuteCommandListsとしてまとまって見える場合があるので、RenderDocではCapture all Cmd Listsを有効にするか、確認用にDX11で起動してDrawIndexed単位で確認します。

■ やり直す設定

RenderDocの Launch Application 画面でチェックする:

  • Capture all Cmd Lists
  • Ref all Resources も付けてOK

DX11でやる

Command Lineにこれ入力👇

"D:\Sandbox\UE573petit25Cl\UE574petit25Cl_Lighting\UE574petit25Cl.uproject" -d3d11 -NoRHIThread

DX12ではDrawCallがコマンドリストにまとまるため、Pass単位で処理を確認しつつ、必要に応じてDX11でDrawIndexed単位でも確認しています。

見つかった!

DrawIndexedInstanced(6, 17)

意味:

  • Index数:6(1ポリの簡単な形)
  • Instance数:17(同じものを17個描画)

👉 パーティクル or 草(インスタンシング)

DrawIndexedInstancedを見て、インスタンシングで同じメッシュを複数描画していることを確認できます。

1回のDrawCallで複数インスタンスを描画しているため、DrawCall削減による最適化がされています。

次見るべきポイント PSSetShader (Pixel Shader)

重そうか(分岐 / テクスチャ数) マテリアル名

PSSetShaderResources テクスチャ数(ここ重要)

見る

  • 何枚使ってるか
  • 無駄に多くないか

目安

  • 1〜3枚 → 軽い
  • 4〜6枚 → 普通
  • 7枚以上 → 重い可能性

このDrawはまだ画面を全部埋めてない


■ ここでやるべき操作(超重要)

■ ① Eventを少しずつ進める

👉 左のEvent Browserで

  • ↓キー or クリックで1個ずつ進む

■ ② 右のTexture Viewerを見る

👉 変化を見る

変わった

■ 今起きてること

👉 Eventを進めたことで

  • 上の黒い部分に
  • 小さい点(葉っぱ)が出てきた

👉 つまり

このDrawが実際に画面に何かを描いてる


■ 今のDrawの正体

左を見ると👇
DrawIndexedInstanced(6, 16)

👉 意味

  • 小さいメッシュ(葉っぱ)
  • 16個まとめて描画

👉 つまり

パーティクル or インスタンス草

■ ① このDrawで何が変わった?

👉 右画面で見る

  • 点が増えた
  • 画面に追加された

👉 これ言える

「このDrawでパーティクルが追加されているのが確認できます」

イベントを進めることで、最初は未描画だった画面が、各Drawによって徐々に埋まっていく様子を確認できます。

チェッカーが消えるタイミングを見ることで、どの描画処理が最終的な画面に影響しているかを特定できます。

RenderDocではイベントを進めながら、どのDrawで画面に要素が追加されるかを確認しています。今回のケースでは、インスタンシングされたパーティクルが描画されているのが確認できます。

このようにDrawごとの変化を見ることで、描画順や負荷のかかる処理を特定しています。

■ ここまでできてること

  • DrawCall見つけた
  • 実際の変化を追えてる
  • インスタンシング理解してる

■ どういう意味?

RenderDocの流れ👇

  1. 最初
    👉 何も描いてない(黒 / チェッカー)
  2. 途中
    👉 一部だけ描画(点・葉っぱ)

  3. 👉 全体が描画で埋まった ← 今ここ

👉 つまり

この辺のDrawで最終結果に近づいた

イベントを進めることで、最初は未描画だった画面が、各Drawによって徐々に埋まっていく様子を確認できます。

チェッカーが消えるタイミングを見ることで、どの描画処理が最終的な画面に影響しているかを特定できます。

状態は「まだ画面を全部塗るDrawに来てない」ってこと。
(チェッカーが残ってる=未描画領域がある)

■ 今の位置の意味

左を見ると👇

  • BasePass
  • DrawIndexedInstanced(6, 17)(葉っぱ)

👉 これは

“オブジェクト描画フェーズ”


👉 だから

  • 一部だけ描かれる
  • 画面全部は埋まらない
  • チェッカー残る

■ 次に探すべきもの(重要)

👉 画面を一気に埋めるDraw


■ 目印

これ探す👇

  • PostProcess
  • Tonemap
  • Fullscreen
  • Resolve
  • Composite

■ 何が起きてるか(技術的に)

👉 今のDrawで

  • SceneColorに
  • あなたのHLSLで描いた月が加算された

👉 つまり

Pixel Shaderが最終色を決めている瞬間

このDrawでは、独自のHLSLシェーダを使って月の表現を描画していて、SceneColorに対してピクセル単位で最終色を出力しています。

RenderDocでこのDrawを確認することで、実際にどのシェーダが最終結果に影響しているかを特定できます。

このようにDrawごとの出力を追うことで、意図したシェーダが正しく画面に反映されているかを検証できます。

■ ここで見るべきポイント(重要)


■ ① Pixel Shader

👉 ここ

PSSetShader

HLSLが動いてる場所

■ ② Shader Resource(テクスチャ)

👉 月の模様

Shader Resource View

■ ③ DrawIndexedInstanced

👉 描画回数

■ さらに強い視点

  • フルスクリーンじゃない → オブジェクト描画
  • 一部だけ変わる → メッシュ単位
  • ピクセルで模様 → Pixel Shader

RenderDocを使うことで、実際の描画結果とシェーダの対応関係を確認しています。

■ 結論(今回のケース)

👉 重くなりやすい要因はこれ

① パーティクル(葉っぱ)のインスタンス描画

  • DrawIndexedInstanced(6, 16/17)
  • 数が増えると一気に負荷増える

② Pixel Shader負荷

  • 独自HLSL(月の模様)
  • ピクセル単位で計算してる

③ テクスチャ参照

  • PSSetShaderResources
  • 複数テクスチャ使ってる

④ オーバードロー(これが一番重要)

👉 葉っぱ(半透明)が重なる
👉 同じピクセル何回も計算される


■ 一言でまとめると

パーティクルのオーバードロー+ピクセルシェーダ負荷


今回のケースでは、パーティクルのインスタンス描画によるオーバードローと、ピクセルシェーダの計算量が主な負荷要因だと考えています。


特に半透明オブジェクトは重なりやすく、ピクセル処理が増えるため注意が必要です。


■ もう一段上

👉 改善案も言う

  • インスタンス数制御
  • テクスチャ削減
  • シェーダ簡略化
  • LODや距離カリング

■ まとめ

👉 今回の分析

  • Draw見た
  • Shader見た
  • 結果から原因言えた

[UE5.7.4][Unreal Insights] Unreal Insightsを利用してのC++最適化方法

計測開始

計測終了

Unreal Insightsの起動

計測結果の選択

時間範囲計測の方法

左右ドラッグで位置移動、

マウスオーバーで このマテリアルの処理だとかが、わかる

左クリックで選択

右クリックでメニュー表示

シングルクリックしてから、別の位置で Ctrl + クリックで 範囲の時間を表示できる。


TRACE_CPUPROFILER_EVENT_SCOPEで関数をマークする。

public:
	virtual void Tick(float DeltaTime) override;

cpp

#include "ProfilingDebugging/CpuProfilerTrace.h"

void ASideScrollingCharacter::Tick(float DeltaTime)
{
	Super::Tick(DeltaTime);
	///////////////////////////////////////////////////////////////////
	TRACE_CPUPROFILER_EVENT_SCOPE(ASideScrollingCharacter::Tick);

	// 重たい処理1
	for (int32 i = 0; i < 100; ++i)
	{
		UE_LOG(LogTemp, Log, TEXT("Omotai 1"));
	}
	// 重たい処理2
	for (int32 i = 0; i < 1000; ++i)
	{
		UE_LOG(LogTemp, Log, TEXT("Omotai 2"));
	}

	////////////////////////////////////////////////////////////////////
	//////////////////////他の処理//////////////////////////////////////
	if (!bIsOnLadder)
	{
		return;
	}
}

ビルドしてから実行

TRACE_CPUPROFILER_EVENT_SCOPE の処理の箇所を検索

1,Timersで「ASideScrollingCharacter::Tick」で検索し

2,出てきたASideScrollingCharacter::Tickを右クリックしHighlighting Eventを使い

3,出てきたASideScrollingCharacter::Tickを右クリックしFind Instance>First Instanceでスレッドが見つかる

参考URL

式会社アドグローブの公式ブログ:TRACE_CPUPROFILER_EVENT_SCOPEによるお手軽C++プロファイリング![UE5.1]
https://blog.adglobe.co.jp/entry/2023/05/12/100000

※はてなブログ(mawasiの備忘録)
https://mawasi.hateblo.jp/entry/2025/06/16/023611
によると、以前のQUICK_SCOPE_CYCLE_COUNTERより、こちらのマクロが推奨されています。
Unreal Insightsの起動: Engine/Binaries/Win64/UnrealInsights.exe を実行します。
プロファイリングの実行: エディタまたはパッケージ化したゲームを、コマンドライン引数 -trace=cpu,frame を使用して起動します。
データの確認: Unreal Insights上の「Timing Insights」タブで、埋め込んだタグ(例: MyFunction_Tag)を検索して計測結果を確認します。

関連・補足情報
詳細なボトルネック調査: Qiitaの記事

https://qiita.com/nonbiri15/items/7968e55bbf4fd61ab4df

で述べられている通り、CPUとGPUのボトルネックを特定し、ボトルネックの修正に活用できます。
関数の呼び出し回数: TRACE_CPUPROFILER_EVENT_SCOPEを使用すると、処理時間だけでなく、関数の呼び出しツリーや回数も確認できます。
詳細な情報源: 株式会社ヒストリアさんの改訂版記事

https://historia.co.jp/archives/48769

では、より詳細なUnreal Insightsの使用方法が解説されています。

この方法を使うことで、ゲームパフォーマンスの改善に役立つ正確なデータを得ることができます。