UE4
oga at 20:26
UE4 のビルドツール UnrealBuildTool はビルドファイルの定義に *.Target.cs や *.Build.cs を使います。それとは別に、デフォルトパラメータを定義できる BuildConfiguration.xml があります。

UE4 Programming Guide / BuildTools / UnrealBuildTool / Build Configuration

例えば次の内容で BuildConfiguration.xml を作り、Documents のフォルダ "Unreal Engine\UnrealBuildTool" に入れておくと UnityBuild を無効化することができます。

<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns="https://www.unrealengine.com/BuildConfiguration">
        <BuildConfiguration>
                <bUseUnityBuild>false</bUseUnityBuild>
        </BuildConfiguration>
</Configuration>

※ UnityBuild を off にするとビルドが極端に遅くなるのでお勧めしません。

BuildConfiguration.xml のチェックが行われている場所は以下の 4 つです。

(1) Engine\Programs\NotForLicensees\UnrealBuildTool\BuildConfiguration.xml
(2) Engine\Saved\UnrealBuildTool\BuildConfiguration.xml
(3) C:\Users\<USERNAME>\AppData\Roaming\Unreal Engine\UnrealBuildTool\BuildConfiguration.xml
(4) C:\Users\<USERNAME>\Documents\Unreal Engine\UnrealBuildTool\BuildConfiguration.xml

この順番で読み込まれるため、下の方が優先順位が高くなります。

(3), (4) はすべてのエンジンに対して有効になります。UE4 のバージョンによって設定項目に若干違いがあるので、複数のエンジンを併用している場合は注意が必要です。エンジンによってエラーが出る場合は (2) のようにエンジン毎のフォルダに入れておいた方が良いかもしれません。

たとえば ProcessorCountMultiplier は UE4 4.20 までは BuildConfiguration に含まれていました。4.21 では無くなっており、代わりに Executor 毎の個別パラメータを使うようになっています。

UE4 4.20 の場合

<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns="https://www.unrealengine.com/BuildConfiguration">
        <BuildConfiguration>
                <ProcessorCountMultiplier>2.0</ProcessorCountMultiplier>
        </BuildConfiguration>
</Configuration>



UE4 4.21 の場合

<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns="https://www.unrealengine.com/BuildConfiguration">
        <LocalExecutor>
                <ProcessorCountMultiplier>2.0</ProcessorCountMultiplier>
        </LocalExecutor>
        <ParallelExecutor>
                <ProcessorCountMultiplier>1.0</ProcessorCountMultiplier>
        </ParallelExecutor>
</Configuration>

ParallelExecutor は 4.21 で新しく追加されたものです。以前の LocalExecutor も残っていますが、分散ビルドを使わない場合 4.21 以降はデフォルトが ParallelExecutor になります。

LocalExecutor の場合、4 core 8 thread の CPU ではデフォルトでビルドに 4 thread 使います。ProcessorCountMultiplier を 2.0 にすると 8 thread 全部使うようになります。8 core 16 thread の CPU ではなぜかデフォルトで 12 thread、ProcessorCountMultiplier を 2.0 にすると 16 thread になります。計算が合わないように見えるのは、5 core 以上で計算式が変わるからです。

// UBT LocalExecutor の計算式
if( ProcessorCountMultiplier == 1.0 ){
   if( Core数 > 4 ){
       ビルドに使う thread 数 = ( Core数 + Thread数 ) / 2;
   }else{
       ビルドに使う thread 数 = Core数;
   }
}else{
   ビルドに使う thread 数 = Core数 * ProcessorCountMultiplier;
}

4.21 から追加された ParallelExecutor では特に ProcessorCountMultiplier を設定しなくても、最初からハードウエアと一致する 8 thread や 16 thread でビルドが行われています。まとめると下記の通り。


Executor LocalExecutor ParallelExecutor
Multiplier 1.0 2.0 1.0 2.0
Skylake i7-6700K ( 4C8T ) 4 8 8 16
CoffeeLake i7-8700K ( 6C12T ) 9 12 12 24
Ryzen 7 1800X ( 8C16T ) 12 16 16 32

