Blend4Web対Unity。 リングでの戦い。 ラウンド2

次の「オウム」？！ あーいや 3つの実際のテスト、3つの異なる方向、さまざまなデバイス、興味深い事実。







Blend4WebとUnityを比較する最初の試みから1年が経ちました。 やや素朴な記事は、予想通りエンジンの支持者が正反対の側面をとるコメントの嵐を引き起こしました。 それ以来、多くの変更が行われました。UnityWebGLはベータ版ではなくなり、Blend4Webは成熟し、成熟しました。



ご理解のとおり、「インターネットの戦い」フィールドでBlend4WebとUnityを比較するトピックに戻ります。 エンジンの使いやすさや機能には興味がありません。 結果のみ、ハードコアのみ、Webブラウザーのみ。 「誰がクールか」というテーマでホリバーを繁殖させるつもりはありません。 実際のテストと実数。 いつでもデバイスをチェックしてコメントを購読解除できます。さあ、始めましょう...

試験準備

完全に異なるソフトウェアツールのテスト比較を行うことは非常に困難です。 多くのニュアンスを考慮し、オブジェクトの場所から最終的なエクスポートのパラメーターに至るまで、対称的なプロジェクトと設定を達成するよう試みる必要があります。



Blenderはベースシーンデザイナーとして選ばれましたが、これにはいくつかの理由があります。 まず、Unity はネイティブのBlenderファイルを完全にインポートします。 FBXのエクスポーターやエディターでのオブジェクトの手動インストールは不要です。 第二に、Blend4Webの場合、これがシーンを作成する唯一の方法です。



したがって、すべてのシーンとモデルは事前にBlenderで準備され、テクスチャが付けられ、エンジンに完全に専念しました。 場合によっては、空のダミーを使用して、ブレンドファイルでUnityを「認識」しないオブジェクトを微調整しました。 これらは光源であり、カメラです。



すべてのテクスチャ、マテリアル設定の機能（拡散、法線マップなど）は、プロジェクト間で実際にミラーリングされました。 いくつかの点については後で説明します。



また、基本的なツールとエンジン機能を使用して、環境、いくつかの風景効果、照明設定、影を作成しました。 私は両方のエンジンで同じシーンの完全な同一性認識を達成しようとしました。 確かに、これはどこでもうまくいきませんでした。あなたはいくつかの矛盾に気付くでしょう。



以下の項目が主な基準として選択されました。

• コールドブート時間 。 アドレスバーでのアクティブ化の瞬間から、テストシーンが表示されるまで。

これは、ブラウザアプリケーションにとって非常に重要です。 もちろん、サーバーの設定、アプリケーションの最適化、接続速度に大きく依存します。 このオプションを正しくテストするために、提案されたエクスポートオプションをデフォルトのままにすることにしました。 したがって、Unityはその場で解凍データを実行し、Blend4Webは開発者の肩を完全に「シフト」します。 テストサーバー自体は、圧縮せずにファイルを「そのまま」送信し​​ます。



一方では、UnityはすでにBlend4Webよりも明確な利点を持っているように見えますが、実際には、「落とし穴」もあります。

• ホットブート時間 。 ブラウザによって既にキャッシュされているファイルをエンジンが起動する速度。

データ転送などのあいまいな現象を結果から除外するために、この基準が考案されました。 コンテンツがブラウザキャッシュからロードされるようになりました。 ここで、エンジンがシーンを表示するのに必要なリアルタイムは興味深いものです。

• 1秒あたりのフレームレート（FPS） 。

これはすべてのプレイヤーのお気に入りのパラメーターであり、ゲーム開発者はそれほど遠くありません！ FPSカウンターがアプリケーションに追加されました。 このスクリプトは Unity に使用され、Blend4Webにはもともとこの機能がありました。



また、テストブラウザでは、60フレームという制限が強制的に無効にされました。 たとえば、Google Chromeは--disable-gpu-vsyncオプションで起動されました。 モバイルブラウザに関しては、既存の制限は特別な役割を果たしませんでした。 多くの結果は明らかに1秒あたり60フレーム未満でした。

• メモリ使用量 。 これは多くのWebGLエンジンにとって苦痛なトピックです。

ブラウザの安定した動作は、特定のタブのメモリ消費によって大きく決まります。 メモリを不注意に処理すると、ブラウザ自体がクラッシュする可能性があります。これは、ゲームやWebアプリケーションではまったく受け入れられません。 実際には、データはGoogle Chromeブラウザーの タスクマネージャーから取得されました（ショートカットキーSHIFT + ESC）。



