ObjectDeliverer Ver 1.4.0 数日前の話ですがObjectDelivererの新バージョンをリリースしました。 （ブログ書こうと思って忘れてた） ObjectDeliverer：ayumax：Code Plugins - UE4 マーケットプレイス 送信元IPアドレスの取得機能追加 通信プロトコルをTCP/IP Server もしくはUDP Receiverにしている場合にのみ使用可能な機能です。 これら2つの通信プロトコルでは、送信元が複数のIPアドレスの可能性があります。 ただし以前のバージョンまではどこからの送信だったのかを知るすべがありませんでした。 （TCP/IP Serverには厳密には送信元を区別して認識する機能はありましたが、IPアドレスを知る機能はありませんでした） これはObjectDelivererの設計思想の「異なる通信プロトコルを同じように切り替えて使える」を実現するために、あまり個別のプロトコルに特化した機能は入れたくなかったというのがあります。 ただ現実的にないと困ることもあり、今回実装しました。 以下仕様例です。 ReceiveDataイベントのClientSocketオブジェクトをGetIPV4Infoインターフェイスを通して使うことで情報の取得ができます。 今回追加したGetIPV4InfoインターフェイスにはIPアドレスをuint8の要素数4の配列で取得するGetIPAddressと"...“の文字列形式で取得するGetIPAddressinStringがあります。 対応している通信プロトコル以外ではReceiveDataイベントのClientSocketオブジェクトがGetIPV4Infoインターフェイスを実装していないため、インターフェイスへのキャストで失敗します。 今後もなるべく同じように使えるというコンセプトは崩したくないですが、個別プロトコル固有の機能はインターフェイス経由で使えるようにしていこうと思います。

.NET Conf 2019 meetup in AICHI 10/5に行われた “.NET Conf 2019” のローカルイベントです。 今回はそれに参加してLTさせて頂いてきました。 発表内容 今回は.NET Core 3.0のイベントのため、Core 3に絡んだ内容の方がいいよねっと思い、.NET Core 3.0で追加されたWPFについてお話させていただきました。 今回発表した内容の資料は以下になります。 Net core3.0とWPF from AyumaKaminosono www.slideshare.net あと当日の発表内容を動画にしていただけました。 @kekyo2さんありがとうございます。 www.youtube.com 自分の発表の反省をしようと思い、公開していただいた動画を見てみたのですが、自分のしゃべっている動画を見るのってメチャクチャ恥ずかしいですね！！ あまりの恥ずかしさにまだ全部見れていません。 また後日気持ちを整えて見たいと思います。 テーマ選定について 自分はそこまで.NETの深いところの話ができるほど知識がないので、言語仕様などを語るよりは実践した体験を展開するような方式にしようと思ってました。 それでどうしようかと考えていて、今年のゴールデンウィーク当たりに.NET Core 3のプレビューを使ってWPFを試していたのを思い出し、ちょうどいい発表材料になるな！と思いテーマはWPFにしました。 {{< x user=“ayuma_x” id=“1125397415937208321” >}} そこでこのテーマで話す内容をまずは箇条書きで書き出してみて、資料作成の土台を作っていきました。 そうするとある1つの重大なことに気づきました。 面白くない。。。 今回.NET Core 3.0でWPFが使えるようになった事をツラツラと書いてみたのですが、中身が薄く面白くありません。 ここで「テーマまずかったかな？？」、「同時に試してたC#8の話の方が書くことあるかな？？」と悩んだのですが、やはり普段から使っているWPFの方がなんかあった時も答えられるしここは崩さず行こうと決めました。 そこでWPF固有の話ではないですが、関連度が高そうなRuntimeをアプリケーションに含められる話や単一実行ファイルを作成できる話を追加して、あとその様子を動画にして実際にどんな感じで動くのかを見てもらえる構成にしました。 全部書いてみて、発表の練習を数回してみたところ、だいたい13～14分くらいになったのでこれで行くことにしました。 まだ少し内容薄いような気もしたけど、今更追加できんし腹をくくろうと。 （イベント終了してから数日経った今ならもう少しCore3 + WPFでネタができました。まあそんなもんです） 発表当日 自分の順番は終盤で、それまでは他の登壇される方の話を興味深く聞かせていただきました。 @kekyo2さんの非同期の話は、ちょうどこの日のちょっと前に昔書いたコードのTask.Wait撲滅活動をしていたこともあり個人的にHitしました。 非同期イテレーター凄く関心があるので、是非近いうちに書いてみよーっと。 私は発表は昨年のLTに続き2回目だったのですが、今日は前回よりは気持ち的に落ち着いていて「今日はテンパらないかなー」と楽観視してました。 ところが自分の番はちょうど休憩後で少し待ち時間があり、PCの準備をして時間まで待っていると段々緊張してきてお腹痛くなってきましたwww でも今日は「早口にならずゆっくりしゃべる」「聞いてくれる人の顔を見て話す」というのを目標にしていたのでそれだけは守れるように、なるべく落ち着いてちょっとずつしゃべりました。 ...