つまり以前の LocalExecutor の場合、ProcessorCountMultiplier = 2.0 は効率を上げるために有効でしたが、ParallelExecutor では本来の倍のスレッドが走ってしまいます。古い設定を継承するとスレッド数が過剰になるため BuildConfiguration から削除されたのかもしれません。ちなみに ParallelExecutor は下記の設定で無効化できます。

<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns="https://www.unrealengine.com/BuildConfiguration">
        <BuildConfiguration>
                <bAllowParallelExecutor>false</bAllowParallelExecutor>
        </BuildConfiguration>
</Configuration>

このように UnrealBuildTool には様々な設定があります。オプションの種類は下記のファイルを見るとわかります。

Engine\Saved\UnrealBuildTool\BuildConfiguration.Schema.xsd

このファイルを見ると UE4 4.22 からは cpp のオプションが増えている事がわかります。下記のような設定もできるようになりました。

<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns="https://www.unrealengine.com/BuildConfiguration">
        <BuildConfiguration>
                <CppStandard>Cpp14</CppStandard>
        </BuildConfiguration>
</Configuration>


関連エントリ
UE4 UnrealBuildTool VisualStudio の選択を行う
UE4 UnrealBuildTool *.Build.cs のコードを共有する


UE4
oga at 19:35
UE4 で C++ プロジェクトを作ると VisualStudio 用のプロジェクトファイル *.vcxproj や *.sln も自動的に作られます。ただしこれらのファイルは UE4 のビルドシステムにとっては必ずしも必要ではなく、IDE を使うための中間ファイルとみなされています。そのため IDE プロジェクトファイルは Git や Perforce には登録されず、必要になったタイミングで作り直します。

VisualStudio プロジェクトファイルを作るには *.uproject ファイルの関連付けを利用するのが最も簡単です。*.uproject ファイルの上で右クリックして "Generate Visual Studio Project files" を選択します。

このとき呼ばれているツールは UnrealVersionSelector.exe です。内部で UnrealBuildTool を呼び出しているのですが、UnrealVersionSelector 経由だとあまり細かいオプション指定ができないようです。

オプション指定を行う場合は、直接 UnrealBuildTool を呼び出すか、またはソースコード版 Engine の GeneratedProjectFiles.bat を使うことができます。


●任意の VisualStudio のバージョンを指定して Project File を作る

UnrealBuildTool や GeneratedProjectFiles.bat を使うと、使用する VisualStudio のバージョンを指定することができます。*.uproject への関連付けも不要ですし、複数のバージョンの VisualStudio をインストールしている場合に便利です。

例えば UE4 4.21 で VisualStudio 2015 を使う場合下記のように "-2015" オプションを指定します。

set ENGINE_PATH=c:\Program Files\Epic Games\UE_4.21

"%ENGINE_PATH%\Engine\Binaries\DotNET\UnrealBuildTool.exe" -projectfiles -project=c:/ue/MyProject421/MyProject421.uproject -game -engine -progress -2015

*.uproject ファイルはフルパスで指定する必要があるので注意。

GitHub のソースコード版を使っている場合は GeneratedProjectFiles.bat を使って同じことができます。

set ENGINE_PATH=c:\ue\4.21.0

%ENGINE_PATH%\GeneratedProjectFiles.bat -project=c:/ue/MyProject421/MyProject421.uproject -game -engine -progress -2015

同様に -2017 や -2019 (4.22 以降) もあります。↓ 4.22 で 2019 を使う場合の例。

c:\ue\4.22.0\Engine\GeneratedProjectFiles.bat -project=c:/ue/MyProject422/MyProject422.uproject -game -engine -progress -2019

ソースコード版エンジンそのものをビルドする場合は GeneratedProjectFiles.bat に -2017 や -2019 などのオプションをつけるだけで OK です。

c:\ue\4.22.0\GeneratedProjectFiles.bat -2019


●プロジェクトファイルの Platform 数を制限する

プロジェクトファイルを作るときに、-platforms オプションを与えておくと不要な Platform を除外してくれます。例えば Win64 と Android だけ含めたい場合は "-platforms=Win64+Android" になります。プロジェクトファイルが小さくなるので、VisualStudio での読み込みが若干速くなります。