デスクトップコンピューターから生産性の高いスマートフォンまで、さまざまなデバイスをテスト機器として使用しました（私には何もなかったので、友人に感謝します）。



テストでは、PC（Intel I5-3570、8RAM、画面解像度1680×1050のGTX 650）、Apple iPad 3、Motorolla Nexus 6、Samsung Galaxy S6 Edgeを使用しました。



非常に用途の広い機器...

テスト番号1。 「Hello World！」

伝統的に、プログラミングはHello Worldアプリケーションの作成から始まります。 最初のテストでは似たようなものを使用することにしましたが、ゲーム開発の現実にもう少し適応しました。



そのため、いくつかのクローンオブジェクトを持つ単純なシーン。 法線テクスチャは、法線マップによって強化されます。 2つの光源とシンプルなアニメーション。 テストはモバイルデバイスで実行されることになっているため、両方のエンジンでシーンを最適化するための対策が講じられました。







ご覧のとおり、ゲームのかなり標準的なシーンです。 ここには複雑なものはなく、両方のエンジンが問題なく「噛む」必要があります。 しかし、結果は予想とは少し異なりました。



基準「コールドブート」によるテスト結果







アプリケーションの読み込みが速いほど、パフォーマンスは向上します。 もちろん、ここではチャネル帯域幅が非常に重要です。 したがって、実数ではなく、相互の結果を検討する価値があります。 そして、ここで興味深い機能が明らかになりました-Unityでのアプリケーションのアセンブリは、Blend4Webからの類似のアプリケーションよりもはるかに遅くロードされ、Nexus 6デバイスでは、ブラウザータブが予期せず「ドロップ」します。



最終ダウンロード時間は、ブラウザの行が開始されてからシーン画面が表示されるまでカウントされることに注意してください。



「ホットブート」の基準によるテスト結果







2番目のテストは、ブラウザーキャッシュからアプリケーションを起動する速度を示しています。 読み取り値は、接続速度、サーバー設定、およびその他のパラメーターの影響を受けませんが、シーン自体をすばやく表示するためのエンジン自体の準備状態のみが特徴付けられます。 そしてここでは、Blend4Webは異なるデバイスでほとんど同じようにすぐに起動しますが、Unityについては言えません。



Unityアプリケーションのダウンロード速度の結果を2つのテーブルで比較すると、非常に興味深い画像が現れます-コールドスタートとホットスタートの時間差はごくわずかです。



ここでは、WebGLの初期化とコンテンツの読み込みの機能がトリックを演じているように見えます。 ハブに関するこの記事では、すべてが著しく描かれています。



また、Unityがスプラッシュスクリーンをデモンストレーションするのにかかる時間を考慮する必要があります。 これは、私が持っている標準バージョンの無効化しないオプションです。 もちろん、エンジンの有料版では、スプラッシュスクリーンの運命を自分で決めることができます。



FPSテスト結果







最初に目を引くのは、コンピューターとモバイルデバイスのFPS読み取り値の急激な違いです。 iPad 3は毎秒より多くのフレームを生成できる可能性があります（少なくともBlend4Webの場合）が、モバイルブラウザーのFPS制限を無効にする方法を見つけることができませんでした。 ただし、目にとっては、30ユニットの画面更新は非常に快適に見えます。



興味深いことに、Galaxy S6デバイスでは、両方のエンジンのパフォーマンスは同等でしたが、iPad 3ではUnityが「テール」のままでした。 もちろん、UnityアプリケーションがMotorollaデバイスでのテストに完全に失敗したことは残念です。



「メモリ消費」の基準によるテスト結果







繰り返しますが、モバイルブラウザの特定のタブのメモリ消費量を正しく測定する方法を見つけることはできませんでした。 したがって、以降はデスクトップコンピューターから取得した読み取り値のみです。 理論的には、モバイルブラウザでも同じ値を使用する必要があります。



一般に、Unityアプリケーションのブラウザークラッシュを説明できる少し異なる画像が表示されると予想していました。 しかし、テストが示したように、少なくともこのシーンでは、メモリ消費量に大きな違いはありません。 さらに驚くべきことは、そのような原始的なシーンでブラウザがNexusでクラッシュしたという事実です。

テスト番号2。 「重砲」

2番目のテストは、キューブシーンの正反対です。 数百のオブジェクト、大きなスペース、数十のテクスチャ、影、100万を超える頂点。 これはおそらくデスクトップコンピューターのみです。 このテストがモバイルデバイスで実行されるとはまったく予想していませんでした！ 低電力デバイス専用の最適化は行われませんでした。







