１．今週の予定
今週もこの順序に従って勉強していきます。
- 映像作成用UE5の勉強
- AIの勉強
- Nvidia Omniverseの勉強
- Gaeaの勉強もしくはVroidとUE5の勉強
- Houdiniの勉強
- AIについての調査（ComfyUIの勉強）
- DirectX12の勉強
それぞれの勉強の最初にその勉強をする目的を一寸だけ書いておきます。
2. 映像作成用UE5の勉強
2.1 PCGを使用した神社の作成
PCGで建物を作成する方法を勉強してるので、その応用としてPCGで神社を作成する事にしました。
最終的にはUEFNのMap内で神社を作成して、だれでも参拝出来るようにするつもりです。
2.1.1 屋根の角のStatic Meshを作成する
以下の屋根の大棟のを繋げたBPだけ作成しました。
以下の様になりました。
それぞれの角で正しい方向を向いていません。
よく観察すると右上、右下、左上、そして左下の角の向きが全部同じになっています。
屋根の角の方向を正しく表示するためには右上、右下、左上、そして左下の角のPointを別々に生成して、その後で向きを回転させるのが一番楽でしょうか？
これをやる事にします。
2.1.2 右下の屋根の角のPointだけ生成する
以下の様にして作成しました。
Top Viewから見て右側にあるPointを利用します。
このPointを以下の実装でWall Size一個分だけ下にずらします。
このようになります。
このWall Size一個分だけ下にずらしたPointから元のPointの差分をとります。
これらのPointが如何に示した様に右下の屋根の端の部分と一致します。
Pointの細かい点の位置は後で、Offsetを使用して調整します。
これはすぐに出来るので最後に一括してやります。
それよりも別な問題があります。
それはこのやり方では以下のように壁が内側に交差する場合にもPointを生成してしまう事です。
このPointは要りません。
このPointを消す必要があります。
これは四角の内側にあるPointは全部消えるようにすれば良いだけです。
以下のOriginal Pointを引いてしまえば消えるはずです。
Differenceノードで引きました。
結果です。
消えません。
何で？
右側の壁を生成するために使用したPointをよく見たら、Original Pointを右にずらしたPointを使用していました。
これは四角内のPointではありません。右側に四角内からはみ出したPointがあります。
しかしこのPointをDifferenceを使って引くと
このように右下の壁の端のPointだけが生成されるようになりました。
結果、All Rightという事でこれでOKとします。
2.1.3 右上の屋根の角のPointだけ生成する
同様にして今度は右上のPointだけ生成します。
四角の右下のPointを移動させてみます。
屋根の外側の角で右上の場合のみPointが生成されます。
出来てますね。
2.1.4 Pointの位置を微調整してBPを貼り付ける
Pointの回転もしないといけないので位置の微調整もここでやる事にします。
まず右下のPointの位置を調整しました。
Offsetを使用してずらしただけです。
PointにBPを表示します。
正しい向きで表示されています。
右上の実装も以下の様に微調整しました。
結果です。
こっちも正しい位置と向きになったようです。
四角の右下のPointの位置を移動して確認します。
出来てますね。
左上と左下の壁の外側の端のPointも同様に作成します。
が時間が無くなってしまったので、それは来週やる事にします。
2.2 PCGの勉強
PCGを使用した建物の作成を勉強しています。
その理由ですが、Luma AIで作成した3D Gaussian SplattingをUE5にImportすると以下の様に、
奥にあるHigh-rise apartment Building（マンション）が歪んでいます。
気持ち悪くなる位曲がっています。
これ直さないと3D Gaussian Splattingは使用出来ない。との結論になりました。
でどのように直すかとなると、PCGを使用してHigh-rise apartment Building（マンション）を作成するしかないのかな。となりPCGで建物を作成する方法を勉強する事になりました。
2.2.1 Do You Want to Remove Just One Side of Your Building? | UE 5.4 P4 [1]の続きを実装する
前回勉強した内容を実装します。
まず前々回に実装した内容をTestしています。
Tutorialと同様にTestしてみます。
Regular WallsのScaleのYの値を1から5に変更しました。
おおRegular Wallの形状だけが変化しました。
今度はDetail WallsのIndex[1]のScaleの値を変更してみました。
結果です。
結構見た目的には面白い変化をします。
今度はOffsetをTestします。
こんな結果になります。
Animationで動させるようになったら興味深い映像が作成出来そうです。
色々な値を試してみます。
これも面白い結果になりました。
これらのParameterを一寸いじるだけでApartmentの形状が非常に本物らしくなります。
全てのStatic Mesh Spawnerノードの前にこのPCG Offset Transformsノードを追加します。
しました。
今度はCorner PillarのSizeを変更しました。
結果です。
おお角の柱が太くなりました。
これはかなり見栄えが良いです。
Roof Boarder WallのScalingの実装は要らないので消します
すると以下の様になります。
これをScalingとOffsetで直します。
うーん。これは結構面倒くさいな。
元に戻しました。
ここはTutorial通りにはやらない事にします。
＜07:54 - Doors Setup＞
PDA_Modular BuildingのVariablesにDoorsを追加します。
そしてDA_RegularBuildingのDoorsに
以下の
を追加しました。
だだしこのDoorに使用したMeshのSizeはWallとは違います。
どこかでSizeを調整する必要があります。
これは来週やる事にします。
今週はここまでです。
2.3 Level Sequence上でAnimationの編集をする方法
Level Sequence上でDragonをAnimation Sequenceを使用するとDragonの爪が地面にめり込んでしまいます。
これを直すには、Animation SequenceではなくControl Rigを使用する必要があるみたいです。しかし私が使用してるDragonには付属のControl Rigがありません。
しかもControl Rigがどういうものなのか全く理解していません。
のでControl Rigがどういうものなのかについての全般的な知識と、その使用方法についての基礎を勉強する事にしました。
その後、今まで勉強してたTutorialはUE5.0用のTutorialで5.5はControl Rig [2]を勉強する必要がある事が判明しました。
のでControl Rig [2]を勉強する事にしました。
2.3.1 先週の復習
Full-Body IK [3]を勉強しました。
Full Body IKノードの使い方は大体理解しましたが、予測と結果が一致しません。
特にFull Body IKノードを使用して、どうやって自然に膝を曲げる動作になるのかが分かりません。
のでFull Body IKノードの設定をいじっていろいろ試してみました。
で結論ですが、
よく分からない。となりました。
最後に、CR_Mannequin_BodyのFoot_r_ik_ctrlを動かすと
膝が綺麗に曲がる事が確認出来ました。
ので
とまとめて終わっていました。
今週はこれをやります。
2.3.2 CR_Mannequin_BodyのFoot_r_ik_ctrlを検査する
Full Body IKを使用してるのかと思ったらCR_Mannequin_BodyではFull Body IKは一つも使用していませんでした。
Foot_r_ik_ctrlを検索すると以下に示した様に沢山のNodeから参照されていました。
それぞれのNodeにおけるFoot_r_ik_ctrlの使用方法を見てみます。
Setup Legノードです。
そもそもこんな名前のNodeが本当に存在してるんでしょうか？
何かのNodeの名前を変更した可能性があります。
まずそれから調べます。
ChatGPTに質問したら以下の回答が返って来ました。
My Blueprint Pannelを確認します。
ありました。
Setup LegをDouble Clickしたら以下の実装が表示されました。
うーん。
実装の中身を見てみます。
これは何をやってるのか全く理解出来ません。
うーん。
色々なNodeをみたら以下のGet Float Channelノードは元からあるNodeのようです。
ない。
このNodeも無いです。
これを見るとGetAnimationChannelノードを使用してるのかもしれません。
うーん。
でも違うかもしれません。
こんなNodeですらどうやってAccessするのかすら分からん。
分かりました。
以下のSoftnessから引っ張って
GetAnimationChannelノードを選択すると、Get Float Channelノードが表示されます。
うーん。
やっとこのNodeがGetAnimationChannelノードである事が確認出来ましたが、それが分かったとして何の足しにもなりません。
ChatGPTに色々質問してたら以下の回答が返って来ました。
Channelという概念が、Control Rigにはあるみたいです。
これはこれだけ理解出来たら十分です。
他に以下のMake Arrayノードでも使用されていました。
これは単にArrayを作成するためのNodeですので、このNodeの先のNodeでどのように使用されているかを確認します。
以下のNodeのIK Controlsに繋がっていました。
このNodeも先程のSetup Legノードと同じここで作成されたFunctionです。
中身を一寸だけ見てみます。
なんとPassされたIK Controlsの値は使用されていませんでした。
いやよく見たら以下の実装で使用されていました。
Set Control VisibilityノードでそれぞれのControlのIconを決定してるでしょうか？
Set Control Visibilityは普通に存在するNodeです。
このNodeの機能は
だそうです。
という事はここの実装はIK ControlのIconを表示するためのものという事です。
以上でした。
2.3.3 CR_Mannequin_Bodyの実装でFoot_r_ik_ctrlを使用してる箇所を見た感想
今週はCR_Mannequin_Bodyの実装を見てみましたが、この実装を理解出来るほどの知識はまだなかったです。
やっぱり地道に基礎を勉強した方が良かったです。
来週からは以下のControl Rig [2]にあるTutorialを勉強する事にします。
3. AIの勉強
AIの勉強の目的ですが、
生成AIが凄いTrendになってるので、最低限の基礎は知っておくべきと思いこの勉強を始めたんでした。
のでこれを勉強してどうしたいというのは無いです。
3.1 前回の復習
Getting started with NLP for absolute beginners [4]の＜Metrics and correlation＞を実装しました。
Kaggleは実装に関係のない部分のErrorが多いのでCollabでやり直そうと思っていたんですが、このTutorialそのものにそんなに興味が無くなってしまいました。
のでそのままKaggleでやる事にします。
＜Training＞
＜＜Training our model＞＞
TransformersからTrainingArgumentsとTrainerをImportしました。
TrainingArgumentsとTrainerについてChatGPTに質問しました。
だそうです。
最近、ChatGPTの回答に満足しない時が多いです。
Copilotでも同じ質問をしてみます。
同じですね。
Copilotの方が読み易いですね。
今週はCopilotで質問する事にします。
次です。
Copilotの回答です。
一応、ChatGPTでも同じ質問しましたが全く同じ回答が返って来ました。
文章の構成までまったく同じです。
気持ち悪いですね。
念のためにGeminiとGrokでも質問してみました。
この２つは多少違う回答が返って来ました。
ただChatGPTやCopilotと比較すると一寸精度が落ちる気がします。
図とか表が無いんです。
これ比較すると全部無料であるCopilotが一番って事になりますね。
これの機能は覚えていますが、名称を忘れてしまいました。
Copilotに聞きます。
Learning Rateの略でした。
そしてこれはどれくらい細かく学習するのかを指定するための設定であるとも解説されていました。
これは分かり易い説明です。
ここでModelのTrainingの設定を指定しています。
Copilotの説明によるとそれぞれの設定は以下の様になってるそうです。
次の実装です。
Copilotによると、このコードは、事前学習済みモデルを読み込み、Trainer を使ってトレーニングと評価を行う準備をしているそうです。
以下のような解説をしてくれました。
ChatGPTはすぐに4oの使用上限に達しました。とか言って来ますが、こっちは何も言って来ません。
普段はこっちを使用して、Graphの生成が必要な時だけChatGPTを使用するのがBestかもしれません。
Trainerの説明もしてくれました。
成程。
大体理解したわ。とおもって実行したらErrorになりました。
Errorの内容をまるっとCopilotに質問したら
これはErrorではなく警告だそうで、以下の事を述べているそうです。
次のCodeを実行します。
今度は本当にErrorになりました。
Copilotの説明通りに直しました。
そしてもう一回、
を実行しました。
一応、結果らしきものを得る事が出来ました。
を実行しました。
結果です。
なんだあ、これは？
モデルが評価データに対して予測した連続値だそうです。
それがなんなのか不明なのだ。
０以下の値と１以上の値を外します。
結果です。
外れました。
でCSV Fileを生成するところまでやりました。
これで完成でいいや。
今週のAIの勉強はここまでです。
4. Nvidia Omniverseの勉強
Robotic AIの仮想空間におけるTrainingのための環境設定こそがこれからの3D Graphicsの専門家が生きる場所であると思っています。
のでその仮想空間でRobotic AIがどんなTrainingを行っているかをまず勉強する事にしました。
色々調べると、その部分はNvidiaのOmniverseの中のIsaac Simが担当してる事が判明しました。
のでその辺りを勉強します。
4.1 NVIDIA Isaac Sim - MuSHR RC Car - Ackermann Tutorial [5]の勉強
Version 4.2.0のIsaac Sim Documentation [6]のTutorialの勉強がROS and ROS2まで終わるまでPending。
WorkspaceのInstall方法並びに、Installした後の確認方法は理解したので時間があったらWorkspaceだけInstallしておきます。
ただし今週も他にやる事が沢山あるのでやりません。
4.2 Version 4.2.0のIsaac Sim Documentation [6]のTutorialの勉強
4.2.1 先週の復習
Isaac Sim Documentation [6]のTutorial のDevelopment にあるRunning Python Code from External Editors [7]を勉強しました。
更に実装もしました。
VS Codeから実行するのは、厳密には出来なくて、VS Codeで書いたCodeをScript Editorから実行しました。
更に言うとVS CodeのWalkthroughsが以下の様に更新し始めて
途中で止まってしまいました。
先週から、他の用事でVisual Studio Codeを何度が使用したんですが、このWalkthroughs更新の途中で止まっています。
後で直す必要があります。
こういうのはChatGPTなどに質問したらすぐに直せるので、後で暇なときに直します。
Jupyter NotebookからIsaac Simを操作する方法は簡単に出来ました。
4.2.2 Isaac Sim Extension Templates [8]を勉強して実装もする
＜Learning Objectives＞
以下の３つが出来るようになるそうです。
- 提供されるテンプレートの構造と目的を理解する。
- USD Worldとリアルタイムに連携するための機能的なコードを即座に書く。
- カスタマイズされたUIベースの拡張機能を作成するスキルを習得する。
まあやったら理解出来るでしょう。
＜Getting Started＞
このTutorialを勉強するのに必要な知識は全部あります。
＜General Concepts＞
Extension Template Generatorの全部のTemplateは基本構造が共通だそうです。
TemplateのRoot Directoryには「./scripts」Folderがあり、拡張機能をサポートするPythonコードが収められているそうです。
この中には共通のPythonファイルが3つ含まれているそうです。
うーん。
まあ知らないよりは知っておいた方が良いって程度の知識ですね。
以下の３つのTemplateがあるそうです。
- py: 拡張機能を作成する際に指定した、タイトルや説明などのグローバル変数を保存するスクリプト。
- py: ツールバーに拡張機能を表示させるための基本コードが含まれたクラス。通常はそのままで幅広いケースに対応可能。
- py: ユーザーがテンプレートにアクセスするメインファイル。コールバック関数やUI要素を作成でき、ユーザー独自の機能を追加する際に便利。最も詳しくドキュメント化されているので、変更前に読むことがおすすめ。
うーん。
よく分からん。
続きを読みます。
このテンプレートでは、./scripts/ui_builder.pyを主に編集すれば拡張機能を思い通りに動作させることが可能だそうです。
内包される標準的なコールバック関数には以下のようなものがあります：
- on_menu_callback(): 拡張機能が開かれた際に呼び出されます。
- on_timeline_event(): タイムラインが停止、ポーズ、再生された際に呼び出されます。
- on_physics_step(): 物理ステップごとに呼び出され、タイムライン再生中のみ動作。
- on_stage_event(): ステージが開かれたり閉じたりした際に呼び出されます。
- cleanup(): 拡張機能が閉じられる際にリソースをクリーンアップ。
- build_ui(): ユーザーが作りたいUIを生成する関数。
成程。
ui_builder.pyだけ編集すれば良いのか。
更に言うと、その中のbuild_ui() 関数の編集が主な作業になるそうです。
＜Loaded Scenario Template＞
Copilotの要約を以下にまとめました。
Loaded Scenario Templateでは、3つの基本ボタン「Load」「Reset」「Run」を含むシンプルなUIが提供されます。
このUIは、シミュレーターの内部構造を深く理解せずに、USDステージに直接影響を与えるコードを簡単に書けるよう設計されています。
ユーザーは必要最低限の簡単な概念のみを理解していれば十分です。
以下の３つが必要最低限の概念になります。
＜＜Simulation Timeline: Omniverse Kit＞＞
左側のツールバーでタイムラインの停止、再生、または一時停止が可能です。
物理シミュレーションはタイムラインがアクティブな場合のみ動作します。
タイムラインが停止している場合、ロボットのArticulation制御はできず、アセットの初期化が必要になります。
Loaded Scenario Templateは、初期化を簡略化し、ユーザーがシミュレーターを手軽に操作できるように設計されています。
＜＜Worldクラス＞＞
omni.isaac.core.worldにあるWorldというシングルトンクラスは、シミュレーションのセットアップと管理を簡単に行えるように設計されています。
このテンプレートでは、LoadおよびResetボタンによってWorldの状態を管理します。
これにより、コールバック関数が呼び出される際のシミュレーターの状態が保証され、ユーザーは簡単な操作でworld.scene.add(user_object)を利用できます。
＜＜Timeline管理＞＞
タイムライン操作は、UI内のLoadとResetボタンを使用して行うべきです。
ユーザーが外部ツールバーのStopやPlayボタンを使用すると問題が発生する可能性があります。
そのため、このテンプレートは外部操作が行われた場合にUIをリセットし、コールバック関数の前提を保つように設計されています。
うーん。
よく分かったような分からんような。
まあ、全部やったら何が言いたいのか分かるでしょう。
次をやります。
＜Implementation Details＞
３つのButtonについて簡単に説明しています。
＜＜Loadボタン＞＞
setup_scene_fn(): 新しいWorldインスタンスを作成し、アセットをステージにロードしてworld.scene.add()でWorldに追加します。
setup_post_load_fn(): アセットがロードされ、初期化済みであり、タイムラインが0タイムステップで一時停止していると仮定できます。
＜＜Resetボタン＞＞
pre_reset_fn(): Worldがリセットされる前に実行。シミュレーターの状態に保証はありません。
post_reset_fn(): アセットが正しく初期化されており、タイムラインが0タイムステップで一時停止していること、アセットが初期位置に戻ることが保証されています。
＜＜Runボタン＞＞
StateButtonで、状態「RUN」と「STOP」を切り替えます。
on_a_click()とon_b_click(): ボタンの状態ごとに対応する関数を実行します。
physics_callback_fn(): B状態の間、物理シミュレーションステップごとにコールバックを呼び出し、A状態では物理シミュレーションを停止します。
これは既存のFunctionを説明してるのでしょうか？
実装する時に、実際に使用して試してみないとよく分からないですね。
付属の映像を見たら、何をやってるのか少し理解出来るようになりました。
Load Scenario Templateを実行します。
するとWorld ControlsとRun Scenarioの項があるTemplateが開きます。
World ControlsにはLoad ButtonとReset Buttonがあり、
Run Scenarioには
RUN Buttonがあります。
今までの説明はこのTemplateについての説明だったようです。
＜Scripting Template＞
以下にCopilotの訳を示します。
Scripting Templateは、Loaded Scenario Templateを基にした、UIベースの拡張機能でより高度なスクリプト的動作をプログラムするフレームワークを提供します。
このテンプレートはロボットの位置をロード・リセットする仕組みを共有しつつ、RUNボタンをスクリプトとして実装します。
このテンプレートで示されるパターンを使用すると、物理ステップごとに新しいコマンドを送信したり、次のステップへ進むタイミングを判断するなど、長時間実行される関数を実装してスクリプトのような動作をプログラムできます。
具体的には、goto_position()、open_gripper_franka()、close_gripper_franka()といった関数が実装されており、これらを連続して使用することで、単純なピック＆プレースタスクをスクリプト化できます。
だそうです。
これも実際に触ってみないとよく分からないです。
一寸だけ理解して来ました。
この説明の肝は、
物理ステップごとに新しいコマンドを送信したり、次のステップへ進むタイミングを判断するなど、長時間実行される関数を実装してスクリプトのような動作をプログラムできます。
なんです。
これサラッと言っていますが、これらを実現するための関数は時間によって制御されるため、非同期な特性が必要になってくるはずです。
それをこのTemplateを使用すると単純なScriptを書くだけで実装出来ますよ。と言ってるんです。
＜＜Implementation Details＞＞
Copilotの要約を示します。
このセクションでは、Loaded Scenario Templateに似たUI実装に加え、スクリプト的な動作の詳細が説明されています。
長時間実行される関数は、Pythonのyield/generatorフレームワークを活用して記述されます。
my_script() 関数が scenario.py 内で実装されており、以下の操作を順番に行います：goto_position()、open_gripper_franka()、close_gripper_franka()。
yield および yield from を使用することで、self._script_generator = self.my_script() の形式でジェネレーターとしてラップされます。
物理ステップごとに next(self._script_generator) が呼び出され、次のyieldステートメントまでコードを実行します（ネストされた関数内も含む）。
要するに、先程出て来た物理ステップごとに新しいコマンドを送信したり、次のステップへ進むタイミングを判断するなど、長時間実行される関数を実装するのにPythonのyield/generatorフレームワークを使用するという事です。
で、具体的にそのPythonのyield/generatorフレームワークがどうなっているのかという事ですか、これはCopilotに沢山質問して完全に理解しました。
以下にその内容をまとめます。
上記のCodeを例にして説明します。
まずGenを実行すると、一回で実行されるのはYieldの部分だけです。
そしてもう一回Genを実行すると、次のYieldが実行されます。
これがYield/Generatorの仕組みです。
そしてここでは以下の実装を例として説明しています。
実行方法は先程の例と全く同じです。
呼び出される度にYieldが実行されます。
次の例です。
今度は、Yieldの代わりにYield Fromが使用されています。
Yield fromは以下のような挙動をします。
別な関数のYieldもNestする事が出来る訳です。
更に実際のCodeの例として以下に示したOpen_gripper_franka()関数の実装が紹介されています。
まず以下の実装です。
open_gripper_action = ArticulationAction(np.array([.04, .04]), joint_indices=np.array([7, 8]))
articulation.apply_action(open_gripper_action)
グリッパーを開く命令が作成され、それが適用されています。
np.array([.04, .04]) はグリッパーの目標値を示しており、joint_indices で制御する関節を指定しています。
while not np.allclose(articulation.get_joint_positions()[7:], np.array([.04, .04]), atol=.001):
yield()
このループでは、グリッパーの現在の関節位置が目標値に到達するまで毎フレーム確認を行います。
つまり一Frame毎にYieldされるという事です。そしてグリッパーの現在の関節位置が目標値に到達するとLoopが終了します。
要は、勝手に自分の仕事だけ進めちゃいけない。って事ですね。全部の関係する関数が一寸だけ進め合うとRobotは正しく機能する。それをこのような実装で実現してるのか。
納得です。
やっとこのTutorialの言ってる事が理解出来て来ました。
Tutorialの次の解説を、Copilotに要約させたものです。
my_script()はyield from open_gripper_franka()を呼び出します。
open_gripper_franka()はフランカのグリッパーを開くためのコマンドを送信し、その後、各物理ステップでグリッパーが目標位置に到達したか確認します。
到達すると、yieldを終了してreturn Trueで成功を示します。
その後、制御はmy_script()に戻り、次の関数が実行されます。
特にCommentはありません。
Yield/Generatorを使用してこんな動作を実現してるのかというだけです。
でもこれ、単にRobotの手を開いただけですよね。
それでもうなんか一仕事終わらしたみたいな感じで語られても。とは感じました。
＜Configuration Tooling Template＞
以下にCopilotの訳を載せます。
Configuration Tooling Templateは、アセットの設定用のツールを構築するための基本的なテンプレートを提供します。
このテンプレートでは、ステージ上の任意のアーティキュレーションを検索するドロップダウンメニューを作成し、選択されたアーティキュレーションの各ジョイントを操作するためのUIフレームを動的に生成します。
Loaded Scenario Templateとは異なり、この拡張機能はタイムラインやステージを制御することはありません。
代わりに、ユーザーがステージ上に存在するものを自由に選択し、その状態を読み取ったり書き換えたりすることができます。
アセットの設定用のツールを構築することはより高度なユースケースであり、そのためシミュレーションタイムラインの内部モデルが必要になります。
例えば、アーティキュレーションはタイムラインが再生されている間のみアクセス可能であるため、提供されるテンプレートではタイムラインが再生されている間のみ選択されたアーティキュレーションの変更を試みることが可能です。
付属の映像を見ると以下の様にそれぞれの関節の値を指定するParameterが表示されています。
これで直接Robotの関節の角度を調整してるようです。
そしてこのような方法でRobotを操作する方法をまとめたのがConfiguration Tooling Templateになると言う訳です。
＜Implementation Details＞
Copilotの訳です。
DropDownは、USDステージ内の指定されたタイプのすべてのオブジェクトを検索する関数によって構築されます。
この関数は、DropDown UIラッパーに直接便利な機能として提供されますが、ユーザーがさらにカスタマイズできるように、テンプレートの最後にその関数のバージョンが残されています。
DropDownで新しい項目が選択されると、ビルダー関数を使用してRobot Control Frameが再構築されます。
この方法は、堅牢で動的なUIツールを作成するための強力なパラダイムです。
このテンプレートでは、フレームは「ロボットを選択できなかった」ことをユーザーに報告するか、問題なく選択された場合はそのロボットのすべてのジョイントを一覧表示することができます。
うーん。
DronDownってこれの事ですかね。
ここから全てのObjectが選択出来るようになってるって事でしょうか？
＜UI Component Library＞
Copilotの訳です。
UIコンポーネントライブラリテンプレートは、作成された各UIElementWrapperの使用方法を示しています。
これは、カスタムUIツールを設定する際の参考資料として使用されるべきものです。
特に重要なのは、このテンプレートが、各UIElementWrapperに添付できるコールバック関数に必要な引数の具体的な型や、戻り値の種類を示している点です。
このテンプレートでは、「ロード」や「リセット」ボタンは省略されています。
これらは特別なケースに該当し、Loaded Scenarioテンプレートで示されています。このテンプレートに表示されているUIコンポーネントは、シミュレーションに直接影響を与えることはなく、ユーザーのコールバック関数を呼び出すだけです。
最後のTemplateであるUI Component Libraryの説明です。
この説明を聞いても意味が全く分かりません。
先に付属の映像を見ます。
こんなUIになっていました。
でもこれのParameterの説明してる訳ではないですよね。
よく分からないです。
次の文章です。
UIコンポーネントライブラリテンプレートのコンポーネントは、omni.uiの要素の一部をラップしています。
それぞれのラッパーには、他のラップされたコンポーネントと並べた際に見栄えが良くなるよう、UIコンポーネントの配置やラベル付けに関する独自の設計が施されています。
上級ユーザーであれば、ラップされたコンポーネントの横にomni.uiのコンポーネントを問題なく追加することが可能です。
いや、この説明はよく分からないです。
何が言いたいんでしょうね。
これでUI Component Libraryの説明は終わってしまいました。
＜Summary＞
Summaryの訳です。
このチュートリアルでは、Omniverse Isaac Sim Extension Template Generatorによって提供されるテンプレートについて説明しました。
それぞれのテンプレートは共通の基盤構造を持ち、異なる用途を示すための薄い実装層が追加されています。
これらのテンプレートのいずれかを参照することで、ユーザーは内部シミュレーターの詳細な仕組みを学ぶ必要なく、カスタマイズ性の高いUIベースの拡張機能を構築し始めることができます。
いや。
このTutorialで勉強出来たのは、３つのTemplateの名前が、Loaded Scenario Template、Configuration Tooling Template 、そしてUI Component Libraryという事だけです。
それぞれのTemplateの使い方も、どうやってCustomizeするのかも全く分かりません。
いや、これは読むだけ無駄なTutorialでした。
星１/星５の評価です。
どっかに評価を書く欄無いですかね。
4.2.3 Isaac Sim Extension Templates [8]の内容を実装してみる
流石にこのままで終わる訳には行きません。
Extensions [9]を見直して実際に実装してみます。
Isaac Simを開き、Isaac UtilesからGenerate Extension Templatesを選択します。
以下のWindowが開きました。
おお、今日勉強した３つのTemplateがあります。
Loaded Scenario Templateを選択してみます。
これらの項目を埋める必要があるのか。
以下の様に書きました。
Generate ExtensionをClickします。
Extensionを開き、作成したExtensionを探します。
ありました。
実行します。
ああ、これは前に勉強しました。
これのRun Scenarioの実装を改良出来る技術を勉強するのが今回のTutorialの目的なはずです。
今日のTutorialを見直すと、
global_variables.py、extension.pyとui_builder.py
について述べています。
ありました。
うーん。
これを理解した上で今回のTutorialは勉強しないといけなかったのか。
Global_variables.pyを開きました。
はあ、これがTutorialに書いてある内容なのか。
うーん。
来週、勉強し直します。
今週はここまでにします。
5. Gaeaの勉強もしくはVroidとUE5の勉強
なし
6. Houdiniの勉強
Houdiniの勉強を始めた理由は、これからの3D GraphicsはProceduralな3Dの生成だという風潮が2年前ぐらいに起きて、それで慌てて勉強を始めたんです。
生成AIブームが起きて、Proceduralな3Dの生成のブームはすっかりなくなってしまいましたが、Nodeを使用して3Dを生成する手法は、職人的な技術が無くても3D Objectの生成が出来るのでかなり便利という事に気が付きました。
のでHoudiniの勉強は続けています。
しばらくHoudiniの勉強はお休みして木の生成について調査していましたが、やっぱりHoudiniの水のSimulationの勉強をする事にします
木を自分で実装してもその凄さに気が付く人はほとんどいません。
それに対して水のVEXを作成したら誰が見ても凄いと思うからです。
6.1 前回の復習
Houdini is HIP - Part 14: Flip Fluids I [10]を勉強しました。
NotebookLMで要約した内容をまとめています。
この勉強した内容、全く覚えていません。
前回のBlogを読み直して復習します。
大体思い出しました。
流体の計算方法は２つあります。
Lagrangian法とEulerian法です。
Lagrangian法はParticleを使用し、Eulerian法はGridを使用します。
Houdiniの流体の計算はこの２つの良いとこどりをします。そしてその名前をFLIPと呼びます。
で具体的なFLIP法のやり方なんですが、前回のBlogのまとめを読んでも今一よく分かりません。
結構真剣に読んだんですが、はっきり言って全く分からないです。
そう言えば、前回まとめた時もよく分からなかったです。
で、NotebookLMのまとめを見直したんですが、NotebookLMが凄い進化していました。
これのReportってやつを見たら、もっと分かり易くまとまってるんじゃない？
見てみます。
以下に関連する箇所の内容を貼りました。
段落が上手くCopy出来ません。
Screenshotで貼り付けます。
この後に、高度なソースと速度の制御、シミュレーション結果の出力などがあります。
しかしまずはこの部分の理解から始めます。
今週はこの部分のやり方をTutorialをみてまとめます。
6.2 Houdini is HIP - Part 14: Flip Fluids I [10]でHoudiniでのFLIP流体セットアップの基礎を勉強する
＜13:45 Flip Fluid Sourcing and Setup＞を勉強します。
新しいProjectを作成して、Geometryノードを配置しました。
Geometryノードの名前はFLIP_BASICにしていました。
Sphereを作成し、そのSphereが液化する3Dを作成するそうです。
Geometryノードを開いてSphereノードを追加しました。
更にNullノードを追加しました。
Nullノードの名前はSOURCEに変更しました。
Scatterノードを追加しました。
以下の様になっています。
これは流体計算のためのParticleを生成してるんでしょうか？
ScatterノードとSphereノードの間に、Isooffsetノードを追加しました。
TutorialではこのIsooffsetノードを追加した事により、Sphereの表面だけでなくSphere全体をScatter出来るようになったと言っています。
更にIsofffsetノードのUniform Sampling Divsの値を100に増やしました。
更にScatterノードのRelax IterationのCheckを外しまし、
Force Total Countの値を100,000まで上げました。
結果です。
この結果をSOURCEノードに繋ぎました。
そしてDopnetノードを追加しました。
おお、この辺からFLIPの勉強が始まるのか。
Dopnetノードは名前をFLIP_DYNAMICSに変更されてました。
どうもこのTutorialの話ぶりから推測するとこのDopnetノードは前のTutorial（おそらくPyroのTutorial）で既に勉強したようです。
何の説明もしないでどんどん進んでしまっています。
Dopnetノードを開きました。
Outputノードだけがあります。
ここにFlipobjectノードを追加しました。
Flipobjectノードの解説が載っていました。
要はObjectですね。
こういう所を見ると、HoudiniはProceduralな手法を採用してるとは言っても、もろObject Orientです。
今度はFlip solverノードを追加しました。
Flip Solverノードの解説も表示されました。
成程。
という事はこのNodeが必要とするDataをPassすれば流体の計算をしてくれるという事ですね。
以下の様に繋ぎました。
以下のような結果になりました。
なんか、この時点で凄いですね。
SpaceとFを押して画面を以下の様に変更しました。
この巨大な格子を見えなくします。
FLIP Solverノードの以下のVisualize LimitsをDisableします。
この状態でSpace＋Fを押すと以下の様に巨大な格子が消えて青いCube状のObjectにだけ注目するようになります。
Fuild ObjectノードのInitial Dataを見ると、この青い物体が何なのかが分かるそうです。
うーん。
これ見ても全然分かりません。
Initial ConfigurationがGridになってるのは分かりますね。これはParticleじゃなくてGridで計算してるって事でしょうか？
でもそうするとScatterノードで沢山のPointを生成したのはどうなってるんでしょうか？
以下の様に変更しました。
ますSOP Pathですが、SOURCEノードに変更しました。
あ、成程。
ここに先程作成したPointの結果をPassするのか。
そしてInput TypeもParticle Fieldに変更しました。
これはPassしたPointをParticleとして使用するって意味でしょうね。
結果です。
当然、丸くなっています。
Flipobjectノードの以下の設定を変更すると
表示が以下の様に変化します。
Particleで表示されるようになったんですね。
こっちの方が視覚的に理解し易いです。
でもTutorialでは元に戻してしまいました。
Tutorialの説明ではParticleでは実際のScaleがよく分からないのでSpritesの方が良いそうです。
うーん。
そうなのか。
更にPropertiesのParticle Separationの値を0.05に変更しました。
Particle Separationの値を変更する事で以下のような変化をもたらすそうです。
まあ、当たり前の事実を単に説明しただけですね。
この値は一個一個のParticleのSizeも決定してるそうです。
Particle Separationの値を0.01に下げると
以下の様に
それぞれのParticleが可視化出来るようになります。
この時点でPlayを押しても何も起きません。それはForceが加わってないからです。
ので次はForceを追加します。
まず以下の様にGrandplaneノードとMergeノードを追加しました。
MergeノードのInput Operatorsの順番を以下の様に変更します。
その結果、
となりました。
そしてGravityノードを追加しました。
ここでGravityノードをSolverノードの後に配置して、意味があるのかという質問に答えています。
結論だけまとめると、この場所でもSolverノードはGravityの影響を計算するそうです。
今の状態ではParticleの半分は地面にめり込んでいます。
これを直します。
Geometry layerに戻り、Sphereノードの後に、Transformノードを追加します。
そしてTransformノードのTranslateの値を以下の様に変更する事で
Sphereの位置を変更しました。
Dopnet Layerに戻り、Playを実行すると非常に遅いですが、以下の様にSimulation結果が実行されました。
Tutorialの説明によると、このSimulationはいろいろオカシイそうです。
まずVolumeが減っています。
以下のSceneを見てください。
Sphereの一部が凹んでいます。
ああ、成程、液体のSimulationだから全体のVolumeが変化するのはおかしいのか。
納得です。
またFlipobjectノードの以下の値を変更して
Particle表示に変更しました。
この状態でPlayを実行すると以下の様になりました。
結構、綺麗です。
ただ、Tutorialの説明によると、このSplashも正しく見えないそうです。
この辺はよく分からんです。
私の観察眼は平均の人と比較してもそんなに優れてはいません。
私の眼には十分本物のSplashに見えます。
これらの問題をこれから直すそうです。
まず以下の箇所に移動してOpenCLをEnableしました。
先週勉強したNotebookLMの要約でもOpenCLを使用すると計算が早くなると書いてありましたが、そうなんですか？
そもそもOpenCLが何をするのかも知りません。
ChatGPTに聞いてみます。
だそうです。
要はCUDAのOpen規格という事です。
この後、もう一回Playを実行していますが、全然、速くなっていません。
今度は、Flip ObjectノードのParticle Separationの値を0.0125に上げました。
Tutorialの解説によると、前の値である0.005のような非常に小さい値は、Simulationにある問題を引き起こすそうです。
ある問題がどんな問題なのか分からないと、どの値が小さすぎる値になるのかの判断もつかないです。
Particle Separationの値を0.0125にした状態で、Playを実行しました。
この結果に、Tutorialはこれらの値を変更しただけで、こんなにSimulationの結果が本物らしくなったと言っています。
私にはよく分かりません。
なってるんでしょうか？
Sphereが地面にぶつかったところです。
確かにVolumeの減少は無くなってるみたいです。
でもたまたまこのSceneだけの結果のような気もします。
分かりません。
Tutorialの説明では、結局ParticleのSizeが小さすぎるので、Simulationの最中にその隙間が埋まってしまい、結果としてVolumeの減少が生じるそうです。
ここでこの節は終わっていました。
はい。
まあ色々勉強になりました。
今週のHoudiniの勉強はここまでにしておきます。
6.3 Houdini is HIP - Part 14: Flip Fluids I [10]でHoudiniでのFLIP流体セットアップの基礎を勉強した感想
こういう実装系のTutorialの勉強は、今までやってたように、実際にやってる映像をYouTubeで見て、自分でやって理解するのが一番、速く理解出来ます。
NotebookLMの要約は全く役に立ちません。
それだけ分かっただけでも収穫です。
以上です。
7. AIについての調査（ComfyUIの勉強）
AIを使用するためのSoftが大量に公開されていますが、それらについて全く理解していません。
3Dやイラストそして動画関連のAI Softについて、
どんなSoftが公開されているのか？
それらのSoftを使用するとどんな事が出来るのか
どんな方法で操作するのか、
などの一通りの事を勉強しておこうと思い、この章を特別に作りました。
特にComfyUIの使用方法やそれに関して生成出来るイラストや映像について集中して勉強していこうと思っています。
2025-03-30のBlogでUE5でもReinforcement Learningが出来る事を知りました。
のでComfyUIの勉強は一端中止してこっちを勉強する事にします。
今週は、先週勉強した Improving Observations & Debugging (5.5)[11]を実装します。
7.1 先週の復習
先週は、Reinforcement Learningにおける根本的な理解において結構な前進があったんでした。
のでそれを忘れないためにも、先週の勉強内容をここにまとめておきます。
まずはこれです。
Reinforcement Learningにおいて、学習のためにどんなDataを収集するのかは、人間が指定する必要があります。
よくReinforcement Learningは報酬の設定が必要と言われますが、実はどのDataを使用して学習するのかを指定する必要もあったという事が判明したんです。
更にChatGPTも、どんなDataを学習に使用するのかという問題は、強化学習全般において研究分野として現役である。と回答していました。
つまり、どのDataを学習に使用するのかの選定は、Reinforcement Learningの学習が成功するかどうかの根本にかかわる問題であるとも言えるんです。
凄い。
やっと、世界のAIの研究者達が何をやってるのが段々分かって来ました。
UE5のReinforcement Learningにおいては、
InteractorのSpecify Agent Observation()関数でどんなDataを観察するのかを指定しています。
更に言うと
InteractorのSpecify Agent Observation()関数は観察するDataを定義し、
同じInteractorにあるGather Agent Observation()関数で実際のDataを収集します。
7.2 先週勉強した Improving Observations & Debugging (5.5)[11]を実装する
InteractorのSpecify Agent Observation()関数にFloat型のVariableのArrayを追加します。
７つの要素を追加してそれぞれの初期値を指定します。
そしてこのVariableを使用した実装に変更しました。
今度はGather Agent Observationの実装を変更します。
Tutorialには前の実装を消して、この新しい実装を追加しろ。とだけ書かれています。
うーん。
一応、前の実装は残しておきます。
新しい実装を追加してCompileしたら大量のErrorが発生しました。
なんだよ。
Errorの原因を調べます。
まずTutorialには以下の２つをやる必要があると書かれています。
やります。
もう一回Compileします。
お、Errorが消えました。
後はWarningが一個だけあります。
Input pin Location Scale specifying non-default value no longer exists on node Make Location Along Spline Observation . Please refresh node or reset pin to default value to remove pin.
NodeをRefreshしました。
Warningが消えました。
これで先週勉強した内容の実装が出来ました。
7.3 Gather Agent Observationの実装を理解する
先週は、Gather Agent Observationの実装は複雑すぎて分からないと言って理解するのを止めてしまいました。
今週はまだ余裕があるのでこの部分を勉強する事にします。
大体は理解しました。
以下にまとめます。
分からない部分はその時その時で調べます。
まず最初の実装です。
Obs ActorにGet Agentノードで取得したSports Car Pawnをセットします。
これって、一個だけ選択するんですかね。それとも全部のAgentを取得するんでしょうか？
ChatGPTに質問したら、判明しました。
そもそもこのGet Agentノードを使用してるInteractorはそれぞれのAgentに対して一個ずつ作成されているそうです。
こんな感じで。
のでこの場合は、このInteractorがついているAgentが呼び出されるそうです。
納得。
Then 0の先を追っていきます。
Look Ahead ObservationsというCommentで区切られた実装が始まりました。
Track ObservationをClearしました。
そしてTrack Distance SamplesでFor each Loopを開始しました。
Track Distance Samplesの値に何かを足してその結果をSample Distanceに保存しました。
何の値を足したんでしょうか？
恐らく今のAgentの位置だと思います。
うーん。
でもEgo Centerだからな。
違うかもしれませんね。
実際の実装を見て確認します。
Splineからの今のAgentの距離のようです。
このGet Distance Along Spline at Locationノードが何を計算してるのかが今一分からないんです。
今、Agentがいる位置とSplineとの距離を計算してるの？
ChatGPTに質問してみます。
分かりました。
いや、凄い。
めちゃめちゃ分かりました。
以下の事をGet Distance Along Spline at Locationノードは計算してるそうです。
まずAgentの位置から最も近いSplineの点を探します。
その点からSplineの始点までの長さ、最短距離ではなく実際のSplineの形状に沿った長さを計算します。
その計算した長さを返すそうです。
ChatGPTによるとこの長さを計算する事により
などに使用出来るそうです。
成程。
一寸ずつですが理解が進んでいます。
良い事です。
となると先程のSample Distanceノードには
Splineの始点から、今のAgentがいる位置にもっと近いSplineの点の距離＋TrackDistanceSamplesのそれぞれのElementに保持されている値が保存されたという事です。
はい。
次の実装です。
Look Ahead Observationsはここで終わっています。
Track Observationsに何かを追加していますね。
Track ObservationsはLearning Agent Observationで構成されるArrayです。ここにはLearning Agent Observationが追加されたと考えられます。
Learning Agent Observationが何なのか、ChatGPTに質問してみましょう。
完璧に分かりました。
まずLearning Agent ObservationはStructです。
その中身ですが、Specify Agent Observation()関数で指定した要素が入っています。
これがSpecify Agent Observation()関数が、どんなDataを観察するのかを指定しているという事の実情でした。
単にStructの構造を決定してるだけでした。
先にそう言ってくれたら、もっと簡単に理解出来たのに…
そしてその時に作成されたStructがLearning Agent Observationになります。
ここ（Gather Agent Observation）では、そのLearning Agent Observationのそれぞれの要素に値をセットしていきます。
この実装は、その値が指定し終わったLearning Agent ObservationをTrack Observationに保存したという事です。
ではそのLearning Agent Observationのそれぞれの値をどうやってセットしたのかを見ていきます。
一つ前の実装です。
In Observation ObjectがこのAgentのLearning Agent Observationだと思います。
そしてMake Struct ObservationノードがそれぞれのElementの値を指定してるんでしょうね。
ChatGPTに質問して確認してみましょう。
なんとここでLimitに達してしまいました。
クッソ。
じゃあ、続きはCopilotで質問する事にします。
回答です。
で、この後の説明が長くなるので結論だけまとめると
Make Struct Observationノードには特定のStructの構造は無いそうです。
え？
つまりここでは、Make Mapで作成したMapの構造がそのままStructに変換されると言っています。
それじゃ、さっきの話と矛盾するじゃん。
ここでどんな構造のStructでも作成出来るとしたら、Specify Agent Observation()関数は何をしてるの？という事になります。
うーん。
これは結構面白い矛盾点です。
この矛盾を解決するにはSpecify Agent Observation()関数の実装をもう一回見直す必要があります。
Specify Agent Observation()関数の実装が実際のStructを生成して、そのStructと同様の構造体をLearning Agent Observationが最初から保持してるとしたらCopilotの説明は間違っています。
逆に、Learning Agent ObservationにはStructとしての何の制約もなかったらChatGPTの説明が間違っている事になります。
あるいは両方のAIの説明はともに正しくて、まだ私が知らない深い論理が隠されている可能性もあります。
この問題は来週、検証する事にします。
今週のLearning Agents (5.5)の勉強はここまでとします。
8. DirectX12の勉強
3D Graphicsを作成するのにOpenGLを使ってるとバカにされるからDirectX12の使い方も勉強しようとしたら、Windows 8ではDirectX12が使用出来なくてずっと勉強を我慢していました。
で新しいPCを買ってやっとDirectX12を勉強できる環境になったら、もうDirectX12を勉強する人がいなくなっちゃってたんです。
のでこれも出来たら何したいというのは無いですね。
ああ、昔MMDを自分で作りたいというのはありました。それを目的にします。
今週は、先週出来なかった「DirectX 12の魔導書」の勉強を先にやります。
8.1「DirectX 12の魔導書」を勉強する
8.1.1 「5.12.1 Upload用のResourceの作成」の実装が必要なのか確認する
先週、あえてこの教科書の勉強をしなかったのは、いい加減な調査でこの決定を下すと後に響くから、それならやらない方が良いと判断したからです。
簡単に前々回の勉強の内容をまとめると以下のようになります。
Resource Objectを作成してUpload Heapを作成する方法を勉強した。
実装しようとしたらSample Codeにこの部分のCodeが無かった。
よく考えたら、TextureをGPUに送るための実装は既にしてある。
この部分（5.12全部）は実装する必要ないのでは？
となりました。
今週はそれを確認します。
＜教科書の説明＞
のっけから正解らしく回答が、教科書に書いてありました。
ID3D12GraphicsCommandList::CopyTextureRegion()関数を使用してDataをCPUからGPUに転送する方法をここでは教えると書いてあります。
今までのDataをCPUからGPUに転送する方法は、ID3D12Resource::WriteToSubresource()関数を使用した転送方法だったそうです。
そうなのか？
この辺、全然理解していません。
まずこの２つの関数のどっちを使用してTextureをCPUからGPUに送っているのかを確認します。
Sample Codeです。
ID3D12Resource::WriteToSubresource()関数のみを使用していました。
成程。
だからSample Codeには5.12節の内容が全く無いのか。
しかも親切にComment欄に「WriteToSubresourceで転送する用のヒープ設定」と書いてあります。
だからこの部分の実装は全くないという事です。
うーん。
解明。
謎が解けました。
＜「5.12.1 Upload用のResourceの作成」の実装が必要なのか？＞
Projectを動かすためだけならこの部分の実装は必要では無いです。
しかしせっかくCPUからGPUにData（Texture）を送るには、Resource（Dataを送るためのObject（Struct？）とHeapが必要で、
そのHeapにはCPU、GPU両方がAccess出来るUpload HeapとGPUだけがAccess出来るがその分速く読み込めるDefault Heapがある事。
さらに、教科書のCreationNodeMaskとVisibleNodeMaskの値は０になっていますが、実際は1の方が好ましい事。
などが分かっているので、この部分は日本で最も理解してる人になるべく、全部理解してしまいましょう。
となると、今までの実装、
ID3D12Resource::WriteToSubresource()関数
を使用した実装方法を復習する必要も出て来ます。
こっちを先にやります。
今週の「DirectX 12の魔導書」はここまでとします。
来週はID3D12Resource::WriteToSubresource()関数を使用したCPUからGPUへのData（Texture）の転送方法を復習します。
そしてその後で、
ID3D12GraphicsCommandList::CopyTextureRegion()関数を使用したCPUからGPUへのData（Texture）の転送方法を勉強する事にします。
更にLötwig Fusel氏のD3D12 Beginners Tutorial [D3D12Ez]でのCPUからGPUへのData（Texture）の転送方法との違いも検証します。
以上です。
8.2 Lötwig Fusel氏のD3D12 Beginners Tutorial [D3D12Ez]を勉強する
8.2.1 Resources, Heaps & Copying | D3D12 Beginners Tutorial [D3D12Ez] [12]の続きを実装する
先週勉強した内容を実際にやってみます。
Release Modeで実行します。
Release Fileを開くと新しいexe fileが出来てます。
Nsight Graphicsを起動させます。
前に作成したProjectを開きます。
新しく作成されたExe Fileを指しています。
Launch Frame Debuggerを押します。
その後も何個かButtonを押したら、起動しました。
Full Screenで紫色になっています。
F11を押してFull Screenを停止しました。
Nsight Graphicsの画面に移動すると
書かれていました。
取りあえずこれは無視します。
左上の表示は以下の様になっていました。
Frame DebuggerからAll Resourceを選択します。
開いたWindowから以下のTexture2D 4を選択しました。
以下のWindowが開きました。
左下に注目すると
以下に示したResource Inforという項目があり
Heap TypeにDefaultと書かれています。
それに対してBuffer１の方は
Upload Heapになっていました。
これでTutorialがやった内容は全部やりましたが、もう少し色々いじってみます。
9. まとめと感想
10. 参照（Reference）
[1] Procedural Minds. (2024, August 25). Do you want to remove just one side of your building? | UE 5.4 p4 [Video]. YouTube. https://www.youtube.com/watch?v=ngizgkYM2Ac
[2] Control Rig. (n.d.). Unreal Engine. https://dev.epicgames.com/documentation/en-us/unreal-engine/control-rig-in-unreal-engine
[3] Full-Body IK. (n.d.). Unreal Engine. https://dev.epicgames.com/documentation/en-us/unreal-engine/control-rig-full-body-ik-in-unreal-engine
[4] Jhoward. (2022, May 16). Getting started with NLP for absolute beginners. Kaggle. https://www.kaggle.com/code/jhoward/getting-started-with-nlp-for-absolute-beginners
[5] NVIDIA Isaac Sim - MUSHR RC Car - Ackermann Tutorial. (n.d.). YouTube. https://www.youtube.com/playlist?list=PL60qgWqGu6k82AJ2SDWOscEKLjCc5tdEW
[6] Isaac SIM UI and workflow Tutorials — Isaac SIM Documentation. (n.d.). https://docs.isaacsim.omniverse.nvidia.com/4.2.0/introductory_tutorials/index.html
[7] Running Python Code from External Editors — Isaac Sim Documentation. (n.d.). https://docs.isaacsim.omniverse.nvidia.com/4.2.0/advanced_tutorials/tutorial_advanced_code_editors.html
[8] Isaac SIM Extension Templates — Isaac SIM Documentation. (n.d.). https://docs.isaacsim.omniverse.nvidia.com/4.2.0/advanced_tutorials/tutorial_extension_templates.html
[9] Isaac SIM Workflows — Isaac SIM Documentation. (n.d.). https://docs.isaacsim.omniverse.nvidia.com/4.2.0/introductory_tutorials/tutorial_intro_workflows.html#isaac-sim-extension-workflow
[10] Nine Between. (2023, October 30). Houdini is HIP - Part 14: Flip Fluids I [Video]. YouTube. https://www.youtube.com/watch?v=DJfkTV3Pivc
[11] Learning agents (5.5) Improving observations & Debugging (5.5). (n.d.). Unreal Engine. https://dev.epicgames.com/community/learning/courses/GAR/unreal-engine-learning-agents-5-5/1w7V/unreal-engine-improving-
[12] Lötwig Fusel. (2023, July 27). Resources, heaps & copying | D3D12 Beginners Tutorial [D3D12EZ] [Video]. YouTube. https://www.youtube.com/watch?v=Mehv3B6l9JY