set ENGINE_PATH=c:\ue\4.21.0

%ENGINE_PATH%\Engine\Binaries\DotNET\UnrealBuildTool.exe -projectfiles -project=c:/ue/MyProject421/MyProject421.uproject -game -engine -progress -2015 -platforms=Win64


●ビルド時に直接コンパイラのバージョンを指定する

UE4 のビルドは UnrealBuildTool が行います。IDE も UnrealBuildTool を呼び出しているだけなので、直接ビルドすることもできます。この場合も -2015 や -2017 等のオプション指定ができます。

set ENGINE_PATH=c:\ue\4.21.0

%ENGINE_PATH%\Engine\Build\BatchFiles\Build.bat MyProject421Editor Win64 Development -project=c:/ue/MyProject421/MyProject421.uproject -2015

最初の引数 "MyProject421Editor" は、ビルド対象の *.Target.cs を意味しています。"MyProject421Editor" は MyProject421Editor.Target.cs を選択します。Editor なしでビルドしたい場合は MyProject421 です。

4.21 と 4.22 では若干引数が変わっているので、直接 UnrealBuildTool.exe を呼び出すよりは Build.bat や Rebuild.bat を使った方がおそらく安全でしょう。

どのようなコマンドライン引数でビルドが行われているのか VisualStudio のプロパティからも確認できるので、うまくビルドできない場合は確認してみることをおすすめします。


関連エントリ
UE4 UnrealBuildTool *.Build.cs のコードを共有する


UE4
oga at 19:18
UE4 は C# で書かれた独自のビルドシステム UnrealBuildTool を使用しています。Makefile に相当するのが Module 毎に用意する *.Build.cs ファイルです。

例えば GameProject/Source/GameModule をビルドする場合下記のようなファイルを作ります。

// GameProject/Source/GameModule/GameModule.Build.cs
using  UnrealBuildTool;

namespace UnrealBuildTool.Rules
{
    public class GameModule : ModuleRules {
        public GameModule( ReadOnlyTargetRules Target ) : base( Target )
        {
        }
    }
}

この中で依存モジュールの宣言や、外部ライブラリの path 追加などさまざまな設定を行うことができます。

*.Build.cs の他に Project 全体の設定を記述する *.Target.cs もあります。

*.Build.cs Module 毎のビルド設定
*.Target.cs Project 全体のビルド設定

Target.cs はあくまで Project 単位に用意するため Plugin にはありません。また Build 対象に応じて Target.cs が変わるため複数存在します。

~.Target.cs Game
~Editor.Target.cs Editor
~Server.Target.cs Server
~Client.Target.cs Client


●他の Module を参照する場合

UE4 内部の Module 同士の依存関係は Module 名で管理されています。そのため Module については個別に Include path を与えたり Link するライブラリを指定する必要がありません。

例えば依存ファイルとして下記のような宣言を行えば、それぞれの Module への include も Link する Lib も自動で管理してくれます。

PublicDependencyModuleNames.AddRange( new string[] {
        "Core",
        "CoreUObject",
        "Engine",
        "Projects",
    });

Public と Private の違いはわかりにくいですが、依存している Module の Include path を追加するかどうかの違いとなります。

例えば GameModule を参照している他の MainModule があったとします。

// GameModule.Build.cs
using  UnrealBuildTool;

namespace UnrealBuildTool.Rules
{
    public class GameModule : ModuleRules {
        public GameModule( ReadOnlyTargetRules Target ) : base( Target )
        {
            PublicDependencyModuleNames.AddRange( new string[] {
                    "Core",
                });
        }
    }
}

// MainModule.Build.cs
using  UnrealBuildTool;

namespace UnrealBuildTool.Rules
{
    public class MainModule : ModuleRules {
        public MainModule( ReadOnlyTargetRules Target ) : base( Target )
        {
            PrivateDependencyModuleNames.AddRange( new string[] {
                    "GameModule",
                });
        }
    }
}

このとき GameModule の Core は PublicDependency なので、MainModule の include path に Core が含まれます。もし GameModule の Core が Private なら MainModule の include path に Core は含まれません。