デルアンバサダープログラムに当選した 先日Twitterを見ていたらデルアンバサダープログラムでノートPCを借りてレビューしている人をみて、試しに自分も登録して応募してみました。 そうすると、なんと当選してしまいXPS 15 2-in-1をお借りする機会をもらったためレビューさせていただきます。 XPS 15 2-in-1をお絵かきなどで使っているレビューはきっと他のかたがたくさんしていると思うので、私はソフトウェア開発者目線でレビューしてみたいと思います。 主に今使っているDELL ALIENWARE13 R3と比較して感想を書きたいと思います。 サイズの比較 ALIENWARE13とサイズを比較してみました。 ALIENWAREは13インチとしては大きいほうなのもあり、ほとんどサイズ的には同じくらいですね。 それだけXPSは15インチとしてはスリムにできているのだと思います。 またディスプレイもベゼルレスでとても大きく感じ見やすいです。 また個人的には持ち運び時にはACアダプタも持っていくので、アダプタの大きさ重さも気になります。 ところがアダプタはXPSの方が断然小さく、重さも軽いです。 ALIENWAREはGeForce 1060積んでいるのでしょうがないんですけどね。 アダプタのコネクタがUSB-TypeCなのも、互換性が高くてよいですね。 勉強会などで外にノートを持っていく機会も多いので、この持ち運びの良さは凄いメリットだなあと感じました。 スペック 入っているOSはWindows10のHomeで、CPUはCore i7-8705G, メモリは16GBです。 効いたことないCPUの型番だなあと思って調べたら、 Radeon™ RX Vega M GL とくっついてるCPUなんですね。 インテル HD グラフィックスよりもハイパワーなGPUが使えるという事で、凄い期待が高まります。 ディスプレイは4Kで鮮やかな色です。 今使っているALIENWAREはFullHDの13inchですので、やはり大きく感じますね。 あと4Kなので小さい文字もくっきり読めていい感じです。 スケール100%で使うと文字が小さすぎるので、175%で使ってみました。 Unreal Engineを使ってみる Unreal Engine(UE4)はゲームをつくることのできるゲームエンジンなのですが、これを使った開発には結構マシンパワーが必要です。 外部GPUを使ってないノートだと、初期状態で立ち上げただけで重くてカクついてしまうのでXPSではどうなるかなと思って確認してみました。 結果UE4のEditorはあっさりと立ち上がり、初期状態でPlayしたところフレームレートも90fps程度でています。 2018年モデルのMacBookAirでは20fpsくらいだったので、それよりも全然快適です。 これは外に持って行ってちょっとした修正程度なら全然使えるなと思いました。 Radeon™ RX Vega M GLはスペックを見ると、自分のALIENWAREのGeForce 1060よりもだいぶ処理能力は低いような印象を持ちましたが実際に使ってみると意外に頑張るなと、良い意味で期待を裏切られました。 ただしマシンの処理的には結構頑張ることもありUE4を立ち上げるとファンが高速に回転しだし、音も結構聞こえます。 Visual Studioを使ってみる 続いてVisual Studioを使ってみました。 自分の公開しているUE4向けのC++ プラグインのコードを書いてみましたが、これはCPUも結構早いのを積んでいるので特にストレスなく書けました。 また画面が広いのでVisual Studioの使い勝手は13inchのALIENWAREよりも圧倒的に良いです。やはりコードを書くのは広い画面の方がよいですね。 1点だけ個人的に残念だったのはキーボードです。 これは個人的な好みかもしれませんが、カチャカチャしたキーボードは安っぽく感じてしまい好きになれませんでした。 ALIENWAREみたいな打ちごごちだったら、完ぺきだったのになーと思いましたが筐体の厚みもかなり薄くできているのでしょうがないかもしれません。 まとめ 借りれていた期間は1か月程度ですが、あっという間に終わってしまいました。 XPSはその他のメーカーのノートと比較しても、見た目もスタイリッシュでカッコよく憧れていたので使う機会がもてて楽しかったです。 私はUE4の開発しているので、PCにGPUが絶対必須なのですがこれだとスリムなボディに関わらずそこそこ動くGPU積んでいるのでアリだなあと思いました。 ...

