ホイール欲しいハンドル欲しい

2019/03/24
UE4 UnrealBuildTool *.Build.cs のコードを共有する

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 からも参照できます。これでメンテしやすくなりすっきりしました。

2019/03/09
Python : zip にアーカイブした pyz を直接実行できる専用 exe を作る

プログラム全般

oga at 22:07

実行ファイルの置き換えに 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 の分類表

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 ヘッドマウントディスプレイ) の接続

Su	Mo	Tu	We	Th	Fr	Sa
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

ホイール欲しいハンドル欲しい

Archives

2019/03/24
UE4 UnrealBuildTool *.Build.cs のコードを共有する

2019/03/09
Python : zip にアーカイブした pyz を直接実行できる専用 exe を作る

2019/03/02
VR HMD の分類表

Sidebar

ホイール欲しい ハンドル欲しい

Archives

2019/03/24 UE4 UnrealBuildTool *.Build.cs のコードを共有する

2019/03/09 Python : zip にアーカイブした pyz を直接実行できる専用 exe を作る

2019/03/02 VR HMD の分類表

Sidebar

ホイール欲しいハンドル欲しい

2019/03/24
UE4 UnrealBuildTool *.Build.cs のコードを共有する

2019/03/09
Python : zip にアーカイブした pyz を直接実行できる専用 exe を作る

2019/03/02
VR HMD の分類表