お世話になっております。
　
この度ご相談したいと思いましたのはOpenWorldを想定した広さの背景の出力に関してです。
まずこの動画を見て頂きたいと思います。

　
これは9KM x 9KMを18x18（総数324タイル）のタイルに分けたサンプルで、Biomeも設定済みのものです。
PDGを利用した出力を行っており、unreal_worldcomposition_prepareノードでタイルに分割しております。
　
それを範囲を小さく絞って出力してBakeを行う様子を撮影しました。
　
相談したいというのはこのBake時間に関連するものです。
動画を見て頂くとCookOutputに比べてBakeの時間が非常に長く、Bakeの時間の大半はPercistantLevelから出力先レベルへの関連付けの処理に要する時間が大半になります。
　
例えばLandScape側はFHoudiniEngineBakeUtils::BakeLandscapeObject関数内のLandscapeInfo->MoveComponentsToLevelがほとんどの時間を消費しており、Instance側はAssetRegistryへのRenameがBake内の時間の多くを消費しております。
つまり一旦Percistant Levelに生成してから他のレベルへの出力　という経路が時間がかかるような事態になっております。
現在312タイルすべてを出力できるように18.5.567から追加されたBlueprint、PythoneのAPIで自動処理を組んでみたのですが、24時間以上かかって終わるような状態で現状UE4との組み合わせでの広範囲のマップの管理が難しい状態です。
そのため、相談　というのはCookOutputとBakeをあわせたような機能つまりActorの生成自体をunreal_level_pathアトリビュートへ出力する機能追加、　もしくは他の方法でも短く終わらせるためのTipsはないでしょうか？
　
広さの参考としては、例えば　
　・アサシンクリードヴァルハラ 120平方km
・ゴースト・オブ・ツシマ 28平方km
・フォールアウト4 9.84平方km
・レッド・デッド・リデンプション 41平方km
　
とこのぐらいの広さ相当のゲーム制作をUE4とHoudiniを組み合わせて制作する事を想定すると、上記の部分は是非改善したいと思っています。
　
一応他の情報としては、大きい広さを作るにあたって現状工夫しているものとしては
1.細かい配置物は、基本的にHISMを使ったクラスタでほどほどの粒度にまとめる事
　Clusterノードとアトリビュートのunreal_split_attr,unreal_hierarchical_instancerなどを使用。
2.範囲を絞って出力できるようにした(全域をこの物量のcookOutputするとメモリが数百GB以上かかったため)
3.全域出力のため、18.5.567の機能を使って範囲出力をループして最後まで書き出し続ける機能を作った
　これによりメモリ消費を抑えつつ最後まで書き出せるようにしました。
4.タイルを細かくしている根拠はランタイム時のメモリを考慮しての事。つまりマップのStreamingを細かい単位にしたかった。
　
サンプルシーンは
https://www.sidefx.com/forum/topic/79656/ [www.sidefx.com]
こちらで送ったものと同一になるのですが、別途お渡しした方が良ければ送らせて頂きます。
　
以上です。こちら相談させて頂く事は可能でしょうか？

すみません、気が付くのに遅れました。来週、担当開発者の所見を待って、別途ご連絡差し上げます。