C#でスクリプトを書きたい 私はUE4のC++は好きです。マーケットプレイスにもいくつかC++プラグインを出してます。ですがC#もたくさん書いているので、時々C#だったらもっと楽に書けるのになあと思うことはあります。 そんな事を考えていて、ふと次のような書き込みをTwitterでしました。 {{< x user=“ayuma_x” id=“1165145950710484993” >}} すると@kekyo2さんからこんなお誘いがあり、今日実際に1日かけてトライしてきました。 IL2C 今回の主役となるツールは@kekyo2さんの作成されているIL2Cです。 IL2Cを用いるとC#をコンパイルしたILを含むDLLやEXEからC言語のソースコードが生成できます。( 凄い） これを使ってC#のコードをUE4のC++から呼んでみようというのが今日行った実験です。 開発環境 今回行った実験は以下の環境でおこなっています。 Visual Studio 2019 Unreal Engine4 Ver. 4.22 また、以下に今回行った手順を書いていきますが色々試行錯誤した結果のため、手順を見ただけでは何故それをやるのかわからない箇所もあるかと思います。 今回の試みはまだ実験段階のためご了承ください。 今回作成したプロジェクト一式は以下に置いてあります。(UE4, C#全部入ってます） C#プロジェクトの作成 まずC#のクラスライブラリのプロジェクトを作成します。今回は.NET Standardのクラスライブラリを選択しました。 次にプロジェクトファイル(*.csproj)のPropertyGroupにというタグを追加しtrueの値を記述します。 この記述は通常.cで出力されるファイルを.cppで出力します。 これはUE4でこの後ビルドを正常に通すために必要な設定です。 &lt;PropertyGroup> &lt;TargetFramework>netcoreapp2.1&lt;/TargetFramework> &lt;IL2CEnableCpp>true&lt;/IL2CEnableCpp> &lt;/PropertyGroup> 次にデフォルトで作成されているClass1.csに以下の記述を行います。 using System; namespace UE4Il2CSample { public class Class1 { public static int Add(int a, int b) => a + b; } } staticなメソッドを1個用意しました。 単純にint型の引数2つを足し算する関数です。 ...

UE4で作成したiOSアプリのパッケージの中身のディレクトリを、iOS標準のファイルアプリで確認するための方法です。 Project SettingsのiOSで以下の2つを実施します。 File System - Supports ITunes File Sharing チェックON Extra PList Data- Additional Plist Data 以下を入力 &lt;key>LSSupportsOpeningDocumentsInPlace&lt;/key>\n&lt;true/>\n 上記設定で作成したアプリをiOS端末に入れると、標準ファイルアプリの「このiPad内」からアプリの中身が確認できます。 この方法を使うと他のアプリからUE4で作成したアプリにファイルを渡せそうなので使い道がありそうです。

