１．今週の予定
＜LandscapeのみのGameを作成する＞
以下の事をやります。
- LandscapeのLayerのMaterialを調整
- Beach-＞Sea
- 洞窟の作成
＜Materialの勉強＞
まだ何をやるか決めていません。
Render Bucket氏のSubstrateのTutorialの２をやるか、Ben Cloward先生のAdvanced Materialのどれかを勉強します。
＜Niagaraの勉強＞
Disintegration into Sand Unreal Engine 5.2 Niagara Tutorial [1]を実装します。
＜戦闘システムの続きを作成する＞
今週からUIの改善を始めます。
＜Gaeaの勉強＞
Data Groupに属するNodeの調査の続きをやります。
＜Houdiniの勉強＞
Epic Game社がGDCで発表したHoudini関連の動画を見ます。
＜UEFNの勉強＞
Epic Game社がGDCで発表したVerseの続きを見ます。
＜YouTube動画の作成＞
なんか動画を作成します。
＜DirectXの勉強＞
C++ DirectX 12 Game Engine - [S01E03] - Creating A Game Engine [2]のFinishing Touchesの続きを勉強します。
2. LandscapeのみのGameを作成する
2.1 LandscapeのMaterialを改良する
以下のような設定になっています。
- Layer CliffにMF_River1をセット
- Layer RiverにMF_Sea1をセット
- Layer SandにMF_Cliff1をセット
- Layer SeaにMF_Sand1をセット
こっちの方がLandscapeが更に本物に見える気がしています。
試してみます。
変更前です。
変更しました。
結果です。
うーん。今の時点では何とも言えません。
以下の表示がされていました。
Landscape Physical Material Needs to be Rebuiltを調べます。
公式のForumであるUE5: “Landscape Physical Material Needs to be Rebuilt”[3]に直し方が載っていました。
だそうです。
Play中の画面です。
Beachの砂と土の境目です。
綺麗に分かれています。
石の層と緑の層が混じっている所です。
そんなに悪くない気がします。
これでやる事にします。
以下に示した様に、先週Landscapeの境界線がはっきり見えてしまっていると書きました。
これの直し方が分からなくて途方に暮れていたんですが、なんと
直っています。
これって先程行ったBuild All Landscapeのお陰でしょうか？
なんかそんな気がしています。
2.2 洞窟を作成する
それでは今週のMainである洞窟の作成を行います。
以下の箇所に作成する事にしました。
先週のBlogを見ながらやっていきます。
＜Landscape Visibility Maskノードを追加する＞
まずLandscapeに使用しているMaterialのBlend ModeをMaskedに変更します。
以下の様にしてLandscape Visibility MaskノードをOpacity Maskに繋ぎました。
Landscape Modeに変更してSculptそしてVisibilityを選択します。
BrushでLandscapeをこすってみました。
おお、消えています。
多分、Landscapeのサイズとかの影響だと思いますが、以下の形状に穴が変形してしまいました。
何度試しても同じです。
これでSaveして洞窟の入り口を作成する事にします。
以下の入り口を作成しました。
凄い気持ち悪くなりました。
以下の様になりました。
中から見るとこんな感じです。
Landscapeの中はこんな感じです。
Landscapeの中身も作成します。
Boxを作成してCumberにします。
中に入ると以下の様になっています。
側面から見た場合です。
それなりには良いですが、以下に示した様にFloorの継ぎ目に隙間があり、
地下から太陽光が漏れてくると言うあり得ない事態が発生しています。
更にChamberの一部が山からはみ出しています。
この辺は素人そのものの作りです。
まあ、初めてのChamberの作成なので仕方ないです。
今週のLandscapeの作成はここまでにします。
2.3 洞窟を作成した感想とPackagingのTest
今回、初めてLandscape Visibility Maskノードを使用してLandscapeに穴を開け、洞窟を作成しました。
完成品の質はともかくとして、一応出来ました。
これで洞窟を作成する事も出来るようになりました。
その中で色々な知見や課題も分かりました。
それらをここにまとめます。
＜穴の形状と大きさ＞
以下の様にLandscapeのScriptのVisibilityを使用して穴を開けたとします。
この時は大体、理想的な穴の形状と大きさです。
ところが、Landscape ModeからSelectionに戻るか、もしくはその後にSaveをすると以下の様に穴が変化します。
形状と大きさが大きく変化し、想定していた事態とは大きくかけ離れます。
Wireframeや
Naniteの
形状が影響しているのかそれぞれ可視化して確認しました。
以下の赤線で囲った部分はWireframeやNaniteの四角と同じ形状です。
となるとWireframeやNaniteの形状通りにしか穴を作成する事は出来ないとなりますね。
Landscapeのサイズを500倍にしているのでWireframe通りの穴しかあける事が出来ないとなると、通常の5倍x2で25倍の穴しか作成出来ないとなります。
Landscapeを500倍した弊害がここで出て来ました。
でもこれ以外の弊害は今の所確認出来ないし、正直通常の100倍で作成するよりも利点もありそうですし、何より通常の100倍のLandscapeを作成するにはGaeaの有料版を買う必要があるので、今回はこのままでいきます。
＜穴の位置＞
今回は以下の場所に洞窟を作成したんですが、
なんとPlayして確認したら、Quinnが洞窟まで登れません。
洞窟の前の坂がきつ過ぎて、途中でずり落ちてしまいます。
階段を付ける事で何とか改善しましたが、穴を開ける位置はQuinnが到達出来る場所なのかどうかを前もって確認する必要があります。
Unreal Sensei氏が建物などを配置する時は必ずCharacterを配置してその大きさを確認しながら作成しないと、超巨大な建物になったり、逆に小さすぎる建物になったりする。と警告していたので
以下のようにQuinnを配置して洞窟の入り口は作成しました。
ので洞窟の大きさに関しては注意しながら作成しましたが、Quinnが洞窟に入れない。のは洞窟がほとんど完成するまで全く気が付きませんでした。
穴を開ける位置にも注意が必要だと知りました。
因みに今回は階段を足して洞窟に入れるようにしました。
＜洞窟の中＞
もう楽したいだけなんですが、もう一枚Landscapeを敷けないでしょうか？
そうしたら作成が凄い簡単になります。
後は、Houdiniの使い方が上達するまで待って、Proceduralで大量の洞窟内の形状を作成出来るようになるしかないです。
建物そのものを手動で作成するのは結構大変です。
＜Packagingを試す＞
普通にPackagingは出来ました。
Playしてみます。
Visibilityで開けた穴はそのままPackaging出来ていました。
作成した洞窟の入り口も普通にありました。
中もUE５と同じ形状で再現されていました。
後、Landscapeの繋ぎの境目は直っていませんでした。
Memoryの使用率も見ておきます。
かなり使用率が高いですね。
同じ箇所のShader Complexityも確認しておきます。
うーん。
特に前と差がある訳ではないですね。
＜境界線の直し＞
World PartitionのSub Landscape同士の境界線が直ってない事が判明しました。
別なMaterialをLandscapeにつけて
LandscapeのMaterialを変更した後に、元のMaterialをLandscapeに直します。
これでMaterialのBuildがRe-buildされるかもしれません。
駄目でした。
これは中々直らないですね。
2.4 Let's Build the RPG! - 56 – Landscape Cave Sculpting and Lighting – Unreal Engine 5 Tutorial [4]の続きを勉強する
Landscapeの下にChamberを作成してLightingの調整は絶対必要な事を悟りました。
のでNumenBrothers氏のLet's Build the RPG! - 56 – Landscape Cave Sculpting and Lighting – Unreal Engine 5 Tutorial [4]の続きを勉強します。
＜Creating a light hole (for natural light to shine through) in the top of the cave＞
ここではGod Rayのための光が入る穴を開けています。
単にVisibilityで穴を開けただけです。
穴の作成方法は特にここでまとめる内容ではないのでSkipします。
結果だけ示します。
＜Indoor lighting with the Environment Light Mixer, including god rays＞
God Rayの作成方法についてです。
２つやり方があるそうです。
一つ目です。
以下に示した様な直接太陽を見た得に発生するGod Rayの作成方法だそうです。
Exponential Height Fogにある
Volumetric FogにCheckを入れます。
そしたらTutorialで、これは直接、Lightを見た時は関係なかったと言ってCheckを消してしまいました。
また後でCheckを入れるそうです。
そしてDirectional Lightに行って
Light Shaft BloomにCheckを入れました。
こんな感じでGod Rayが発生しました。
もうこれで完璧じゃん。
更に
の値を調整する事でGod Rayを濃く出来るそうです。
Lightを見ないと以下に示した様にGod Rayが消えてしまいます。
ここにGod Rayが表示されるようにします。
まずは先程のVolumetric FogをEnableします。
しかしGod Rayは現れません。
Exponential Height FogにあるFog Densityの値を0.02から0.2にします。
すると以下のようなGod Rayが表示されるようになります。
今度はGod Rayを濃くするためにExtinction Scaleの値を10にします。
結果です。
濃くなりました。
＜Postprocess brightness settings for our player character＞
これでGod Rayは終わりですが、もう一つだけ調整します。
それはCave全体の明るさです。
Post Process Volumeを選択して
以下に示したMin BrightnessとMax BrightnessをEnableします。
Min Brightnessの値を0.4に上げます。
すると以下に示した様に
全体的に真っ黒になり、更にPhoto-Realisticな洞窟になります。
Numen Brothers氏は、この部分の説明で、何でMin Brightnessの値を上げると暗くなる理由はよく分からないと言っていますが、これはGaeaのMinとMaxの指定と同じです。
要はどれかのBufferのImageは全てのPixelの光の当たり具合を表す値を持っています。
その値に対してMinとMaxの間の値をもっている箇所だけBrightになるような設定になってるんです。ので今までMin Brightnessの値が0.04だったので0.04以上の値はBrightにセットされたんです。
これが、今度は0.4になったので0.4以下の値を持っている箇所はもうBrightじゃなくなったんです。
これがMin Brightnessの値を上げると暗くなる理由です。
最後にTipとしてPost Processの値を変更出来るNodeが紹介されています。
Min BrightnessとMax Brightnessの値は洞窟の外側と内側で変える必要があるそうです。
特に海岸では明るすぎになる傾向があり、洞窟はその逆に暗すぎる傾向があるそうです。
のでBrightnessの値を動的に調整したい時はこのNodeを使用すると言いそうです。
以上でした。
2.5 Let's Build the RPG! - 56 – Landscape Cave Sculpting and Lighting – Unreal Engine 5 Tutorial [4]の続きを勉強した感想
God Rayそのものは作成しませんが、Post ProcessのMin BrightnessとMax Brightnessの値の調整はすぐに試す事にします。
思ったよりは短かったです。
Post Processを以下の様に追加しました。
Post ProcessでBrightnessを探します。
Min EV100 とMax EV100しかないです。
この値を変更してみます。
結果です。
Min EV100の値を0にすると画面が真っ黒になって何も見えません。
時間が経っても真っ黒なままです。
Min EV100の値を-0.2にした状態でPlayしてみます。
奥が壁になっているのかどうかすら分かりません。
怖さが倍増しました。
Post Processの調整は、かなり大きな話題なのでまとめて勉強しようと思っています。
今週は、洞窟が作成出来たし、Lightの調整方法についても学べたのでそれなりには進みました。
ただLandscapeの境界線が消えないのが悩ましいです。
3．Materialの勉強
今週は、RenderBucket氏のUnreal Engine 5.2 - Crystal, Ice, Gemstone Materials Tutorial [5]を勉強します。
UE5.2のSubstrateに関しては、先週の勉強で基礎は理解出来ましたが、実際に氷を作成した時に、以下に示した私が作成した氷よりも
Photo-Realisticなのかどうかが知りたいからです。
後、Crystalについてもどの位Phot-RealisticなGemが作成出来るのか知りたいです。
昔、OpenGLでGemを作成して、あまりにも本物そっくりなGemを作成してそれを見た人達を驚愕させた経験があります。
のでSubstrateで作成したCrystalがどれだけPhot-Realisticなのかにも興味があります。
3.1 Unreal Engine 5.2 - Crystal, Ice, Gemstone Materials Tutorial [5]を勉強する
まず軽く全部見ます。
長い。40分もあります。
最初のIntroの説明だけ見てまとめます。
＜Intro＞
以下の５つのMaterialの作成について勉強するそうです。
Crystalです。
Blurが確認出来ます。
Specular Lightもありますね。
とにかくGem感がすごいです。
Magma Rockです。
Magmaを透明なCrystalに閉じ込めた感じです。
凄い事は凄いですが、ここまで凄いのを見ていると＋Alphaが欲しいです。
Iceです。
うーん。
これがIceなのか。
こういうIceが存在する事は知っていますが、もう少し透明感のあるIceを作成して欲しかった。
Gemです。
これははっきり言って出来が悪いです。
こんな石を見せられても欲しくならないです。
ここでTutorialが説明しています。全部同じMaterialで作成したそうです。
Parallax Occlusion Mappingを使用して作成した。と言っています。
Parallaxって日本語でいう視差って意味です。
Gemです。
同じMaterialを使用しても対象となるStatic Meshによって印象が全く変わる事を示してます。
近づくとこんな光り方をしています。
＜Materialの作成＞
何と、Substrateを使用していますが、このMaterialはSubstrateを使用する必要は無いそうです。
Gem系のMaterialを作成するのに重要なのはTextureですが、以下に示した様なTextureを使用しているそうです。
３つNormal Mapがありますね。内側の層用のNormal Mapでしょうか。
残りのTextureの内３つはこのNormal Mapに対応したNoiseのTextureみたいです。
となると純粋なGemのTextureは２つだけなんでしょうか？
まずParallax Occlusion Mappingノードを追加します。
これってDefaultで存在しているの？
これだけ確認します。
ありました。
後、確かにSubstrateを使用しなくてもParallax Occlusion Mappingノードを使用出来ます。
Tutorialでは以下の様に使用していました。
Parallax Occlusion MappingノードのInput側の設定です。
Height Map TextureにTexture Objectノードをつなげるのは、まあ納得です。
しかしHeightmap ChannelにはVector4を繋げています。
うーん。よく分からん。
以下のTexture SampleノードにTextureを追加しました。
するとPreviewのImageが以下のようになりました。
うーん。
ここが内部の形状を担当しているのか。
Parallax Occlusion MappingノードのHeight Ratioの値を変更すると
内部の模様が存在する深さを変更する事が出来ます。
今度は色を追加するそうです。
Parallax Occlusion Mappingノードの
Heightmap ChannelにVector4を追加します。
Tutorialでは、ここでColorを設定する利点について説明していますが、よく意味が分かりません。
結果です。
うーん。
あんまり変わってないような。
今度は以下の箇所に色を追加する実装を追加しました。
結果です。
こっちの色付けは分かります。
内側の模様の色を指定しているんです。
しかもDiffuse Abedoに繋がっていますので、なぜこの実装で色が変化するのかも納得出来ます。
さっきのParallax Occlusion MappingノードのHeightmap Channelの指定は外側の透明な箇所の色でも指定しているのかもしれませんね。
Lerpノードを使用して以下の様に組む事も可能です。
結果です。
これ敢えてTextureとPinkを掛けたものをBに繋ぐ必要が有ったんでしょうか？
この実装で以下の色合いに変更すると
以下のように
浅い層と深い層が存在するように見えるようになります。
Tutorialではこの２つのColorを指定するConstantノードをParameter化してInstanceから色を変化させ以下のようなMaterialを作成していました。
うーん。
大体、このTutorialで何をしているのかが分かって来ました。
このParallax Occlusion Mappingノードの使用方法を説明しているんです。
今度はNormal Mapを追加します。
以下の様に追加しました。
するとなんと球の表面が凸凹し始めました。
今度はNormal MapのUVsの値をParallax Occlusion MappingノードのParallax UVsと繋ぎます。
すると以下に示した様に
中の模様が凸凹になります。
今度はGlowを追加します。
もう単純に光らせるためには以下に示した様にEmissive Colorを使用します。
この実装では黒い部分が光っています。
色を追加します。
結果です。
うーん。
これは想像してたColorと違いますね。
Glowを追加したいんで、Emissive Colorを使用するのはわかります。
でも、Emissive Colorの値が1以下だとGlowは起きないはずです。
実際、このPreview画面でGlowは起きていません。
とりあえずTutorialの続きを見ます。
光過ぎです。と言っています。
そしてCheap Contrastノードを追加して色の強さを調整しました。
反転したTextureの白い部分の値を0.1にしているんでしょうか？
結果です。
ぱっと見はそんな感じです。
Parameter化してLevel上で確認しています。
TutorialはこれをGlowと呼んでいますが、どうなんでしょう？
Glow無しです。
うーん。
確かに光ってる感はあります。
でも一般にGrowって言ったら光の周りに出来る淡い線やRingを指しますよね。
そういう意味で使用はしてないみたいです。
以下の様に整理しました。
Commentを使用してBlock化するだけでこんなに分かり易くなりました。
Normal Mapの値の調整方法に以下のやり方を採用していました。
うーん。
これは間違っているでしょう。
まず、RGの値が１以上になってNormalize（正規化）しなくなる可能性があります。
Bの値とRGの値に整合性が取れなくなります。
後、Normal Mapの値のRangeは-1～1です。
つまりSinかCosの値を足してNormalizeした方が変化するはずです。
もしくは0～１の間の値を掛けるかです。この場合は1より大きな値になる事はないです。
そしてBの値は2023-02-06のBlogで使用しているDerive Normal Zノードを使用して求めるべきです。
また２つのNormal MapをBlendしたい時は以下のNodeが正しくBlendしてくれます。
それはともかくとして、Tutorialでは以下に示した様にParameterを調整してIce調のMaterialを作成しました。
うーん。
これがIceの作成方法か。
まあ、こういうIceもありますし、値を上手く調整したら中をもっと透明にも出来そうです。
このIceに対する感想は一端保留にして次に進みます。
今度は以下のGemの実装についてです。
表面がガラスのような光沢があります。
とTutorialが言っていますが、言うほどありますか？
これでTutorialは終わりでした。
＜感想＞
うーん。
感想と言うほどの内容が無かったですね。
3.2 Fabric Shaders - Advanced Materials - Episode 10 [6]を勉強する
これだけと短いのでBen Cloward先生のFabric Shaders - Advanced Materials - Episode 10 [6]も勉強する事にします。
まず軽く全部見ます。
見ました。
これも簡単でした。
以下に内容をまとめます。
ここではUEやUnityでどうやって服の質感を出すのかを学習します。
まず通常のRenderingを行うと、Plasticのような質感になります。
その理由ですが、UEではDeferred Renderingを採用しており
以下に示したようにMaterialの特性をGBufferに焼き付けておいて、そのDataを使用してMaterial上における光の影響を計算します。
この光の計算に使用されるModelが全てのMaterialで同じなのでPlasticのような質感になります。
のでこの光の計算に使用されるModelをCloth用に変更する必要があります。
それはShading Modelの設定にClothをセットする事で変更出来ます。
これだけです。
以下にTutorialで示したClothの例をまとめます。
まず以下のMaterialを作成します。
これはまあ普通の実装です。
ここでShading ModelをClothに変更し、以下に示したFuzz ColorとClothの値を指定します。
結果です。
これが
こうなりました。
簡単にまとめるとこれだけです。
3.3 Content ExampleでClothやSubstrateを使用した例を見る
まだ短いのでもう少しだけ勉強します。
Content Exampleは5.1が最新でした。
以下のMapがあったのでこれを見る事にします。
以下の説明がありました。
Chaos Clothってどんな機能なんでしょう？
とりあえずはここにある例を全部見る事から始めます。
布が風で揺らいています。
これがChaos Clothのようです。
成程、これはMaterialそのものをClothにする話ではなく、どれくらい布が風などでそよぐかを指定する機能でした。
これはこれで面白いので一寸だけ見る事にします。
全部、本物そっくりのそよぎ方をしています。
特に黒い布は高級なブランド品に使用する布のような揺らぎをしていました。
この布に使用されているMaterialの実装を調べたら
普通にDefault Litを使用していました。
あれ？
Cloth Collisionについてです。
凄いですね。
全然破綻しないんですね。
別な方法でCollisionを達成しているそうです。
Self-Collisionです。
左がOffで右がOnの状態です。
Self-CollisionをOnにすると確かに破綻がないです。
でも絶対、無い訳ではないです。
他のSoftも同時に動かしておいてUEに戻ると、途中の映像を飛ばして今、いるべき位置にTeleportします。
その結果以下に示した様な
破綻が生じる時がありました。
現時点ではGameに使用するのは難しそうです。
最後の例です。
ほとんど動いてくれないので、よく分からないです。
Strataに関しては以下のMaterial Functionしか引っかからなかったです。
以上です。
4. Niagaraの勉強
今週は Disintegration into Sand Unreal Engine 5.2 Niagara Tutorial [1]を実装します。
4.1 Disintegration into Sand Unreal Engine 5.2 Niagara Tutorial [1]を実装する
今回はUE5.2で作成してみます。
Materialの作成をします。
先週のBlogにやり方をまとめてあるのでその通りに作成します。
NoiseはEngineにあった以下のTextureを使用しました。
結果です。
まあ。中らずと雖も遠からず。でしょう。
今度はNiagara Systemを作成します。
UE5.2のNiagara SystemのIconは凄い綺麗です。
しかもParticle Systemってのはこういうもんだと言うところを、一発で表していて上辺だけの綺麗さじゃないところが凄い良いです。
このDesignを考えた人を知りたいですね。
後、このDesignを考えた人がEpic Games社内で、本当に評価されているのかも知りたいです。
NSを開いてEmitter内にある要らないModuleを全部消しました。
Particle Spawn SectionにStatic Mesh Location Moduleを追加します。
PreviewとDefaultに椅子をセットします。
Errorが表示されたのでFixを押しました。
直りました。
直ったのは良いんですが、何でErrorになったのかの原因が分かりません。
結果です。
Spawn Particle SectionにあるInitialize Particle Moduleの設定を微調整しました。
結果です。
GPUに変更します。
Propertiesの設定を以下の様に変更しました。
Emitter Update SectionにあるSpawn Rate ModuleのRateを20,000に変更しました。
はい。出来ました。
今度はMaterialに戻ってTextureを以下のものに変更します。
結果です。
ここでまたNSに戻ります。
Particle Spawn SectionにScratch Moduleを追加します。
実装です。
これでTextureの色がParticleに反映されるはずです。
Scratch PadのModuleにTextureをセットします。
結果です。
うーん。
出来てない気がします。
Tilingを追加して確認します。
しました。
警告が出て来ましたが、これはTutorialも出ていたので無視します。
Tilingの値を0.01にします。
結果です。
おお、出来ていました。
今度はこの透明な部分をRender SectionにあるSprite Renderer Module内で使用しているMaterialを変更する事で直します。
Tutorialでは
と言っていましたが、
Translucentを使用する以外の情報がないので、このMaterialは自作する必要があります。
正直、ここが今回のTutorialの一番の難関で、これがClear出来れば後は簡単です。
とりあえず、今使用されているSpriteのMaterialをDuplicateしてBlend Modeの設定をTranslucentに変えてみました。
このSpriteの実装ですが、
元々、OpacityにParticle ColorのAlphaが繋がっていました。
これで黒が表示されるはずです。
テストしてみます。
新しく作成したMaterialをSprite Renderer ModuleのMaterialにセットしました。
結果です。
これは完璧でしょう。
MaterialのTexture SampleノードのUVs値も同じに揃えました。
結果です。
同じになりました。
そしてMaterialの実装を以下の様に変更しました。
これを使用するEmitterを作成します。
しました。
Mesh Renderer ModuleのOverride Materialにセットしました。
結果です。
白い部分が消えていません。
MaterialのBlend ModeをMaskedに直します。
そしてStepの結果をOpacity Maskに接続します。
またNSに戻ります。
椅子が消えています。
０の時に
で
1の時に
完全に消えます。
Tutorialと逆な気がします。
確認します。
あってるみたいです。
Particle Update SectionのDynamic Parameter ModuleのDissolveの値を以下の設定に変更します。
結果です。
今度はSand Emitterの調整をします。
まずScratch Pad ModuleのTextureをNoiseに変更します。
Scratch Pad内の実装は先週のBlogでは記録しなかったので、ここにしっかり記録として残すようにします。
Sample Texture 2DノードをBreakしてSubtractします。
[INPUT]Floatを追加してSubtractする値が入力出来るようにします。名前はDissolveに変更しました。
その結果を[PARTICLE]Colorに追加します。
これでNSのScratch Pad ModuleのDissolveの値をいじる事で
椅子が出たり
消えたりします。
これは[PARTICLE]Color のAlphaの値も変更されるからです。
なのでScratch Padに戻り以下のような実装に変更します。
今度はDissolveの値を変化させてもSpriteは消えないで色が白から黒に変化するだけになりました。
白と黒の境界があいまいなのでStepノードを足して境界をはっきりさせます。
結果です。
分かり易いです。
今度は白と黒の境界だけが白くなるような実装に変更します。
以下の実装を追加しました。
AddノードのBの値は[INPUT]Edge_Thicknessから来ています。
この部分の実装の理屈は、先週のBlogの以下の部分で解説しているので
ここでは省略します。
結果です。
ここで黒いParticleをKillします。
まずそれぞれのParticleの色の値を保持するParameterをMap Setノードに作成します。
[PARTICLE] KillBlackと名付けました。
そしてParticle Spawn SectionにKill Particles Moduleを追加して
以下の設定を組みます。
結果です。
白い部分だけParticleが生成されるようになりました。
今度は生成されるParticleが移動するようにします。
Scratch ModuleのDissolveにChair EmitterのDynamic Parameter ModuleのDissolveの値をCopyします。
結果です。
色々微調整をした結果ですが、かなり良い感じになりました。
Map Setにある[PARTILCE]Colorを外して
Spawn Particle SectionにあるInitialize Particle Moduleの
色を変える事で
Spriteの色を金色にしました。
更にCurl Noiseを追加します。
Curl Noiseの設定はよく分からないのでTutorial通りにします。
結果です。
だいぶ砂らしくなってきました。
今度は毎回同じ方法で分解するのでそれを直します。
椅子に使用しているMaterialを開き、Constantノードを外しそこにDynamic ParameterのTilingを繋ぎます。
今度はNSに戻ってSystem SpawnにSet New Parameterを追加します。
設定は以下の様にします。
そしてChair EmitterのDynamic Parameterの
Tilingにこの[SYSTEM]Random Tilingをセットします。
Sand EmitterのParticle Spawn SectionにあるScratch Moduleの
Tiling にもこの[SYSTEM]Random Tilingをセットします。
これで毎回、椅子の消え方が変わるはずです。
テストします。
変わっていました。
今度はGravityを追加します。
結果です。
完成しました。
５．戦闘システムの続きを作成する
今週からUIの改善に着手します。
先週のBlogで以下のようにまとめましたが、
今週はMain Menuの追加をやります。
5.1 Main Menuの作成の復習
去年、半年ほどUI、特にMain Menuについて勉強しました。
しかしこれは勉強の手法を間違えてやってしまったので、戦闘システムの完成を大きく妨げ、かつProject自体を迷走させてしまった大きな要因になってしまいました。
今回はその失敗を繰り返さないために、どこで迷走が始まってしまったのかをしっかり把握します。
これは去年の終わりか、今年の初めの総括で既にやっているのでそれを復習します。
その上で、せっかく半年近くも勉強したのだから、使えるものは使いたいです。
ので何を勉強したのかももう一回復習します。
今週はこれをやります。
＜迷走の始まりとその理由の確認＞
これは2022-12-25のBlogにしっかりとまとめられていました。
2022-05-09のBlogから迷走が始まったと書いてありました。
恐ろしい。
丁度、去年の今の時期です。
今年も同じ轍を踏みそうで怖いです。
更に以下の様にまとめられてもいました。
うんこをDiamondと勘違いしていた。
これ重要な検証結果です。
段々思い出してきました。
以下に思い出した内容をまとめます。
- 正しいUIの作り方と言うようなKnow How的なものは無かった。
- User目線から、このUIは駄目だ。みたいな意見を言う人は全く信用出来ない。
- UIは最後に作るもの。Save機能のようなそのGameに元々ない機能をUIには絶対必要だから、追加するみたいなのはやっては駄目。
以下に少しだけ説明を付け加えます。
＜正しいUIの作り方と言うようなKnow How的なものは無かった＞
これ一番衝撃的なんですけど、科学的に検証されたUIの作り方というものがないんです。
Design学的に絶対に必要だと思うんですが、そういうのは無かった。
UI、UE Designerはそういうのが有る風に装っていますが、100％経験に頼っているだけだったんです。
Power Pointのまとめ方的なHow toでももっと統一された原則みたいなのがあります。
まだData Scienceなどで言われるVisualization（可視化）のような他人に説明しやすいようにDataを整理するための技術体系なんていうのも全く無かったです。
＜User目線から、このUIは駄目だ。みたいな意見を言う人は全く信用出来ない＞
User目線というのは大切です。
でもそれはあくまでも同じUser同士にとって大切なんです。
一般の商品に例えて考えると分かり易いですが、この商品を買おうと思った時に前にその商品を買った人のCommentはとても参考になるじゃないですか。
Gameに関して言うとそういうUserの意見で最も多い部分がUIに関しての苦情です。
これはUIがUserとGameを繋ぐ窓口である事を考えれば当たり前なんですが、それ以外にも誰でも間違いを指摘出来るという部分もあるからです。
Landscapeの作成の間違いを指摘するのには、TilingとかMacro VarianceとかNaniteとかWorld PartitionとかDirect Lightとか色々な知識が必要になります。
そういう事を全部、勉強して初めてLandscapeについて批判出来るようになるんです。
UIについて批評するのはそういう知識、全く要らないんです。
で、そういう人のUI批判を聞いて、あ、この人はUIの専門家なんだ。と誤解してしまったんです。
まさしくうんこをDiamondだと思ってしまったわけです。
それでそういう人達の意見に振り回されてしまったんです。
UserならこのUIは使いにくい。という感想で十分なんです。でもUIの専門家なら、その問題をどうやって解決するのかを知ってないといけないんです。
ところが、User目線から、このUIは駄目だ。みたいな意見を言う人は、全く解決策を持ってないんです。解決策らしき事を提案する事は出来たとしても、100％机上の空論です。
ので直す事が出来ないんです。
だったら最初から聞かない方が良いんです。
＜UIは最後に作るもの。Save機能のようなそのGameに元々ない機能を、UIには絶対必要だから追加する。みたいなのはやっては駄目＞
去年は「Main Menuには最低限、Option とSaveボタンは必要。」と言う意見を聞いて、素直にああそうなのか。と思って後から付け足そうとしました。
もうGame自体が完成してしまっているので、UI側からGameの変更をすると、Game自体を最初から作り直さないといけない事態になります。
去年はこれを無理やり敢行しようとして、全く違うGameを作成するところまでなりかけました。
結論から言うと、そういうのを後から付け足す事は出来ないんです。
そういう事をやろうとすると、Game自体を最初から作り直すのと同じになります。
それだけのCostを負担する余裕があるのか、という事と、もっと大切な事はGameのConceptから外れてしまうのは良いのか、という事の２つの問題が発生します。
もうGameのConceptは最初の段階で決まっていて、それを実装したんだから後は確認するだけなんです。
そのGameが面白いかどうかを。
だから「UIが使いにくいから次回作ではこういうUIを作成したらどうでしょうか？」
という意見なら良いんですが、今のGameを変える事はかなり頓珍漢な行為をやっている事になります。
ので絶対にやってはいけません。
5.2 Main MenuのDesignを決定する
前節で、去年やった間違いの原因と今年は同じ間違いを犯さない対策方法もかなり分かってきました。
まずMain MenuのDesignを最初に決めてしまいます。
そこは絶対に必要なものしかありません。
それが出来たら完成です。
そのDesignをまずここで決めてしまいます。
このGameのMain Menuに絶対必要なものは一つだけです。
Start Buttonだけです。
Start Buttonを押したらGameが始まるようにします。
来週はこれをまずします。
そしてTitleとか後ろの画面のとか、他のButtonとか、BGMとかはその後で考えます。
5.3 去年のUIの勉強についての復習
それでは復習をやっていきます。
2022-12-25のBlogにそれぞれの週で何をやったのかの詳細がまとめられています。
それを参考にしながら復習します。
色々なGameのStart Screenを集めたSiteを見て以下の感想を述べています。
この感想自体は参考になります。
以下の様に述べていました。
この時点で当初の目的を忘れて壮大なRPGを作成する気になっています。
更にUI画面には以下のものが必要だと述べています。
- Credit画面
- Dialogue画面
- Game Over 画面
- Inventory画面
- Level選択画面
- Load画面
- Lobby画面
- Map画面
- Menu画面
- Progress画面
普通のRPGならどれも必要ですが、今回のGameはどれも必要じゃないです。
唯一の例外がCredit画面で使用した音源を記載する必要があります。
ここでも普通のRPGなら必要かもしれないUIについて勉強していました。
今回のGameには必要ない事なのでまるまるCutします。
ここから迷走が始まります。
これが間違っていました。
何年も前から言われていますが、英語が喋れるようになるためには、英語が喋れる人から学習方法を聞く必要があるんです。
ところが英語が喋れない人でも平気で専門家ぶって有料で学習方法をAdviceしたりしています。
こういう人の話を真に受けると永遠に英語が喋れなくなります。
それと同じ事をしてしまいました。
Gameを作れない人からUIのAdviceを聞いてしまったんです。これではUIは永遠に完成しません。
Gameを沢山Playする人ってどんな定義ですか？
- 沢山のGameをやる人ですか？
- 一個のGameを長くPlayする人ですか？
もうこの時点で、正しいUIを考えるのにGameをPlayする必然性がない事が分かります。
更に言うとYouTubeのGame系Influencer達は、全くGameをPlayしないで批判しているんですよ。
これ、英語圏では徐々に常識になって来ていますが、彼らが参考としてYouTubeに表示する画面ですら、他のYouTuberがPlayした画面なんです。
それでも彼らの言う事は世論として時には政治を動かす程の影響力を持ちます。
だから正しいUIを作成する事とGameを沢山Playする必要がある事にはなんの因果関係もありません。
これはまあ正しい結論です。
ここでUIの勉強からGameには報酬というものが必要らしい。との情報を得ました。
それ自体は知見ですが、この戦闘システムはそういう目的で作成した訳ではないのに、このGameに報酬システムを追加するにはどうしたらいいのかを検証し始めています。
ここの感想は2022-12-25のBlogにまとめられている通りです。
この後のBlogのまとめも2022-12-25のBlogに簡潔にまとめられていました。
ここからはいちいちBlogの復習をする必要はないと判断しました。2022-12-25のBlogのまとめで十分です。
＜UIの勉強の復習のまとめ＞
何か役立つ情報を拾えないかと確認しましたが、今回のMini-Gameの作成に関して言えば無い事が確認出来ました。
それだけ判明したら十分です。
無駄にしてしまった時間と労力は勿体ないですが仕方ありません。
そこから何かを無理やり得ようとするより、これから同じ過ちをしないようにする方が遥かに益があると思います。
ので失敗したところは無視して先に進みます。
６．Gaeaの勉強
6.1 先週の復習
流石に先週の勉強の内容は覚えていますが、非常に重要な内容なのでここで復習がてらまとめ直します。
GaeaではMaskを作成するためにData GroupのNodeを使用します。
そのData GroupのNodeには2種類のNodeがあり、一つ目の種類のNodeは以下の図で示した実装の
Textureノードの部分に使用します。
このTypeのNodeはUEで言うところのMacro Varianceの作成に使用されるNodeで直接Maskを作成するためのものではありません。
もう一つのTypeのNodeはSlopeノードの部分に使用するNodeです。
この部分に使用するNodeの目的は、まさしくMaskをするためで、UEにMaskとしてExportするのもこの部分に使用するNodeです。
最後に、この実装ですが、UEのLandscapeのLayer Info Weight-Blended Layer (normal)を選択した場合におけるMaskの挙動と全く同じ結果になります。
この実装方法を知らなかったら、GaeaにおけるColoringはUEの結果と同じにならないからする必要がないと結論付けて勉強しないで終わっていました。
先週はData Groupの中で、このType1に当たるNodeの機能の復習をしました。
実際に調査したNodeを以下に示します。
- Textureノード
- Curvatureノード
- Distributionノード
- Ditherノード
- ProTrusionノード
- RockMapノード
- SurfTexノード
- Velocityノード
今週は残りのType2のNodeの機能を勉強します。
6.2 Data GroupのType 2のNodeの検証
＜Angleノード＞
2023-03-20のBlogで勉強していますね。
あるAngleとDirectional Lightの光の角度ので白黒が決まります。
ParameterであるAzimuthに関しては
2023-03-20のBlogで詳しく解説しています。
＜Flowノード＞
GeometryにおけるFlowを示しています。
このFlowの部分は水が流れるから緑が多いと考えるのか、逆に水が流れるから緑は少ないと考えるのか？
どっちが正確なんでしょうか？
緑を白にあててみました。
逆にしました。
うーん。
どっちも正しそうです。
＜Growthノード＞
植物が生える部分をMaskします。
この説明を見るとSlopeとFlowsから植物が生える箇所をMaskしています。
Flowの調整をするParameterはないですね。
以下にDefaultの結果を示します。
これしかMaskしていません。
ある特定の植物を生やすためのMaskと考えると丁度いいかもしれませんね。
＜Heightノード＞
これはある特定の高度だけをMask出来るNodeです。
こんな感じにある特定の高度にだけ植物を生やしたりとか出来ます。
＜Occlusionノード＞
このNodeはScaleがDefaultの場合は以下に示した様に白過ぎてあんまりMaskとして有効に思えませんが、
ScaleをLogarithmicに変更すると
以下のような黒い部分がかなり多いMaskとなります。
Coloringも追加してみました。
＜Soilノード＞
ここから2023-03-27のBlogを参考にします。
Flowノードとならんで定番のSoilノードですが、
そのまま使用すると弱いですね。
緑がほとんど見えなくなってしまいました。
＜Slopeノード＞
これはもうあまりに一般的になってしまったので敢えてここで機能を勉強する必要はないとは思いますが、一応書いておきます。
Heightノードの角度Versionで、特定の角度だけMaskします。
UEのWorld Aligned Blendノードと同じ機能です。
＜Sun Lightノード＞
Sun Lightノードは雪のMaskに使用するためのものだそうです。
2023-03-27のBlogでも書いていますが、
どう使用したらいいのか不明です。
雪の解け具合を表すのに使用するみたいです。
色々、試して見たんですがやっぱり使用方法が分かりません。
以上でした。
今週のGaeaの勉強は短いですが、予定の範囲が終わったのでここまでとします。
７．Houdiniの勉強
7.1 Creating realistic landscapes in Unreal Engine with Houdini | GDC 2023 [7]を勉強する
先週、一回軽く全部見たんですが、かなり濃い内容でこれはしっかりまとめるべきだと感じました。
のでここでしっかり勉強する事にします。
＜Introduction＞
いきなりこれですか。
これってPokémonのPorygon事件を思い出しますが、正直本当にこんな事件って起きるんでしょうか？
後で一寸調べてみます。
Embark Studioの人がPresentします。
調べたんですが何している会社かよく分からなかったです。
この会社では、UE5用のLandscapeをHoudiniを使用して作成しているそうです。
そのやり方をここで公開するそうです。
おお。
以下のPartに分けて解説するそうです。
LiDARの所で、Geospatial Scientistって書いています。
BingでGeospatialについて聞いたら以下の回答が返って来ました。
うーん。
Raster Dataについての解説は？
まあいいです。
要するに地図に関するDataを指しているのね。
＜Background＞
誰でもPhot-RealisticなLandscapeが作成出来るToolを作成する。が目的の会社だそうです。
このPartはこの会社について解説しているのでSkipします。
と思ったらこの会社で、今までどうやってLandscapeを作成していたのかの解説が始まりました。
ここは大切なのでやっぱりまとめます。
以下のような変遷があったそうです。
Landscape DCC ToolはGaeaなんかを指していると思われます。
この会社でも最初はLandscapeを作成するのにGaeaなどのSoftを使用していたみたいです。
2D vs 3Dの意味はよく分かりません。
最後のLiDARがHoudiniを使用したLandscapeなんでしょうね。
＜＜Landscape DCC Tool＞＞
最初に使用していたDCC Toolだそうです。
Gaeaもしっかり入っていますね。
以下の欠点があるのでこれらのSoftの使用を止めたそうです。
二番目の新しいSoftの使用方法を学ぶ必要がある。と三番目の学んでも使用出来る箇所が非常に狭い範囲だけ。は納得です。
特にこれらのTerrainを作成するSoftはきちんとしたTutorialがないので正しい使用方法を学ぶのは大変です。
これらの要点に関しての更に詳しい説明です。
うーん。
確かにGaeaで作成するLandscapeはRealではあるんですが、なんか本物とは違う気がしない事もないです。
でもErosionの発生なんか科学的に計算して作成している訳で、Artistが勝手に「これ本物っぽくない。」と言うのも違う気がします。
どこが本物と違うのかを比較して証明してほしいですね。
次の点についてです。
Artistが覚えなくてはならないSoftの数を減らしたい。そうです。
それは、そうです。
でもこれってGaeaなどのLandscape DCC Toolが学習Costが異常にかかる事も関係していますよね。
私はこの壁は超えてしまったのでGaeaのTutorialも作成します。
三番目の要点についてです。
以下に示した様にLandscape DCC Toolは使い方を覚えても
Landscapeしか作成出来ません。
それに比べてBlenderやHoudiniは色んな事が出来ます。
一回、使用方法を覚えたら、いろんな事に使用出来ます。
だからこっちのSoftを覚える方がコスパが良い訳です。
HoudiniのLandscapeはよく知らないですが、BlenderのLandscapeのErosionの質はかなり落ちます。
2023-04-17のBlogにまとめていますが、
火星の表面みたいです。
LookDev Groupに当たるNode群もないですし、その辺はやっぱり一概には言えないですね。
ここで何と、何で色々な事が出来るSoftの方がましなのかを例を用いて解説し始めました。
聞いてみましょう。
ここで２つの例をHoudiniを使用して解説しています。がよく分かりません。
どこでHoudiniのLandscape以外の機能を使用したんでしょうか？
最初の例では以下のSatellite Imageをうんたらかんたらしています。
が、そのうんたらかんたらしている箇所の説明がよく分かりません。
でもこの例は衛星写真からLandscapeを作成するというまあGaeaからでは出来ない事をしているので何かHoudiniのLandscape以外の機能を使用しているんでしょう。
二番目の例です。
Houdiniで作成したLandscapeを以下の様に一枚のTexture？（Normal Mapの事？）に変換して
この後のUEでの使用方法の説明が全く理解出来ません。
うーん。
まあ、分からんものは仕方ない。
一応、こういう事を実行出来るのでHoudini内でLandscapeを作成した方が得である。という事で先に進みます。
最後の要点についてです。
Lack of Scriptabilityだそうです。
ようするにCodeを掛けるのかどうかです。
これは確かにその通りで、UEと同じLayerをGaeaで作成しようとすると以下の実装を組む必要がありますが、
この実装の組み方、自分自身で思い付く事は出来ませんでした。
これGaeaにIf節にあたるNodeがあったら、すぐに同じ結果を作成する事ができます。
けどIf節はないので1か月位悩んで、諦めました。
ここではPluginの作成が無理なので、Artiestが担当すべきでない事を強いられる結果になった。と書いています。
Artiestが担当すべき事はUserがPlayした時に気に掛ける部分の作成に集中すべきで、それ以外の問題の対応に関わらせるべきではない。というのは全くその通りだと思いました。
＜＜2D vs 3D＞＞
最初何が言いたいのか分からなかったんですが、分かりました。
Landscape DCC Toolで作成した結果は2DのHeight MapとしてExportします。
この結果を修正するためには2D上であるHeight MapのImageを3Dの結果を予測しながらPhotoshopなどのSoftで編集する必要があります。
この方法だと直感に頼った編集をするのはかなり難しくなります。
ところがHoudiniだったら以下に示した様に
3Dのまま調整する事が出来ます。
うーん。
でもこれってUEのLandscapeを使用すれば、普通に出来ますよね。
＜＜LiDAR＞＞
ここを理解するにはLiDARが何なのかについて知っておく必要があります。
まずそれを調べましょう。
National Ocean ServiceのWhat is lidar?[8]に以下の解説がありました。
こんなImageを衛星から撮影出来るそうです。
うーん。
別に写真と同じじゃん。
と思ったら
3Dで撮影していました。
すげえ！
このDataをそのままUEにLandscapeとして使用出来るの？
じゃ日本の地形とかそのままUEにImport出来るって事。
ほお。
凄い。
LiDARのDataから3Dを作成した例だそうです。
本物そっくりではなく本物のDataから作成したLandscapeになります。
ここからどうやってLiDARが地表のDataを集めたり、そのDataからどうやって3DのLandscapeを作成するのかについての具体的な説明がありました。
それ自体は有益で面白いんですが、この動画を理解するのには必要のない内容なので、この辺のまとめはSkipします。
で、この複雑な手順を自動化して、誰でもHoudini内で簡単にLandscapeを作成出来るようにしたそうです。
Houdini内で３D化したLiDARのDataです。
もう少し複雑な地形でやってほしかったです。
これだとGaeaで作成したTerrainとの差が見れません。
更にこのLandscapeに対して
ArtistはDataの質を落とす事なく自由に調整する事が出来るようなります。
このPointの位置を移動させる機能は、元々Houdiniにある機能を使用していますね。
更に以下のような色をDataから生成する事も可能だそうです。
これはLiDARのDataから生成するのでしょうか？
それとも一緒に撮影した写真とかから自動で生成するのでしょうか？
単に似たImageを生成するだけならGaeaのColoringでも出来ます。
その辺の違いというか、GaeaのColorの生成に対しての優位性についての説明が、ほしかったです。
まあ、LiDARのDataから3Dを作成するのはここでしか出来ないのでその時点で比較しても仕方ないですが。
Maskの例だそうです。
この辺はHoudini本体の機能がどうなっているのかがよく分からないのですが、多分色んなMaskが元々あると思います。
UEへのExportのやり方だそうです。
これ見るとMuti-LayerでHeight MapやMaskをExportする仕組みのようです。
Gaeaの有料版と同じ方法ですね。
ただし将来的には、UEにBridgeのように直接Export出来るようにするそうです。
＜LiDAR＞
節の分けが、訳分からなくなりそうですが、前のLiDARはBackgroundの中のLiDARで、ここからは
のLiDARです。
まず自動化の進捗状況について解説しています。
この辺は別に知る必要もないですし、この会社がこのPluginを完成させたら、使用させてもらうだけです。
ので簡単にまとめます。
以下の手順でHoudiniにImportするそうです。
結果です。
でこの場合、56,000,000のPointが使用されているそうです。
そこで低解像度でArtiestがRealtimeに編集できる機能が大切になります。
普通にグリグリ動かしています。
LiDARのDataをLoadしてから全く遅延がないです。
＜Houdini Height Tool＞
Height Toolって何を具体的に指しているのか不明です。
おそらくLiDARから生成したLandscapeに対してErosionを追加したりMaskを追加したりする事を指していると思われます。
＜＜Gaea＞＞
え、なんでいきなりGaeaの話が出て来るの？
あ、これはGaeaのFlowノードじゃないでしょうか？
Maskを作成するのにGaeaのNodeをそのままHoudini内で使用するって事でしょうか？
凄い。
説明聞いたら、元々HoudiniにはGaea Bridgeと言う機能があるそうです。
それを使用したらGaeaの機能をHoudini内から使用出来るそうです。
へー。
そうなの！
良い事聞きました。
これはGaeaの勉強はHoudiniを使用してLandscapeを作成する事になっても無駄にならないって事じゃないですか。
うーん。
偶然とは言えLandscapeの作成にWorld MachineからGaeaに変更して良かった。
小っちゃくて分かりませんが以下の箇所でGaeaを使用しているみたいです。
結果です。
これが
こうなりました。
Gaeaのどんな機能を使用してるのか不明ですが、Houdini内でGaeaのNodeをそのまま使用出来るんでしょうか？
とても興味のある話題です。
＜＜Height Field Color＞＞
Landscapeにどうやって色を付けたのかの解説です。
これは何をやっているのか全く理解出来ません。
今のHoudiniの知識ではこれを理解するのは無理です。
ただ、それぞれのLayerはGaeaと同じか似ていますね。
Slope LayerとかFlow Layerとかあります。
以下の図に示したColorは
説明を聞いた限りで解釈するとUEにおけるMacro Varianceですね。
＜Align and Lattice＞
AlignとLatticeは、Landscapeの形状を3Dで編集するためのToolだそうです。
凄い速さでLandscapeの形状を直していますが、具体的な使用方法までは理解出来ません。
ただ見て凄いな。と思っただけです。
＜Houdini Engine＞
ほとんど使用しないそうです。
＜Hight Field Cliffs＞
これがHoudini Engineの代わりに使用するのか、Houdini Engineの中にある機能なのかよく分からないです。
UE5内で何かやっていますが、何が目的なのかよくわかりません。
ただ凄いグリグリ動きます。
物凄いSmoothに動いています。
＜Landscape LOD＞
HDAと繰り返し言っているんですがこれの意味が分かりません。
この辺でまとめるのもお終いにします。
でもHoudiniでUE5様にLandscapeを作成する方法そのものについての情報とGaeaと比較した場合の利点、そしてLiDARについてなどについて新しい知見を得られたので十分です。
今週のHoudiniの勉強はここまでとします。
８．UEFNの勉強
8.1 The Verse Programming Language | GDC 2023 [9]の続きを見る
＜UEFNとUEの違い＞
ここで以下にまとめられているのはUEFNとUEの相違点です。
Simple to Approachと言うのは、UEFNでは最初からFortniteというGameが完成されていて、その中でVerseを使用すればいいだけなので、UEと比較するとGameを完成するまでにかかる手順が圧倒的に少なくて済みます。
Constantly Evolvingは、誰かがGame内で何かを発表したら、すぐにそれを使用する事が出来ると言う意味だそうです。
ちなみに今のFortniteは2週間に一回はUpdateしているそうです。
これがいつでも誰でもUpdate出来るようになる。と言っている訳です。
その下の３つについては説明しないで次のSlideに移ってしまいました。
まあ、またこのSlideに戻ってるくのかもしれませんが。
＜Verse API＞
Verse APIについてです。
Verse APIは以下に示した３つに分割されるそうです。
UnrealEngine.comはUnreal Engineの事、Fornite.comはFortniteの事だそうです。
そう言われてももう少し具体的に説明してほしい。と思ったら以下のSlideを表示しました。
うーん。
何となくですがImage掴めました。
今年の予定だそうです。
こういう機能に関しては実際にUEFNでGameを作成してみないとどの機能が必要なのか分かりませんね。
Scene Graphでは以下の２つを考えているそうです。
この辺になると何を言っているのかもう分からなくなりました。
UEFNで私がGameを作成したとします。それを公開する時にここで説明されている内容が必要になって来るんでしょうか？
それともUEFNでGameを作成する時にこれらの内容が必要になるんでしょうか？
お、次のSlideで具体的な例を用いて解説してくれるみたいです。
＜Verseの使用例＞
UEFNでDeviceを作成した場合だそうです。
VerseのCodeが書かれていますね。
Classを使用していますし、Inheritanceも使用しています。
これは単にBPで新しいClassをActorから作成したのと機能的には同じです。
次に以下のCodeを追加しました。
Script内には編集可能なPropertyを追加する事が出来るそうです。
このCodeがその一例だそうです。
Slideの右側に表示されているDetailsのEscape Sequence Deviceの
Player Spawn Aが追加されている事が確認出来ます。
これはUE４のC++に同じような機能がありました。
次のSlideです。
ここで重要なのは以下のCodeで
これがOnBeginの中で実装されているという事です。
つまりBPで言えば
Event BeginPlayノードがOn Beginでその次に繋がっているNodeがSpawn｛StartEscapeSequence（）｝になるわけです。
次のSlideです。
RaceとかDeferとか使用しています。
この辺はまだ勉強していないので大体の感覚で理解していきます。
動画で分かり易く解説していました。
まず以下の関数が呼ばれます。
この関数ではRace Methodが使用されているので
EscapeMethod()関数とPlayerSpawn.SpawnedEvent.Await()関数の両方が実行されます。
このPlayerSpawn.SpawnedEvent.Await()関数はPlayerをRespawnするための関数だそうです。
EscapeMethod()関数が実行されたので以下のDoEscapeSequenceA()関数も実行されます。
それでMessageが表示されます。
その後でPlayerがRespawnします。
そして表示されたMessageを隠します。
うんうん。
分かって来ました。
でも先週のBlogでまとめましたがRaceって
一個の関数の実行が終了したら他の実行中の関数は中止するんじゃなかったんでしょうか？
この辺の関連はまだよく分からないです。
こういうのはパズルを解くのに似ていて最初から全部のパーツを埋めるのは不可能で、分かる所だけ埋めて、そのうちに全部のパーツが埋まって理解出来るようになるので、今はこれくらいの理解で充分です。
続きを見ます。
今度はDeferについて解説していました。
Deferを使用すると前に書いたCodeを後から実行する事が出来ると、至極当たり前の事を解説していました。
この後、Verseを使用したGameの例が紹介されています。
流石にこれを今理解するのは無理です。
Verseを使用するとこんな事が出来るようになる位の感想でここは見る事にします。
＜Q and A＞
ここからQ and Aが始まります。
うーん。どうしようかな。
先週、見た時はこのQ and Aもかなり勉強になったんですが、今はもうVerseがどんな言語なのかとか、どういう風に実装するのかとかのImageが大体出来ています。
あえてQ and Aを全部まとめる必要もない気がします。
これは全部Skipしましょう。
8.2 The Verse Programming Language | GDC 2023 [9]を見た感想
まずVerseがどんな言語なのか、どのように使用するのかについての大体のImageを掴む事が出来ました。
Verseは3DにおけるJavaScriptの立ち位置を狙っていて、JavaScriptと同じように色々な言語のParadigmで実行する事が可能です。
つまりVerseはFunctional Logic言語ですが、Classも作成する事が出来ますし、ここで紹介された例ではUE5とほとんど同じ方法、つまりObject Orient言語で書いていました。
今週の内容は具体的なVerseの使用方法とその例の紹介だったので、この動画の肝は先週の内容になります。
ので一部、繰り返しになりますがここでMetaverseに関しての動画を見た感想をまとめます。
まずVerseというかMetaverseの将来性に関してですが、今の一般的な意見と違い、かなりの可能性を感じました。
タンパク質の構造のような3Dで表す以外に正しく記述出来ない分野だけでなく、車の設計のような2Dでも出来るけど3Dだと更に見やすい分野は無限に存在します。
これらをMetaverseの空間で共有できると言うのは、唯一無二の存在としてこれから強力に発展していく可能性を感じました。
先週も書きましたが、新築の家をMetaverse内に先に立てて生活する事で、実際に家を建てた時に直面する問題を先に認識する事も可能になるかもしれません。
ビルの安全性を検討する時に、Metaverse内に同じビルを建てて火災を起こして本当にビルの中の人達が無事に逃げ出せるのかどうかを疑似Gameとして試すのは、安全性の検討としても重要ですし、新しいGameの可能性としても面白いと思います。
もう一つの可能性がRemote WorkにMetaverseを使用する事です。
通勤中のテロが頻繁に起きるようになったら、劇的にRemote WorkにShiftするでしょう。そうなった時にMetaverseを使用した方が便利になる気がしています。
8.3 VerseやUEFNをどうやって学ぶのか？
MetaverseやUEFNの時代が来るのは理解しましたが、どうやって勉強するのが得策なんでしょうか？
と言うか、UEFNを勉強すると言ってもう一か月経ちます。
まだFortniteのGameすらやったことが無いです。
今まで勉強した内容は全部忘れています。
取りあえず復習をします。今まで勉強した内容を以下にまとめます。
ここで初めてUEFNを知るんですが、この時点で結構詳しく調べています。
まず JSFILMZ氏のFortnite Creative 2.0 Beginner Tutorial [10]でFortniteとUEFNをInstallしました。
次に公式のこのサイト[11]で以下の事を勉強しました。
まずFortnite Creativeは以下の３つで構成されています。
これは順番に理解しないとよく分からなくなりそうです。
ので以下の順でやる必要があります。
これ。最初のFortniteで遊ぶと言うのが面倒なんです。
正直、Gameで遊んでる暇と体力はないって感じです。
次のFortnite Creative Toolsetで島やGameを作成するのも、何個か動画を見ましたが、Gameの延長戦状と言うか操作方法がFortniteと全く同じで、UEとは全く違います。
これを覚えるのは出来たら遊んでいる時間や休憩している時間で済ませたいです。
がそういう時間はYouTubeとか見て過ごしてしまっています。
ここで詰まっているのか。
ここでは完成した島をFortniteに公開する方法があってそれをするとお金が稼げるらしい。と言って終わっています。
ここでUnreal Sensei氏が別アカでUEFNのTutorialを作成しているのを知りました。
これを勉強する事にします。
途中まで勉強して終わっています。
後、Fortniteは小学生が沢山Playしています。
大人が子供に混じってPlayして児童虐待とか疑われないように気を付ける必要がある。と書いています。
これは、まあ子供がいる所に近づかなければ良いだけです。
あとUEFNは日本語でやる事にします。
これでへんなアメリカ人に絡まれる事も無くなるでしょうから。
Functional Programming（関数型プログラミング）について勉強した内容をまとめています。
あれ、これって結構最近ですね。
先週のBlogです。
The Verse Programming Language | GDC 2023 [9]を勉強しています。
以上でした。
＜まとめと感想＞
うーん。成程！
これじゃ。まだ何も勉強してないのも納得です。
まずはUnreal Sensei氏もといFortnite Sensei氏のTutorialを最後までやります。
それから次を考える事にしましょう。
９．YouTube動画の作成
今週は、とにかくマイクに何かしゃべらないと、と思って先週書いた共和党が崩壊する可能性について録音してみました。
これについてまとめます。
後、任天堂が英語圏のInfluencerからフルボッコにされている件でとんでもないNewsが飛び込んできたのでそれについてもまとめる事にします。
9.1 共和党が崩壊するかもしれない件についてマイクに喋ってみた
もうマイクを買ってから全然使用していないのでとにかく喋ってみました。
ただある程度の内容がないと喋る事も出来ないので以下のあらすじをまとめました。
- 中絶問題
- Googleは中絶が出来る病院のそばに妊婦が移動した時は履歴が分からないようにした
- Metaは警察に中絶しにいった可能性があると警察に報告した。
- Z世代から蛇蝎のごとく嫌われている
- BoomerはComputerを使えない
- 大学の学費は100倍になったのに給料は1倍しか上がっていない。
- Boomerの年金運用のために一生働かされるZ世代
- Z世代の数が多い
- 銃の規制
- 嘘ばかりついて来たそのつけを払う段階になった
- 日本を含めアジア人を積極的に追い出したツケが回って来た
- 結局、作れない電気自動車。
- High Tech会社から追い出されたアジア人達。
- アジア人を追い出したら何も作れなくなった
＜結果＞
30分弱しゃべったんですが、それなりに喋る事は出来ました。しかし元の内容の作りが甘かったのでしゃべっている途中で話のLogicがぐちゃぐちゃになってしまいました。
そもそもこのYouTubeは、アメリカと言うか世界で大問題になっているのに日本で全く報道されていないNewsを紹介して、それについて私のCommentを追加する形式にするはずでした。
なんで共和党の崩壊という私の単なる予測をまとめる形式にしたんでしょうか？
その辺から元の内容の作りが甘かったです。
でも細部には
- アメリカでは実質、中絶が禁止になっている
- アメリカのZ世代について
- Fox Newsが1000億円位の和解金を払った件
- Fox NewsのTucker Carlson氏が首になった件
- Florida州知事であるDeSantis氏とDisneyの争いの件
- Matt Gaetz議員がAOC議員と組んで議員の利権に切り込んだ件
について述べています。
これらは全く日本で報道されないが世界では非常に大きなNewsになっています。
あ「日本では全く報道されないが世界では非常に大きな話題になっているNewsについて紹介する。」と言った方が、「アメリカと言うか世界で大問題になっているのに日本で全く報道されていないNewsを紹介する。」と言うより断然分かり易いです。
で、こういう話題を紹介するには私、正直まだ力不足を感じる場面がありました。
例えば、Fox NewsのTucker Carlson氏ですが、私ずっとCarl Tuckersonって名前だと思っていました。
この辺の正確性をどこまで追求するのか、がこれからの課題です。
流石にTucker Carlson氏をCarl Tuckersonって読んだらそのYouTube Channelの信頼性は0になってしまいます。
でも、あんまり正確性を追求すると動画を作成するのに丸一日とか費やす必要が出て来ます。
それを専門でやる訳でもないので、そんなに時間をかける訳にはいかないです。
9.2 任天堂が英語圏のInfluencerからフルボッコにされている件でとんでもないNewsが入って来たのでその続きです。
なんとKotakuという英語圏のGame系のMediaでもっとも大きくもっとも信頼のある会社が、違法にLeakされたゼルダの新作を大々的に記事して紹介したそうです。
これは任天堂がKotakuをブラックリスト入りしたので、新作のゼルダの情報が手に入らないからその復讐なんだそうです。
もう、なんか日本人の常識からしたら訳分からなすぎて絶句してしまいます。
で、このNewsに関してYouTubeの動画を見たら事情が大体判明したので、まずそれをまとめます。
次に、これに対してのアメリカ世論をまとめます。
そして私の意見をまとめます。
最後に、私が思う解決策を述べる事にします。
まず何でKotakuが任天堂からBlacklistに入れられたのかについてですが、これもすぐに分かりました。
任天堂は任天堂のGameに対してのEmulatorの使用に対して極めて厳しい態度で接する事で有名です。
これは先週や先々週のBlogで検証した結果、EmulatorやModの存在を認めてしまうと以下の問題が発生するからと判明しました。
- 簡単にHackされるようになってUserの安全を守れない。
- IPの価値が汚染される。
以下に簡単に解説します。
＜簡単にHackされるようになってUserの安全を守れない＞
PC Gameはどうなのか？と言う人がいますが、PCは元々HackされたらそれはそのPCの持ち主の責任なんです。PCは持ち主がそのPCの安全を保つ責任があるんです。
しかしSwitchで遊ぶ層は、別にPCの専門家ではありません。というかそういうIT関連にうとい層が遊ぶためのものです。
任天堂がUserが安全にGameを遊べるようにUserを守る必要があるんです。
AppleのiPhoneやiPadの対応を見ると全く同様の対応をしています。
ので、これはかなり必要な事です。
＜IPの価値が汚染される＞
これは私もかなり誤解していました。
任天堂は一寸過剰にIPを守り過ぎているんじゃないのか。と思っていました。
最近のGameはともかく、もうPlayする事ためのConsoleが販売していないGameに関してはEmulatorでPlayしても良いんじゃないの。と思っていました。
しかしSonyのPlayStationが今まで誕生したIPをほとんど全部消滅させてしまった事を考慮すると、任天堂ぐらい厳しくIPを守らないとすぐにIPは消滅してしまうんだという事が判明しました。
同様のCaseとしてDisneyがあります。
Disneyも別に古いIPだから自由に使っていいとは絶対に言いません。
だからDisney Landは劣化しないんです。
＜＞
ので任天堂がEmulatorに対して非常に厳しい態度をとるのは当然かつ必要なんです。
それに対してアメリカ人がどう考えているかですが、これは世論と法律で微妙に違います。
まず法律ですが、
Emulatorを作成する事もPCでEmulatorを使用してPlayする事も違法ではない。
ただし違法なCopy、つまり海賊版などをPlayした場合や、Emulatorの使用方法を積極的にNetなどで紹介して、IPの持ち主に不利益になる行為をした場合は違法。
その場合は被った不利益の全てを賠償する責任を負うし、かつ刑事罰も負う事になる。
となっています。
と言っても私がそう解釈しただけですので、実際は裁判の判決が出ないと分からない部分は勿論あります。
次にアメリカ人の世論ですが、ここ2週間でかなり変わりました。
まず任天堂は脅したら引くだろうと思ってたみたいですが、まったく引かないどころか、どんどん攻撃を掛けて更にとんでもない賠償を請求するので、甘く見てたかも。と一寸後悔しています。
後、Game系のYouTuberも任天堂のIPが全く使用出来なくなると信用にかかわるので、ある程度の所で手打ちをしたいと思っていました。
そこで先週のBlogに書きましたが、任天堂がEmulatorの使用に関しての動画を消したらゼルダの新作を先行Playさせてやる。という飴を用意したので直ぐに和解しました。
ここまでが前提の話になります。
まずKotakuは、3カ月か半年前位に任天堂が出した新作を発売してすぐにEmulatorを使用すればSteam DeckでそのGameが４KでPlay出来るという記事を書きました。
しかも海賊版もあって無料でPlay出来る事までほのめかしていたそうです。
これは先程解説した内容に照らし合わせたら分かりますが、完全な違法行為です。
言うなれば、赤信号なのに車で減速しないで直線する位の、誰の目から見ても分かる位の違法行為です。
当然、任天堂はKotakuに抗議しました。
ところが任天堂の講義をKotakuは無視します。
まあ、その時は任天堂に対してのInfluencerからの攻撃が凄かったので、Kotakuに対しても正義の味方と捉えるアメリカ人も多かったのかもしれません。
その結果、任天堂はKotakuをBlacklistにのせ、それ以来全く新作のGameの情報を供給しないようにしました。
その結果、Kotakuは今回ゼルダの新作の情報を一切得る事が出来なくなりました。
で、Kotakuが反省したのかと言うと、事実は全く逆で任天堂に対して激高して、Hackingなどの違法行為をして得たゼルダの新作のLeak情報を全部、記事にするという暴挙に出ました。
はい。
これに対するアメリカの世論ですが、あんまりKotakuを支持している人はいません。
Influencer達ももう任天堂と事を構えたくはないのと、明らかにKotaku側が違法行為をしているので、静観しているか、逆に任天堂を支持しています。
＜この件について私が思う事＞
はい。
まず任天堂の取った行動ですが、正しかったと思います。
次にKotakuの態度ですが、Emulatorの問題は確かに白黒はっきり言えない部分は有る事を考慮しても、幼稚過ぎます。
任天堂はKotakuを裁判で徹底的に追い込むべきだと思います。
賠償金を取るだけでなく、この会社が持つ信用を破壊すべきです。
ここで、比較対象として非常に面白いSampleになりそうなのがCapcomです。
CapcomはStreet Fighter６というGameをReleaseするそうですが、賞金一億円の大会付きだそうです。
それで聞いた話なんですが、海外勢は、このGameを既にHackingでPlay出来る状態にして、現時点で十分な練習を積んでいるそうです。
ところがCapcomは海外勢がそういう違法行為を行っていても、彼らを追い出すと海外からの売り上げが減少したりバッシングを受けたりする可能性があるので、これからはしないで下さいと、言って終わってしまったそうです。
もうほとんどいじめられっ子が虐めないでと泣きながらお願いするみたいな事をしてしまいました。
任天堂と180度真逆の対応です。
どっちがより良い結果に結びつくんでしょうか？
それは分かりません。
しかし私は任天堂は正しい選択したと思っています。
それは昔、遊戯王カードで同じような事件が起きた話を聞いたことがあるからです。
まあ有名で人気のあるPlayerが公式の対戦でズルしたそうなんです。
でも、その人をそこで失格にすると大会の運営依然にアメリカで遊戯王カードの販売すら危うくなりそうだと。
でも結局、失格にしたそうです。
その結果、その人とその人のFollowerは全部、遊戯王カードから去りました。
それでアメリカで遊戯王カードの人気が廃れたのかと言うと、逆で遊戯王はRuleをしっかり守るとの評価を得て、そこに価値を見出すアメリカ人が多く集まるようになったんです。
Ruleを守る事に価値を見出す人達が集まったので、PlayerのMannerも良くなりました。
と言う訳で、最終的には遊戯王カードにとってはかなり良い結果になりました。
この話を聞いているので私は任天堂の対応が正しいと思います。
ただしCapcomの対応が100％間違っているとも思っていません。
HackingなんてProgrammingを勉強していたら、出来て当たり前です。
一億円もかかっている大会だったら参加者も命がけでしょうし、そういう勝負で卑怯も汚いもないです。Hacking位するでしょう。勝った方が正しいだけです。
そういう勝負事で、相手がイカサマしたから負けました。と言うのは軟弱すぎます。
のでCapcomの対応は一寸情けないですが、Hackingまでして勝とうとするアメリカ人の態度は、勝負事として見るとそれはそれで有りだとは思っています。
＜私の考える対応策＞
また、素人が出しゃばって何言っているんだと思われそうですが、秘策があります。
のでここでそれを書いておく事にします。
まず、Kotakuとは手打ちをします。これ以上Emulatorに関する記事やLeak情報を載せない代わりに、賠償金だけで勘弁してあげます。
正し、その記事を書いた記者を首にする事を条件にします。
そしてその記者を徹底的に追い込みます。全部の賠償金を押し付けて二度と立てないまで潰します。
これ、同じ罪を犯した人達に同じ様に罰を与えると結束してしまうんです。
ところが、片方だけ罰してもう片方は許してあげると、絶対に仲違いを始めます。
ズルい。Unfairだと。
こうなるとお互いに喧嘩を始めます。
こっちに攻撃しなくなってもっと簡単に相手を追い込む事が出来るようになります。
そして対外的には任天堂のGameを違法にCopyして遊ぶとこんな酷い目にあうまで、追い込まれるのかと実証にもなります。
人間はその性質として、危険は可能性があるだけでも避けるようにします。
ので全員に同様の罰を与えなくても一人だけ徹底的に潰せば、それが抑止力になってEmulatorを使用する人もいなくなると言う訳です。
１０．DirectXの勉強
10.1 C++ DirectX 12 Game Engine - [S01E03] - Creating A Game Engine [2]のFinishing Touchesの続きを勉強
10.1.1 先週の復習
まずは先週のBlogを読んで復習をします。
先週の内容は結構複雑で、理解出来ない部分があったはずです。その理解出来ない部分についても何が理解出来なかったのかをきちんと言語化しておきます。
先週はFinishing Touchesの前半を勉強しました。
この時点で一寸疑問があります。
UEでは別にEngineを一々Buildしません。ProjectをBuildするだけです。そして実行するのもProjectだけです。しかしProjectを実行すれば自然とEngineも実行されます。
Engineを実行した場合はUE editorが起動するだけです。
これと同じならOlympus Engineを実行した時に、同時にBlank Projectが実行されるのはオカシイです。
まあ、Game Engineなら何でも同じとは限りませんのでこういう疑問を持っていると言う事を確認しつつ先に進む事にします。
やっぱりOlympus EngineのWinEntry.hからBlank ProjectのApplicationを呼び出そうとしています
このEntryApplication()の実装はBlank Project内で書かれています。
この場合はAppicationになるはずです。
先週はExternの機能を忘れてしまっていたのでその復習もここでしていました。
次にOlympus Engine ProjectにあるWinEntry.hのEntryApplication()のErrorを消すために
以下の事をしていますが、
この意味がよく分からないと書いています。
この意味は先週の時点で判明したんですが、よくまとめられていないのでここで改めて言語化しておきます。
まずここでEntryPoint()と書いていますが、これはTYPOで本当はEntryApplication()です。
このXは以下に示した様にApplicationが使用されています。
そしてApplicationはIApplication Classを継承しているので、文法的に正しい関数になります。
のでOlympus Engine ProjectにあるWinEntry.hのEntryApplication()はBlank ProjectのApplicationを返せるようになりました。
本当はここでEntryApplication()のErrorが消えて、感動で終わるはずなんですが消えません。
これは変数名と関数名が同じせいです。
ので先週は最後に変数名を変更して
Errorを消して終わっています。
10.1.2 C++ DirectX 12 Game Engine - [S01E03] - Creating A Game Engine [2]のFinishing Touchesの続きを勉強
本当は、今週は先週勉強した内容を実装しようと思っていたんですが、復習した結果、特に理解出来てない箇所も無い事が判明したのでFinishing Touchesの残り半分を先に勉強する事にします。
Olympus Engine ProjectにあるWinEntry.hのEntryAppにある
Applicationを実行するためにBlank ProjectにあるApplication.ｈを確認すると
Initialize()関数を読んで、Update()関数を呼ぶ必要があります。
ので、Initialize()関数を使用します。
ただしBlanc projectのApplication ClassにあるInitialize()関数は何も実装していません。
ので以下のようにApplication.cppのInitialize()関数内に以下の実装を追加します。
テストのためにこれをRunします。
Errorになりました。
まず最初のErrorですが
Olympus.dllが見つからないと言っています。
この問題を解決するためにはまずOlympus EngineのBuild Folderを開きます。
ここでは前に設定した通り、２つの別々のFolderがあります。
Errorを消すためにはこの２つを統合する必要があります。
Olympus Engine内のBuild、OlympusそしてDebug Folderを開くと以下のようになっていますが、
ここにOlympus.dllが存在する必要が有るそうです。
次のErrorですが
以下の=0が駄目だと言っているそうです。
うーん。
今は頭が働きません。
そういう事を言っている気もしますが、よく分かりません。後で考えます。
以下の様に変更します。
そしてOlympusをBuildします。
今度はErrorなくBuildされました。
そしてOlympus Engine内のBuild、OlympusそしてDebug Folderを確認すると
今度はOlympus.dllが出来ています。
そのOlympus.dllをCopyしてBlank ProjectのDebugにPasteします。
うーん。
EngineをUpdateするたびに毎回これをやる必要があるの？
Blank Projectを選択してSet as Startup Projectを選択します。
この状態で実行します。
以下のBoxが表示されました。
うーん。
Application.cppのInitialize()関数内で指定した通りの結果が表示されました。
これで２つのProjectを跨いでBlank Projectを実行する事が可能になった事が確認出来ました。
今度はWinEntry.hのWinMain()関数にApplication ClassのUpdate()関数を追加します。
そのためにBlank ProjectのWinMain.cpp内にあるMeessageLoop()関数の実装をCopyして
Olympus Engine Project内のWinEntry.hのWinMain()関数内にPasteし
If節内にElseを追加してEntryApp―＞Update()を追加する事でApplication ClassのUpdate()関数を呼び出します。
そしてBlank Project内のApplication.cpp内のUpdate()関数内に以下の実装を追加します。
でこれで完成か。
テストして終わりかな。と思ったらもうひと手間ありました。
まずOlympus Engine Projectの実装を変更したのでOlympus Engine ProjectをBuildする必要があります。
次にBuildして生成された新しいOlympus.dllをOlympusのDebug Folderに行ってCopyして
そのCopyをBlank Project内のDebug Folder内にPasteします。
これをしないとBlank Projectが参照するOlympus.dllが最新のOlympus Engine Projectの内容と同じになりません。
うーん。
やっぱし。
これは結構大変です。
この部分を自動化出来ないとかなり面倒ですね。
後で、この部分を自動化すると思います。
テストします。
最初のBoxが表示されました。
OKを押すと以下のBoxが表示されました。
Application ClassのUpdate()関数も正常に作動していました。
ここでFinishing Touchesは終わりです。
キリが良いので今週のOlympus Engineの勉強もこれで終わりにします。
10.2「DirectX 12の魔導書」の勉強
10.2.1「DirectX 12の魔導書」の先週の勉強を復習する
先週のBlogを読み直しました。
先週は「3.3.5 Render Target View (RTV)」の続きを読んでその内容をまとめています。
その過程で、Descriptorの解釈がViewやSamplerを沢山含んだContainerみたいなのものから単なるViewやSamplerを指しているのではないか。と変化したと書いています。
そして最後に以下の様にまとめています。
実装するにあたって、今まで「3.3.5 Render Target View (RTV)」で勉強した手順を以下にまとめておきます。
- Descriptor Heapを作成する
- Swap ChainのMemoryと紐づける
基本的はこの２つしかやっていません。
Swap ChainのMemoryとの紐づけはかなり複雑な手順です。実装しながら解説する事にします。
10.2.2「3.3.5 Render Target View (RTV)」の実装を行う
＜Descriptor Heapを作成する＞
D3D12_DESCRIPTOR_HEAP_DESC型の変数を作成します。
D3D12_DESCRIPTOR_HEAP_DESCはStructなのでそれぞれのMemberの値を指定します。
このD3D12_DESCRIPTOR_HEAP_DESCについて先週のBlogで調査していたと思っていたんですが、してなかったです。
今調べます。
公式サイトのD3D12_DESCRIPTOR_HEAP_DESC structure (d3d12.h) [12]です。
当然、Structです。構成しているMemberは以下の４つがあります。
一個ずつ見ていきましょう。
＜＜Type＞＞
ここではD3D12_DESCRIPTOR_HEAP_TYPE enumerationを使用してDescriptor HeapのTypeを指定します。
公式のD3D12_DESCRIPTOR_HEAP_TYPE enumeration [12]を見ると以下の５つの要素から選択出来るそうです。
今回はRTVのためのDescriptor HeapなのでD3D12_DESCRIPTOR_HEAP_TYPE_RTVを使用しています。
＜＜NumDescriptors＞＞
このDescriptor Heapに何個のDescriptorをセットするのかを指定するそうです。今回はDouble Bufferingなので２つのDescriptorをセットします。
＜＜Flags＞＞
教科書にはここはGPU側からこの情報を見る必要が有るかどうかを指定する。と書かれていました。
公式サイトのD3D12_DESCRIPTOR_HEAP_DESC structure (d3d12.h) [12]では
としか書かれていませんね。
D3D12_DESCRIPTOR_HEAP_FLAGS enumeration (d3d12.h) [13]の解説も見てみます。
Syntaxを見ると以下に示した様に
NoneとShader_Visibleしかないですね。
教科書の説明であってそうです。
＜＜NodeMask＞＞
これはVideo Cardの数が一個以上の場合に指定するそうです。今回はVideo Cardは一個しか使用していないので0と指定します。
うーん。
この教科書は最初にVideo Cardが複数ある場合を想定して実装を書き始めたので、ここでいきなり「今回はVideo Cardは一個しか使用していないので0と指定します。」と書かれても、あれ？って思います。
教科書を読み直したら「3.2.2 Direct 3Dの初期化」でしっかりVideo Cardが複数ある場合の対応方法について書いています。
うーん。
同じ3章内で前提条件が変わってしまっているのか。
一寸不安。
次にID3D12DescriptorHeap型の変数を作成します。
これで
CreateDescriptorHeap()関数を使用する準備が整いました。
以下の様に実装しました。
CreateDescriptorHeap()関数に関しては先週のBlogで調査しています。
これでDescriptor Heapは生成されるはずです。
それではTestします。
いつもの以下のTest用のCodeを追加して
実行します。
普通に動いています。
更にResultの値には
S_OKが入っていました。
出来ています。
今週はもう少しやる予定だったんですが、本当に時間が無くなってしまいました。
ので「DirectX 12の魔導書」の勉強はここまでとします。
10.3 「HLSLシェーダーの魔導書」を勉強する
10.3.1 先週の復習
先週は教科書の「3.2 Texture Mapping」を読んだんでした。
特に分からない箇所とかも無かったようなので今週は教科書の「3.2 Texture Mapping」の実装を行います。
10.3.2 「3.2 Texture Mapping」の実装を行う
教科書の指示通りにやって行きます。
まずSample CodeのSample 03_02を開きます。
以下の箇所にCodeを追加していきます。
＜Step-1 三角形ポリゴンにUV座標を設定＞
以下の様に実装しました。
どっかに正解のSampleがあるはずですが、見つからないので全部手で打ちました。
＜Step-2 TextureをLoad＞
Polygonに張り付けるTextureをImportします。
これも手打ちしました。
TextureのAddressだけ確認します。
Sample.ddsのAddressは\Assets\Imageとなっていました。
￥は以下に示した様に
英語版だとBack Slashです。
うーん。これでも読み込めるのか？
調べるのも面倒なんので取りあえずこのままでいきます。
Textureが読み込めなかった時はこの部分を疑う事にします。
＜＜Step-3 TextureをDescriptor Heapに登録＞＞
はい。
しました。
ここまで実装したら教科書にMainAfter.cppに実装した後のCodeがありますので参考にして下さい。と書いてありました。
ありました。
うーん。
多分、手打ちした方の実装をそのまま使用しても大丈夫でしょう。
今度はHLSL側の実装です。
Sample.fxを開きました。
Step 4とStep 5がありました。
今度はsample.after.fxも先に開いておきます。
これならTypoとかしないで実装出来るでしょう。
＜Step-4 t0 RegisterのTextureにAccessする変数を追加する＞
しました。
CPU側でt0にTextureの値を入れたので、GPU側でt0からTextureの値を回収している訳です。
それ以上の事は分かりません。
＜Step-5 Texture ColorをSamplingして返す＞
Sample CodeをそのままCopyして貼り付けました。
g_samplerが何をしているのか分かりませんね。
うーん。
これがSamplerなの？
おお。
初めてSamplerをいじりました。
＜Test＞
Testします。
普通に出来ました。
「HLSLシェーダーの魔導書」はこんな感じで軽めにやって行きます。
後で、他の教科書の内容と繋がったら、細かい実装の仕組みを見る事にします。
10.4「Direct3D 12 ゲームグラフィック実践ガイド」の勉強
10.4.1 先週の復習
先週はとうとう、DXGI_SWAP_CHAIN_DESCの全部のMemberの機能の調査が終わりました。
ので今週はその先を勉強します。
教科書を見るとSwap Chainの設定（つまりDXGI_SWAP_CHAIN_DESCの全部のMemberの指定）をした後は、Swap Chainの生成を行っています。
更にその後では、Swap Chainが正しく生成されたかを調べ、そうでない場合はRelease Methodを用いて解放しています。
うーん。どの辺まで実装したのか覚えていません。
調べます。
うーん。
Swap Chainの設定すら実装していませんでした。
今週はそれをやります。
10.4.2 Swap Chainの設定の実装
しました。
Sample Codeから丸っとCopyしました。
今週はここで時間切れです。
いつもDirectX 12の勉強が割り食ってしまっていますが、別に進んでいない訳ではないです。
後、一寸と言えどDirectX 12の勉強をすると頭の中が整理されて他の分野の勉強している時も、論理的に考える事が出来るので役には十分立っています。
１１．まとめと感想
今週も時間がないのでここはなしです。
１２．参照（Reference）
[1] CGHOW. (2023, April 24). Disintegration into Sand Unreal Engine 5.2 Niagara Tutorial | Download Files [Video]. YouTube. https://www.youtube.com/watch?v=MdCY1VWtYKs
[2] OlympusMonsTutorials. (2021, March 17). C++ DirectX 12 Game Engine - [S01E03] - Creating A Game Engine [Video]. YouTube. https://www.youtube.com/watch?v=YgZSSE3qZqA
[3] UE5: “Landscape Physical Material Needs to be Rebuilt.” (2021, June 8). Epic Developer Community Forums. https://forums.unrealengine.com/t/ue5-landscape-physical-material-needs-to-be-rebuilt/484614
[4] NumenBrothers. (2023, February 18). Let’s Build the RPG! - 56 – Landscape Cave Sculpting and Lighting – Unreal Engine 5 Tutorial [Video]. YouTube. https://www.youtube.com/watch?v=EYwfDQK645Y
[5] renderBucket. (2023, April 23). Unreal Engine 5.2 - Crystal, Ice, Gemstone Materials Tutorial [Video]. YouTube. https://www.youtube.com/watch?v=G31OTd69rYw
[6] Ben Cloward. (2022, December 8). Fabric Shaders - Advanced Materials - Episode 10 [Video]. YouTube. https://www.youtube.com/watch?v=cTqQ4AYNTKM
[7] Unreal Engine. (2023, April 27). Creating realistic landscapes in Unreal Engine with Houdini | GDC 2023 [Video]. YouTube. https://www.youtube.com/watch?v=CKN3ee2uNDE
[8] What is lidar? (n.d.). https://oceanservice.noaa.gov/facts/lidar.html#:~:text=Lidar%20%E2%80%94%20Light%20Detection%20and%20Ranging,Lighthouse%2C%20Dry%20Tortugas%2C%20Florida.
[9] Unreal Engine. (2023, April 24). The Verse Programming Language | GDC 2023 [Video]. YouTube. https://www.youtube.com/watch?v=5prkKOIilJg
[10] JSFILMZ. (2023, March 23). Fortnite Creative 2.0 Beginner Tutorial [Video]. YouTube. https://www.youtube.com/watch?v=1xmVuhXmHD8
[11] Fortnite - Introduction | Epic Developer Community. (n.d.). Epic Developer Community. https://dev.epicgames.com/community/fortnite/new-to
[12] Stevewhims. (2022, January 31). D3D12_DESCRIPTOR_HEAP_TYPE (d3d12.h) - Win32 apps. Microsoft Learn. https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ne-d3d12-d3d12_descriptor_heap_type
[13] Stevewhims. (2022, January 31). D3D12_DESCRIPTOR_HEAP_FLAGS (d3d12.h) - Win32 apps. Microsoft Learn. https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ne-d3d12-d3d12_descriptor_heap_flags