つまり、他の Module に公開したいヘッダファイルがある場合、ヘッダ側で include している Module は Public にしておく必要があります。他の Module から参照されることがない GameProject のような Module (PRIMARY_GAME_MODULE) では、すべて Private 宣言にして構いません。


●外部ライブラリを参照する場合

UnrealBuildTool は "ThirdParty" というフォルダを特別扱いします。このフォルダは検索対象から外れており、ソースコードがあっても勝手にビルドを行いません。外部ライブラリは一般的に ThirdParty フォルダに入れておきます。Build.cs では下記のように相対的に ThirdParty のパスを求めます。

using  UnrealBuildTool;

namespace UnrealBuildTool.Rules
{
    public class GamePlugin : ModuleRules {
        private string ThirdPartyPath
        {
            get { return Path.GetFullPath( Path.Combine( ModuleDirectory, "../../../ThirdParty/" ) ); }
        }

Include path, Lib path, Lib file 等は個別に指定が必要で、さらに Platform も複数あるので外部ライブラリの参照は複雑になりがちです。

using  UnrealBuildTool;
using  System.IO;
using  System.Collections.Generic;

namespace UnrealBuildTool.Rules
{
    public class GamePlugin : ModuleRules {
        private string ThirdPartyPath
        {
            get { return Path.GetFullPath( Path.Combine( ModuleDirectory, "../../../ThirdParty/" ) ); }
        }
        private Dictionary<UnrealTargetPlatform,string> PlatformTable= new Dictionary<UnrealTargetPlatform,string>(){
            {   UnrealTargetPlatform.Win64,     "Windows/x64",  },
            {   UnrealTargetPlatform.Win32,     "Windows/x86",  },
            {   UnrealTargetPlatform.Linux,     "Linux/x64",    },
            {   UnrealTargetPlatform.Android,   "Android28",    },
            {   UnrealTargetPlatform.Mac,       "macOS/x64",    },
            {   UnrealTargetPlatform.IOS,       "iOS/arm64",    },
        };
        public GamePlugin( ReadOnlyTargetRules Target ) : base( Target )
        {
            PublicDependencyModuleNames.AddRange( new string[] {
                    "Core",
                    "CoreUObject",
                    "Engine",
                    "Projects",
            }
            if( !PlatformTable.ContainsKey( Target.Platform ) ){
                return;
            }
            bool debug= Target.Configuration == UnrealTargetConfiguration.Debug && Target.bDebugBuildsActuallyUseDebugCRT;
            string  config= debug ? "Debug" : "Release";
            string  PlatformName= PlatformTable[ Target.Platform ];

            PublicIncludePaths.AddRange( new string[] {
                    Path.Combine( ThirdPartyPath, "flatlib" ),
                });
            if( Target.Platform == UnrealTargetConfiguration.Android ){
                PublicLibraryPaths.AddRange( new string[] {
                        Path.Combine( ThirdPartyPath, "flatlib/lib", PlatformName, "arm7", config ),
                        Path.Combine( ThirdPartyPath, "flatlib/lib", PlatformName, "arm64", config ),
                        Path.Combine( ThirdPartyPath, "flatlib/lib", PlatformName, "x86", config ),
                        Path.Combine( ThirdPartyPath, "flatlib/lib", PlatformName, "x64", config ),
                    });
            }else{
                PublicLibraryPaths.AddRange( new string[] {
                        Path.Combine( ThirdPartyPath, "flatlib/lib", PlatformName, config ),
                    });
            }
            PublicAdditionalLibraries.Add( "flatCore" );
        }
    }
}

外部ライブラリを必要としている Module や Plugin があれば、それぞれの Build.cs に記述しておく必要があります。Makefile の include のように共通の設定を動的に読み込む仕組みがあれば良いのですが、特に用意されていないようです。


●UnrealBuildTool による Build.cs の読み込み方

*.Build.cs は UnrealBuildTool によって dll に変換されます。


 (1) Intermediate/Build/BuildRules/~.dll を読み込む