ARKitの物体検出(Object Detection) 物体検出機能はARKit2から利用可能になった機能で、あらかじめスキャンした物体のデータを登録しておくと作成したARアプリケーションから登録済みの物体を検出することができるようになります。 この機能についてはUnityを使った事例はいくつか記事になっているのですが、UE4を使った事例は見つかりませんでした。 今回どうしてもこの機能をUE4(4.22)で使いたくて、色々試し動かすことに成功したのでやり方をメモしておきます。 オブジェクトのスキャン まずは検出する物体のスキャンをします。 UE4を使ったスキャン UE4を使ってスキャンする場合は、まずARSessionConfigのSession Typeを「Object Scanning」にしてから、「Get AR Candidate Object」を使用して行うらしいです。 上で「らしい」という言葉を使ったのは理由があり、現状上記やり方ではスキャンは成功してないです。 「Get AR Candidate Object」をコールした際にアプリケーションが落ちてしまいスキャンはできませんでした。 成功した方がいらっしゃったら、教えてください。 Apple提供ツールを使ったスキャン 以下のサイトの上部にある「Download」ボタンを押すと、オブジェクトスキャンをするためのiOSアプリのプロジェクト一式がダウンロードできます。 Scanning and Detecting 3D Objects | Apple Developer Documentation ダウンロードしたプロジェクトをXCodeを使って、自分のiOS端末にいれて使用します。 使い方は結構直観的に分かり、最初に黄色いBoxで領域を確定した後、各面毎にスキャンを行います。 黄色いBoxの中に小さい黄色い点（多分物体の特徴点）がたくさんあったほうが後の検出率が高いような気がしています。 スキャンが終わると*.arobjectという拡張子のファイルが生成されるので、iCloudとかを利用して開発マシンまでファイルを持っていきます。 XCodeやUnityを利用したARアプリ開発の場合は上記方法で完結しており、*arobjectのファイルがそのまま利用できます。 UE4の場合はそのままは利用できず、ダウンロードしたスキャンアプリを一部書き換える必要があります。 ViewController.swiftのcreateAndShareReferenceObjectメソッド 変更前 try object.export(to: documentURL, previewImage: testRun.previewImage) 変更後 try NSKeyedArchiver.archivedData(withRootObject: object, requiringSecureCoding: false).write(to: documentURL) 上記書き換え部分はファイルを生成する部分なのですが、利用する関数が違います。 変更前はARReferenceObjectクラスのexportを使っているのですが、これをNSKeyedArchiverを使ってバイナリ化した後そのままファイルに書き込むように変えました。 またオリジナルと区別するためファイルの拡張子を(*.arobject2)に今回はしています。 これはUE4のARKitプラグインでバイナリを復元する際(FAppleARKitConversion::ToARReferenceObjectSet)に使われているのがNSKeyedUnarchiverだからです。 最初書き換えなしで*.arobjectのファイルを読み込ませたところ、ARReferenceObjectの復元に失敗したため調査したところ上記書き換えで成功するようになりました。 arobjectファイルにはUnityで読み込むと静止画のサムネイルが表示されていたので、そういった付加情報が*.arobjectには入っており後者のファイルとはバイナリに保存される内容が違うのが原因かなと思っています。 スキャンデータのUE4への取り込み ARCandidateObjectアセットの作成 スキャンして生成された*.arobject2ファイルをUE4に取り込みたいのですが、今回は専用のアセット生成クラス(UFactoryを継承したクラス)をC++で書きました。 ファイルの中身は以下になります。 ここで気を付ける点としては、上記C++クラスはEditorの機能を利用するため、UnrealEdモジュールへの参照追加の必要があります。 また自分のプロジェクトのRuntimeモジュールにいれてしまうとアプリの書き出し時にエラーがでるので、Editorモジュールにいれてください。 このモジュールについては以下のヒストリアさんのサイトが分かりやすいです。 [UE4] モジュールについて｜株式会社ヒストリア 上記ファイルをプロジェクトに追加してビルドすると*.arobject2ファイルをドラッグすることでファイルがインポートされてARCandidateObjectのデータアセットが作られます。 アセットを開くと「Candidate Object Data」の配列に大きな数字が入っているのが分かると思います。 ここに*.arobject2ファイルの中身がバイナリ形式で入っています。（配列を開くと数が多いのでとても重いです。開かないほうがいいと思います） ...