このシーンでの主な難点は、正確には両方のエンジンの外観の同期でした。 Blend4Webを使用すると、すべてが明確になります。モデルと地形がBlenderで作成され、水と環境の設定もそこで実行されました。 すべてがなんとかスムーズに進み、特別な問題はありませんでした。



Unityに問題がありました。 まず、組み込みの地形の使用を拒否しました。 木を植えてペイントするのは楽しいですが、このソリューションの力にもかかわらず、内部の地形は不必要に遅くなる可能性があります。 したがって、ランドスケープモデルと事前に配置されたオブジェクトを含むBlenderのシーンのみを使用しました。 この場合、ほとんど同一のシーンを実現することができました。



第二に、標準のUnityシェーダーは、両面マテリアルを使用する方法を知らず、木の葉が後ろから輝いています。 何らかの理由で「木の葉」のような組み込みシェーダーを使用する試みは失敗しました。 私はこれに対処せず、インターネット上で優れた仕事をする自作のシェーダーを見つけました。



しかし、テスト結果に移りましょう、そしてそれらは驚くべきものであることが判明しました！



「ダウンロード」基準によるテスト結果











まず、Unityアプリケーションを起動すると、Nexusデバイスのブラウザーが再びクラッシュします。 また、Unityからの非常に長い、途方もなく長いコンテンツのダウンロード。 興味深いことに、このエンジンの「コールド」と「ホット」の結果の一時的な違いは、一般に重要ではありません。 Unityはデモンストレーションのためにシーンを準備するのに素晴らしい時間を費やしているようです。



FPSテスト結果







このテストは、パフォーマンスに関して非常に興味深い結果を示しました。 まず、PCおよびGalaxyデバイスでのFPS読み取り値は、両方のエンジンで同じです。 ここではUnityもBlend4Webもあまり目立ちませんでした。 興味深いことに、異なるエンジンのシーンスケールを変更するときのFPSのダイナミクスはさまざまでした。 したがって、Unityの場合、カメラを島から取り外したときに最高値が得られました。 反対に、Blend4Webは最大近似で最良の結果を出しました。 明らかに、エンジンは異なる最適化アルゴリズムを使用します。 したがって、表には、エンジンに最も適した角度で​​可能な最大FPSが示されています。



Apple iPad 3の予期しないクラッシュについて...ご覧のとおり、このデバイスはNexusに追加されています。 標準的な「横たわる」バイクとは異なり、iPadは最後まで抵抗し、ステージ上ですでに飛行していました。 そのため、負荷を測定することはできましたが、残念ながら、Unityアプリケーションはここでは機能していませんでした。



「メモリ消費」の基準によるテスト結果







最初のテストでは、ほぼ同じ量のメモリが消費されました。 ここでは、2つのエンジンの動作の大きな違いが見えています。 明らかに、Blend4Webは内部シーンの最適化を実行できましたが、Unityは成功しませんでした。



シーンは複製されたオブジェクトを使用し、理想的にはインスタンスが機能するはずです。 おそらく、特定のパラメーターを調整すると結果が改善される可能性がありますが、エンジンは同じ条件に置かれ、Blenderで作成された同じシーンを使用します。



非常に困難なテスト、WebGLの最適化されていないシーン、低FPSですが、2つのエンジンのうちBlend4Webのみが完全に対処しました。

テスト番号3。 跳ねるボール

最初は、2つのシーンだけで停止することを考えていましたが、物理学については思い出しました。 はい、はい。 オブジェクトが計画とは異なる動作をするとき、私たちはすべて物理学を愛し、障害を乗り越えますが、多くの場合、それなしではできません。



3番目のテストは、GPUの使用に関して非常に簡単です。 ここで、プロセッサは基本的に「吹き飛ばす」必要があります。 数十個のボールで満たされた立方体の囲まれた空間。 オブジェクトはその軸を中心にゆっくりと回転し、ボールが移動、衝突、落下します。







技術面では、シーンの物理は単純なコライダー（球体、立方体）、剛体、トルクで表されます。 テストされたエンジンの両方のシーンは完全に同一であり、物理的なパラメーターの一部は同じです。



いつものように、シーンでの物理学のパフォーマンスには多少の努力が必要でした。 おそらく、問題が何であるかをすでに推測しているでしょう。



ボールは頑固にケージを離れようとし、国境からこぼれ落ちました。 これは両方のエンジンに適用されます。 最終的に、すべてのオブジェクトが計画どおりに動作したときに、PCプラットフォームで許容できる品質の作業が見つかりましたが、モバイルデバイスでは、このシーンが時々ワイルドに見えました。 したがって、新しいテスト基準が導入されました-物理学の安定性、または私がそれを「アウトサイダーボール」と呼びました。 シーンは1分間動作し、セル内の残りのオブジェクトがチェックされました。 失われるほど、結果は悪化します。