 (2) もし *.Build.cs が更新されている場合は動的にコンパイルを行い dll を Reload する


この dll の生成は Project 単位で行います。例えば GameProject の場合、下記のファイルをまとめてコンパイルし単一の GameProjectModuleRules.dll が作られます。

GameProjectEditor.Target.cs
GameProject.Build.cs
GameModule.Build.cs
MainModule.Build.cs

  → GameProject/Intermediate/Build/BuildRules/GameProjectModuleRules.dll

Engine も同様で、下記の cs ファイルから単一の dll にコンパイルします。

Engine/Source/UE4Editor.Target.cs
Engine/Plugins/~/*.Build.cs
Engine/Source/~/*.Build.cs

  → Engine/Intermediate/Build/BuildRules/UE4Rules.dll

よって動的な include はできないものの、他の Build.cs や Target.cs で宣言したコードを呼び出すことが可能です。例えば代表 Module を 1つ決めて、Build.cs に共通で使いたいコードを書いておきます。 

// GameProject.Build.cs
using  UnrealBuildTool;
using  System.IO;
using  System.Collections.Generic;

namespace UnrealBuildTool.Rules
{
    public class ThirdPartyCommonLibrary {

        ~

        public static ThirdPartyCommonLibrary Create( ModuleRules rules, ReadOnlyTargetRules target, string path= null )
        {
            ~
        }
        public void SetupFlatlib()
        {
            ~
        }
    }

    public class GameProject : ModuleRules {
        public GameProject( ReadOnlyTargetRules Target ) : base( Target )
        {
            PublicDependencyModuleNames.AddRange( new string[] {
                    "Core",
                    "CoreUObject",
                    "Engine",
            }
            var lib= ThirdPartyCommonLibrary.Create( this, Target );
            lib.SetupFlatlib();
        }
    }
}

他の Module の *.Build.cs からも参照できます。これでメンテしやすくなりすっきりしました。

// GameModule.Build.cs
using  UnrealBuildTool;

namespace UnrealBuildTool.Rules
{
    public class GameModule : ModuleRules {
        public GameModule( ReadOnlyTargetRules Target ) : base( Target )
        {
            PublicDependencyModuleNames.AddRange( new string[] {
                    "Core",
                    "CoreUObject",
                    "Engine",
            }
            var lib= ThirdPartyCommonLibrary.Create( this, Target );
            lib.SetupFlatlib();
        }
    }
}



実行ファイルの置き換えに python を使用したときのメモです。Python 3 はプログラムコードを zip にアーカイブしたまま実行することができます。


●(1) Library として読み込む場合

テストコードを appmain.py, testmodule.py とします。

# appmain.py
import  testmodule

def main():
    testmodule.app()

if __name__ == '__main__':
    main()

# testmodule.py
def app():
    print( 'testmodule' )

そのまままとめて zip 圧縮可能で、Libpath に追加すると読み込むことができます。

### zip file を作る
import  zipfile

src_list= [
        'appmain.py',
        'testmodule.py',
    ]

with zipfile.ZipFile( 'applib.zip', 'w' ) as fo:
    for src in src_list:
        fo.write( src )


### zip file 内の code を実行する
import sys

sys.path.append( 'applib.zip' )

import  appmain
appmain.main()

embeddable 版の python3x.zip と同じように事前にコンパイルしておくこともできます。


●(2) zipapp (pyz) に変換してから実行する場合

zip ではなく zipapp (pyz) に変換すると script のように直接実行できるようになります。

予めサブフォルダ app を作って、その中に appmain.py, testmodule.py を入れておきます。下記のコードを実行すると pyz にまとめることができます。create_archive() 最初の引数 'app' はフォルダ名です。

import  zipapp

zipapp.create_archive( 'app', 'app.pyz', '/usr/bin/env python3', 'appmain:main' )

変換出力した app.pyz はただの zip ですが、エントリポイントとして __main__.py が挿入されています。この pyz ファイルはそのまま python で実行できます。

python app.pyz

また unix 系 os の場合は実行属性をつけることで直接実行することができます。

$ chmod 755 app.pyz
$ ./app.pyz

Windows の場合そのまま実行することはできませんが、pyz 専用の exe を作る方法が zipapp のマニュアルで紹介されています。


●(3) pyz の起動用に exe を作る

zipapp --- Manage executable Python zip archives

上記ページに載っている zastub.c をそのままコンパイルします。

// zastub.c
#define Py_LIMITED_API 1
#include "Python.h"

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

#ifdef WINDOWS
int WINAPI wWinMain(
    HINSTANCE hInstance,      /* handle to current instance */
    HINSTANCE hPrevInstance,  /* handle to previous instance */
    LPWSTR lpCmdLine,         /* pointer to command line */
    int nCmdShow              /* show state of window */
)
#else
int wmain()
#endif
{
    wchar_t **myargv = _alloca((__argc + 1) * sizeof(wchar_t*));
    myargv[0] = __wargv[0];
    memcpy(myargv + 1, __wargv, __argc * sizeof(wchar_t *));
    return Py_Main(__argc+1, myargv);
}

コンパイル方法もマニュアル通りです。下記のコードを実行してコンパイルできます。

# compile.py
from distutils.ccompiler import new_compiler
import distutils.sysconfig
import sys
import os
from pathlib import Path

def compile(src):
    src = Path(src)
    cc = new_compiler()
    exe = src.stem
    cc.add_include_dir(distutils.sysconfig.get_python_inc())
    cc.add_library_dir(os.path.join(sys.base_exec_prefix, 'libs'))
    # First the CLI executable
    objs = cc.compile([str(src)])
    cc.link_executable(objs, exe)
    # Now the GUI executable
    #cc.define_macro('WINDOWS')
    #objs = cc.compile([str(src)])
    #cc.link_executable(objs, exe + 'w')

if __name__ == "__main__":
    compile("zastub.c")

zastub.exe が作られるので、(2) で作った pyz とそのまま合成します。単純につなげるだけです。

copy /b zastub.exe + app.pyz app.exe

これで pyz を実行可能な app.exe ができました。そのまま実行できます。(python3.dll が必要)

app.exe

プログラムの内容によっては python の import でモジュールが見つからない場合があるかもしれません。その場合は予め検索パス設定しておいてください。環境変数 PYTHONPATH でも構いませんし、zastub.c の中で Py_SetPath() を使ってパスを与えることもできます。

zastub.c は python.exe 相当です。これが引数を何も加工していない状態になります。

int wmain()
{
    return  Py_Main( __argc, __wargv );
}

zastub.c では 1番目の引数に自分自身のパスを複製して挿入します。例えば引数が "arg1" なら「app.exe arg1」→ 「app.exe app.exe arg1」となります。自分自身である app.exe には app.pyz の内容がそのまま含まれているので、app.exe を pyz とみなしてそのまま実行できるわけです。

なお 1番目の引数を正しく渡すことができるなら、必ずしも exe に pyz を合成する必要がありません。例えば下のように直接 "app.pyz" を渡すことができます。

int wmain()
{
    wchar_t **myargv = _alloca((__argc + 1) * sizeof(wchar_t*));
    memcpy(myargv + 1, __wargv, __argc * sizeof(wchar_t *));
    myargv[0] = __wargv[0];
    myargv[1] = L"app.pyz";
    return Py_Main(__argc+1, myargv);
}

ただし若干問題もあります。上のコードはカレントディレクトリでなければ app.pyz を読み込むことができません。例えば他のフォルダからフルパスで app.exe を実行しようとすると app.pyz が見つからずにエラーになります。もし app.pyz を実行ファイルと同じ場所に置くなら、__wargv[0] や GetModuleFileNameW() を利用して app.pyz のパスを求めることができます。

↓ __wargv[0] から app.pyz のパスを求める。

#define Py_LIMITED_API 1
#include    <Python.h>

#define WIN32_LEAN_AND_MEAN
#include    <windows.h>

#ifdef WINDOWS
int WINAPI wWinMain(
    HINSTANCE hInstance,      /* handle to current instance */
    HINSTANCE hPrevInstance,  /* handle to previous instance */
    LPWSTR lpCmdLine,         /* pointer to command line */
    int nCmdShow              /* show state of window */
)
#else
int wmain()
#endif
{
    wchar_t *PYZ_NAME= L"app.pyz";      
    size_t  NAME_LENGTH= wcslen( PYZ_NAME ) + 1;
    size_t  length= wcslen( __wargv[0] ) + NAME_LENGTH;
    wchar_t *pyz_path= _alloca( (length + 2) * sizeof(wchar_t) );
    wcscpy_s( pyz_path, length, __wargv[0] );

    wchar_t **myargv = _alloca((__argc + 1) * sizeof(wchar_t*));
    myargv[0] = __wargv[0];
    memcpy(myargv + 1, __wargv, __argc * sizeof(wchar_t *));

    wchar_t *eptr= pyz_path;
    for( wchar_t *ptr= pyz_path ; *ptr ; ptr++ ){
        if( *ptr == L'/' || *ptr == L'\\' ){
            eptr= ptr + 1;
        }
    }
    wcscpy_s( eptr, NAME_LENGTH, PYZ_NAME );

    myargv[1]= pyz_path;
    return Py_Main(__argc+1, myargv);
}

同じようにして exe の場所からライブラリの位置を特定し、Py_SetPath() することもできます。例えば embeddable 版を使うなら、Py_SetPath() に python3x.zip と dll/pyd フォルダの 2つを与えれば OK です。


2019/03/02
VR HMD の分類表

VR
oga at 23:14
VR 機器の種類が増えたのでわかっている範囲で大まかに分類してみました。

(1) 頭 ポジショントラッキングあり 回転のみ
(2) 手 ポジショントラッキングあり 回転のみ
(3) 外部に PC (PS4) が必要 スタンドアロン (Mobile SoC)
(4) 外部センサーあり 外部にセンサーを設置する必要なし
Oculus Rift Quest Go
HTC Vive Vive/Pro (*1) Cosmos Focus Plus Focus
Sony PSVR
Samsung Odyssey GearVR
MS Windows MR
Google Mirage Solo Daydream


(1)/(2) ポジショントラッキングがあるかどうか

VR 空間を自由に歩く Room Scale に対応するにはポジショントラッキングが必要です。外部にトラッキング用のセンサー設置が必要なタイプと、内蔵のカメラだけでトラッキングできるインサイドアウト方式の 2種類があります。


(3) PC が必要かどうか

外部に PC が必要なタイプはモニタ相当です。ケーブルで Host PC (PS4) に接続する必要があります。性能が高く画質も良いですがプレイ中はケーブルがじゃまになりがち。

スタンドアロンタイプはケーブルが不要で PC と繋がなくても単体で使うことができます。手軽に使える半面、描画などの処理能力はスマートフォン相当になります。


(4) 外部にセンサーの設置が必要かどうか

「外部センサーあり」の場合は、トラッキングためにカメラなどのセンサーを部屋に設置しておく必要があります。HMD だけでなくセンサーのためのケーブルも必要で、事前の準備に少々手間がかかります。

(*1) HTC Vive / HTC Vive Pro は同じグループの中でも少々別格です。部屋にベースステーションの設置が必要ですが厳密にはセンサーではなく、どちらかといえばマーカーに近いものです。そのため PC とのケーブル接続が不要で、バックパック型 PC を使うとスタンドアロンタイプのようにも使えます。またポジショントラッキング対応のコントローラを 10個以上同時に利用することができます。手だけでなく足など全身のトラッキングも実現できます。


関連ページ
HMD VR / AR Device spec 一覧

関連エントリ
Gear VR のヘッドセットの種類のまとめ
各種 VR HMD と Volume 調節の仕方まとめ
VR で物が大きく見えたり小さく見えたりするわけ
Oculus Go は VR ができる新しい携帯ゲーム機
Oculus Go と VR デバイスの種類
Windows MR で Fallout 4 VR (Dell Visor)
Google Daydream View (2017) 新型
Windows Mixed Reality Dell Visor (VR HMD)
ASUS ZenFone AR (Daydream/Tango)
Gear VR Controller
HTC Vive のセットアップと PC スペック、遅い PC で動くかどうか
HTC Vive (VR ヘッドマウントディスプレイ) の接続


<<前のページ(日付が新しい方向) | 次のページ(日付が古い方向)>>