ObjectDeliverer Ver 1.3.0 本日ObjectDelivererの新バージョンをリリースしました。 ObjectDeliverer：ayumax：Code Plugins - UE4 マーケットプレイス 内容は以下の2点です。 iOS, Android, Macへの対応 UDPReceiverを使用した時にエディタ終了時まれにフリーズする不具合を修正 iOS, Android, Macへの対応 最近個人的にUE4でモバイルアプリの作成を開始したこともあり検証環境ができてきたので、モバイルOSの対応を実施しました。 ただ内部的なコードの変更は何もしておらず、各種OS向けにパッケージを作成したのみとなります。 もともとほとんどの仕組みをUE4のC++クラスのみを利用して作成していたため、今確認できる範囲では各種OSでもちゃんと動作が確認できています。 これによりスマホアプリとデスクトップアプリや、スマホアプリ同士での通信ができるようになるため、プラグインとしての使い勝手が今まで以上に広がると思っています。 UDPReceiverを使用した時にエディタ終了時まれにフリーズする不具合を修正 もう1点は不具合修正になります。 UDPの受信機能を使用している場合に、タイミングが悪いとエディタ終了時にフリーズしてしまう不具合があったため修正しました。 他のプラグインの対応 現状ObjectDeliverer以外のプラグインは全てWindowsのみの対応としていますが、今回の対応で対応方法が分かってきたので、他のプラグインも時期をみてモバイルOSの対応も実施したいと思っています。