そして今...



「ダウンロード」基準によるテスト結果











FPSテスト結果







Blend4Webシーンの同じFPSに注意してください。 エンジンが60よりもはるかに多くのFPSを生成できると仮定するのは論理的です。これは垂直同期によって制限されます。 実際、Blend4Webは物理を別のストリーム （ワーカー）で処理できます。 私の知る限り、Unityはこれに対応できません。 これはFPSが非常に高い場所であり、後で見るように、「安定性」の基準による良い結果です。



基準「物理の安定性」によるテスト結果







前述のとおり、UnityおよびBlend4WebはPCプラットフォームで非常に優れたパフォーマンスを発揮しました。 すべてのボールが所定の位置に残った。



Galaxy S6（Blend4Web）はモバイルデバイスのリーダーであることが判明し、iPad 3（Blend4Web）は部外者になりました。 Unityプラットフォームは、PCプラットフォームを除き、この基準で失敗しました。



一般に、WebGLのUnityの物理学は非常に悪い印象を残しました。 シーンを読み込んだ後、画面は遅くなり、数秒後に待望のFPSが入りました。 もちろん、これはPCにのみ適用されます。モバイルデバイスについては何も言うことがないため、すべてがテーブルにあります。



Unityの場合のこのようなひどい物理的挙動に対する答えは、次のメモリテスト結果にある可能性があります。



「メモリ消費」の基準によるテスト結果







最初の2つと比較して、3番目のシーンはメモリ使用量の点で最も食いしん坊でした。 そして、これは両方のエンジンに適用されます。



Unityアプリケーションの動作は非常に奇妙でした。 シーンのローンチ後、メモリ消費量は700 mbに跳ね上がり、数秒後には400に減少しました。この間、低電力モバイルデバイスはすでにすべてのボールを失っていることは明らかです。 したがって、デバイスのこの部分のFPSデータは正しくありません。すでに空のキューブがオブジェクトなしで画面上で回転しているためです。



この振る舞いを説明する方法はわかりませんが、Unity WebGLの物理学が最高の状態であるとは証明されていません。

結論...

結論はあなたをします。 結果は記事にあり、以下にテストアプリケーションへのリンクがありますが、私はまだ自分からいくつかの言葉を追加します。



3つの異なるシーンが作成され、さまざまなデバイス、ブラウザー、システムでテストされました。 ほとんどの場合、Blend4Webの結果はUnityの結果よりもはるかに優れていました。 Blend4WebはWebGLアプリケーションを作成するためのフレームワークとして作成されたため、これは正しいです。 メモリ消費量が少なく、起動するシーンをすばやく準備できるため、デバイスに関係なくかなり高いFPSを実現できます。 また、このフレームワークは、ツールと機能の点で非常にきれいです。 パフォーマンスが大幅に向上しました。



Unity WebGLは完全に失望しました。 モバイルデバイスでの完全な動作不能。 非常に長時間の起動（スプラッシュスクリーンのデモを時間から除外しても）。 弱いデバイス上の物理の不安定性。 そして、はい、同じ遅いコンパイル！ エンジンの開発者は、1年にわたって実際には何もせず、最も単純なシーンに適した単純なスタブを作成したようです。



テストシーンへのリンク：



» テスト番号1。 Hello World！（Unity）

» テスト番号1。 「Hello World！」（Blend4Web）



「 テスト番号2。 重砲（Unity）

「 テスト番号2。 重砲（Blend4Web）



» テスト番号3。 跳ねるボール（Unity）

» テスト番号3。 跳ねるボール（Blend4Web）



注意！ Unityアプリケーションテストへのリンクは機能しており、ブートローダーは表示されません。 Unityのダウンロードははるかに遅いことに注意してください。



更新する

テストのソース 。



アップデート＃2（10/10/2016）

エンジンの新しいバージョンのリリースを考慮して、プロジェクトが再構築されました。 影がシーン1に追加されました。 両方のエンジンのパフォーマンスはほぼ等しく低下しました（PC）。 モバイルの場合、B4WのFPSはわずかに増加し、Unityは変わりません。 したがって、テーブルをやり直してもあまり意味がありません。



また、元はBlend4Webに存在していたmeta name = "viewport" ...タグがUNITYプロジェクトのHTMLファイルに追加されました。 この矛盾に気づいた人に感謝します！



シーン2がソースに追加されました。