社内開発担当者と、このビデオ (https://vimeo.com/477285390) の Simon と話してみましたが、ベイクは時間がかるのは避けられないようです。

一つの回避策として、試してみないとわからないですが、18 x 18 として行うのではなく、9 x 9 を 4回繰り返す方が時間短縮となるのではないかとのことです。

もう一つは、今後 UE5 が出た際の World Partition での方が時間短縮が見込まれる可能性が高い、ただし開発はこれからとなります。

上記で列記されたゲームはどれも自社製エンジンで開発されているようですね。

取り急ぎ回答まで。

検討、回答して頂きありがとうございます。
お手数お掛け致しました。
　
列挙したゲームは大きさの参考に上げたものでした。誤解を招き申し訳ございません。
つまりこの大きさのゲームを開発するニーズがどのエンジンであれ存在する事をお伝えしたかった次第です。
（「Houdiniを導入する」検討材料になりうる　という話を推したかったのですが、そもそもOpenWorld関係なく強力なツールなので要らない説明でしたね・・・）
　　
以下確認させてください。

▽「18 x 18 として行うのではなく、9 x 9 を 4回繰り返す方が時間短縮となるのではないかとのことです。」
　こちらですが、
　　LandscapeInfo->MoveComponentsToLevel
　が重い原因の半分程度はLandScape関係のテクスチャ再生成に起因している部分になります。
　またActorの移行も比較的回数が多く重い処理であるRenameの回数は提案されたやり方では変化がなく、そのため9x9を4回　にしても 18x18を1回にしても計算回数やテクスチャの生成回数は変わらない　との認識です。
　Save時間は短縮されるかも知れませんが時間としては誤差になるかと思います。
　こちらは時間短縮の提案に関して何かしら根拠をお聞かせ願えればと思うのですが如何でしょうか？
　一応お渡ししたシーンファイルも3x3,4x4,5x5と範囲出力を変更できるように対応していて、いくつか試していますがそれぞれ時間は大きく変化する事はない次第です。
　
　
補足：　もしかしたら上手く伝わらなかったかも　と思い念のための記述です。考慮済みであれば　スルーしてください。
　提案させて頂いたものは、現在のCookOutputとBakeが分かれていると
　　1.生成コスト
　　2.移すコスト（前述の通り移す際に、LandScapeはテクスチャの再生成も行うためLandScapeをもう一回出力するような事と同じ事になってしまう。）
で一部は処理が重複処理になっています。
　これを最初からターゲットレベルにOutputする事によって短くなるのではないか？
　という事をお伝えさせて頂いた次第です。
　
　つまりBake処理を高速にするのではなく、【CookOutput先がBake先のパッケージであれば結果的に速くなるのではないか？　
　LandScapeは重複処理部分で、Actorはパッケージ移行のためのRename処理分が無くなるはず】
　という事ですね。

UE4 プラグインはクック時、World Composition (WC) に登録する前に、「ローカル」の地形を作成します。
(編集) 操作時に再クックされたり削除される可能性のある仮のレベルを WC に登録するのは不可能です。
よってベイキングには WC に登録するサブレベルの作成も含まれ、これが非常に時間がかかります。

可能であれば、簡単に誰でも再現できるような、最低限のシーンファイルと再現方法をいただくことは可能でしょうか?
そういうのがあると、問題解決への早道となります。

宜しくお願い致します。

【対応が不可能】　という話で了解致しました。
　
一応ですが、以前お渡ししたシーンファイルは再現可能だと思うのですが、そちらでは再現が出来なかった　という感じでしょうか？
次回サンプルを送る時の参考にさせて頂ければと思います。

私が「簡単に誰でも再現できるような、最低限のシーンファイルと再現方法をいただくことは可能でしょうか?」
という理由は、ほぼここに書いてある通りです。
https://www.sidefx.com/ja/forum/topic/75614/ [www.sidefx.com]

今回の問題で再現が必要なのは、Unreal 内での実際の操作です。
いただいたファイル(群)は、.zip ファイルに .hda と .hip ファイルでしたが、Unreal 内での操作方法の記述がありませんでした。よって、こちらで解析を始めるには、その再現から始めなければなりませんが、第三者が再現しようとすると、非常に時間がかかるか、間違った解釈になりがちです。

担当開発者は常に複数のケースを抱えているわけで、再現方法が無いものは後回しになりがちです。
私ですら、これを見ている間、別 UE4 の問題を複数見ていました。

つまり、問題があること、その症状もわかりましたが、それ以上の解析をして改善につなげるには、(他の問題で頭を抱えている人がすぐに取り付くことができるような)再現方法があると、対応が著しく早くなります。
よって、UE4 の中での操作の手順をいただけないでしょうか?