WindowCapture2Dとは Unreal Engineで使えるWindow Captureのプラグインです。 Windowsの他のアプリケーションのWindowの表示を、自分のUE4プロジェクトのテクスチャとして扱うことができるようになります。 そのためメッシュに張り付けて3D空間に配置したり、UMG上のImageに張り付けることなんかができるようになります。 リアルタイムにスキャンしてテクスチャの中身を更新しているので、キャプチャー元のWindowの表示が更新されればテクスチャの表示も更新されます。 UE4のMedia PlayerとMedia Textureを使って動画を表示するのに近い使い勝手かと思います。 ブループリントOnlyのプロジェクトでも使用可能です。 詳しくは以前の記事を参照してください。 なぜ作ることにしたのか等書いています。 UE4でウィンドウキャプチャー機能を作ってみた - AYU MAX UE4 マーケットプレイス 以下のページにて公開しています。 WindowCapture2D：ayumax：Code Plugins - UE4 マーケットプレイス 価格はFreeです。 Engineのバージョンには4.22に対応しています。（近いうちに4.20と4.21にも対応させます） また、ソース一式も以下のGitHubにてMITライセンスで公開しています。 現状の機能とこれから 今(2019/7)のところウィンドウのキャプチャーのみ行えます。 今後はこれに操作機能(VRコントローラーなどでキャプチャーしたウィンドウを操作）を作ろうと考えています。 その他、今よりもパフォーマンスの改善や使い勝手の改善なども行っていく予定です。 特にキャプチャー対象のウィンドウの解像度が上がっていくと、処理負荷が高くなっていくのでその当たりが一番の課題かなと思っています。 こんな機能を追加してほしいなどのご要望ありましたら教えてください。

UE4のWorldの大きさ問題 最近作ってたコンテンツでおきた問題をメモしておきます。 そのコンテンツはWheeledVehicleを使って車を走らせていたのですが、最近走るエリアを大幅に広げてみました。 それでちゃんと動くかテストしたところ、10kmを超えたあたりで車が消滅してしまいました。。。。 エリアが広すぎるせいで処理が重くなったりするかなあという不安はもっていたのですが、急に車が消滅するのは想像していませんでした。 そこで色々調べたところ原因と解決策が分かりました。 WorldSettingsのEnable World Bounds Checks まず簡単にこの件を解決する方法としては、WorldSettingsのEnable World Bounds ChecksをOFFにすることです。 （色々検索しててみつけたのですが、元のページが見つからなくなってしまった。。。） この項目をOFFにするとたしかに10kmを超えても車は消滅しません。 なぜなのか？この項目は何に効いているのか？と疑問がでたのでもう少し調べてみました。 Editorでこの項目にマウスを合わせると以下の画像のようにツールチップがでます。 ん？CheckStillInWorldってなんだ？と思ってEngineのソースを検索してみると、AActor::CheckStillInWorld‘という関数が見つかりました。これは怪しい。 bool AActor::CheckStillInWorld() { if (IsPendingKill()) { return false; } UWorld* MyWorld = GetWorld(); if (!MyWorld) { return false; } // Only authority or non-networked actors should be destroyed, otherwise misprediction can destroy something the server is intending to keep alive. if (!(HasAuthority() || Role == ROLE_None)) { return true; } // check the variations of KillZ AWorldSettings* WorldSettings = MyWorld->GetWorldSettings( true ); if (!WorldSettings->bEnableWorldBoundsChecks) { return true; } if( GetActorLocation().Z &lt; WorldSettings->KillZ ) { UDamageType const* const DmgType = WorldSettings->KillZDamageType ? WorldSettings->KillZDamageType->GetDefaultObject&lt;UDamageType>() : GetDefault&lt;UDamageType>(); FellOutOfWorld(*DmgType); return false; } // Check if box has poked outside the world else if( ( RootComponent != nullptr ) &amp;&amp; ( GetRootComponent()->IsRegistered() == true ) ) { const FBox&amp; Box = GetRootComponent()->Bounds.GetBox(); if( Box.Min.X &lt; -HALF_WORLD_MAX || Box.Max.X > HALF_WORLD_MAX || Box.Min.Y &lt; -HALF_WORLD_MAX || Box.Max.Y > HALF_WORLD_MAX || Box.Min.Z &lt; -HALF_WORLD_MAX || Box.Max.Z > HALF_WORLD_MAX ) { UE_LOG(LogActor, Warning, TEXT("%s is outside the world bounds!"), *GetName()); OutsideWorldBounds(); // not safe to use physics or collision at this point SetActorEnableCollision(false); DisableComponentsSimulatePhysics(); return false; } } return true; } 関数の一番最後に答えが書いてありました。 ...

ObjectDelivererのVersion 1.2.1をリリース 今回はユーザーの方よりご指摘いただいた以下の不具合を修正しました。 UDPReceiverで既に使われているポートを指定するとEditorがクラッシュする InnerSocket = FUdpSocketBuilder(TEXT("ObjectDeliverer UdpSocket")) .WithReceiveBufferSize(1024 * 1024) .BoundToPort(BoundPort) .Build(); Receiver = new FUdpSocketReceiver(InnerSocket, FTimespan::FromMilliseconds(10), TEXT("UProtocolUdpSocketReceiver")); Receiver->OnDataReceived().BindUObject(this, &amp;UProtocolUdpSocketReceiver::UdpReceivedCallback); Receiver->Start(); if (InnerSocket) { DispatchConnected(this); } 上記が修正前のソースです。 BoundPortに既に使われているポート番号が指定されると、InnerSocketにはnullptrが入るためその後FUdpSocketReceiverを生成したタイミングでクラッシュしていました。 今回はこれを単純ですが以下のように修正しました。 InnerSocket = FUdpSocketBuilder(TEXT("ObjectDeliverer UdpSocket")) .WithReceiveBufferSize(1024 * 1024) .BoundToPort(BoundPort) .Build(); if (InnerSocket) { Receiver = new FUdpSocketReceiver(InnerSocket, FTimespan::FromMilliseconds(10), TEXT("UProtocolUdpSocketReceiver")); Receiver->OnDataReceived().BindUObject(this, &amp;UProtocolUdpSocketReceiver::UdpReceivedCallback); Receiver->Start(); DispatchConnected(this); } これでFUdpSocketBuilderでの初期化に失敗した場合でも、クラッシュすることはなくなりました。 この不具合を見つけて、同じような仕組みのTCP/IP Serverは大丈夫かと思いましたが、そちらはガードが既にかかっており大丈夫でした。 単純なミスをやらかしてしまい、お恥ずかしいです。