今日、インターネット上で彼らはただ雲について、彼らがどれほど無限で美しいかについて話します...彼らがそこで見たサーバーについて...そしてあなたは？ そこで、オンライン3Dおよびインテリアデザインサービスの開発における私の経験を読者と共有することにしました。 ここでは、プロジェクト全体のアーキテクチャと実装の詳細についてお話します。

3Dクラウドデザインシステムとは何ですか？ 「クラウドコンピューティング」という用語は最近非常に人気があり、インプレースでもアウトオブプレースでも使用されているため、定義から始めます。 私の理解と実装では、クラウド3D設計は、3Dモデルに関するすべてのデータとその処理手順がリモートサーバー（つまり、クラウド）に配置され、クライアントデバイスが特定のデータを要求するようなソフトウェアアーキテクチャですまたはインターネットでの計算結果。 言い換えると、このようなシステムは、クライアントデバイスではなくサーバーで決済操作の大部分を実行し、モデルとそのパラメーターを視覚化するためのデータのごく一部のみをクライアントに送信するという点で、従来の設計システムとは異なります。 このようなシステムのアーキテクチャは、密接に相互作用しますが、離れた場所にあるサーバーとクライアントの部分に分かれており、製品のユーザーには相互作用が見えないようにするための特別なアプローチが必要です。

次の質問は、そのようなアーキテクチャの利点は何ですか？ 間違いなく、クラウドアーキテクチャは、ユーザー、ユーザーのデータ、およびその処理が1か所に配置され、生成される従来のクラウドアーキテクチャよりも複雑です。 しかし、私のプロジェクトでは、クラウドアーキテクチャには開発と使用の両方の面で多くの否定できない利点があり、アプリケーションアーキテクチャのこのような複雑さを適切にしています。 私はそれらを定式化しようとします：

• クライアントアプリケーションはWebブラウザです。 現在、これはクロスプラットフォームアプリケーションと、あらゆるデバイスからサービスを使用する機能を意味します。
• インストールせずにアプリケーションをすばやく起動すると、将来のユーザーのしきい値が下がります。
• すべてのデータはすべてのデバイスから同時にアクセスできるため、ドキュメントを保存してデバイス間で移動する必要はありません。
• 複数のユーザーが個々のドキュメントとプロジェクト全体を同時に編集または表示する機能と便利な通信により、リモートにあるクライアント間で単一のワークスペースが作成されます。
• 継続的な開発プロセスの編成と更新の即時配信。これにより、顧客はソフトウェアの最新バージョンを使用でき、開発における極端なプログラミング手法の積極的な使用を促進できます。

もちろん、このアプローチには欠点があります。 これらのうち、以下を区別します。

• アプリケーションを快適に使用するための優れたインターネットチャネルが必要です。
• ソフトウェアの複雑さ、そして結果として、開発の時間とコストの増加。
• ソフトウェアが機能するために必要なネットワークインフラストラクチャの展開とその後のサポートの必要性。

プロジェクトのアーキテクチャ

アーキテクチャを選択するとき、将来のスケーリングの可能性を考慮して、最も負荷のかかったパーツを簡単に並列化できるようにプロジェクトをパーツに分割しました。 計算では、CAD開発の既存の経験に基づいて次の仮定を使用し、プロトタイプを作成するときに改良しました。

家具付きの平均的なアパートメントをダウンロードするには、約25 MBの非圧縮のジオメトリデータと追加の属性（5 MBの圧縮）+ 10 MBのテクスチャが必要です。 0.2秒からのデータ生成時間 5秒まで （最も難しい場合）。 モデルのボリュームを300〜500万の三角形に制限する予定です。

ユーザーによるプランの設計とさまざまな製品の配置の作業中、1つの操作（製品の挿入と編集、プランの再生成）あたり平均100〜500 Kbの発信トラフィック。 サーバー上の各操作の平均実行時間は0.1〜0.5秒です。

ユーザーアクティビティは、1分間に1つのモデルを開くレベル、または1分間に5〜10の編集操作を実行するレベルです。

これに基づいて、1台のサーバーで100人以上のアクティブユーザーを保持することが問題になることが明らかになったため、異なるサーバーで幾何学的リクエストの処理を保証し、何らかの方法でそれらの間で3Dモデルを配布する必要があります。

開発ツールの選択において、最初はいくつかの制限に縛られていました。 まず、C3Dをジオメトリコアとして使用し、モデルを操作する際のジオメトリ計算の速度に対する高い要件により、サーバー側でのC ++の使用が事前に決定されました。 第二に、ブラウザでクライアント部分を起動すると、言語の選択がJavaScriptでのコンパイルをサポートする言語に絞り込まれます。

その結果、この段階では、プロジェクトは4つの独立した部分で構成されます。2つの内部（バックエンド）サービスと2つの外部Webアプリケーションです。 メインの内部サービスは、幾何学的モデリングと計算を担当します。 C3DおよびQt Coreライブラリを使用してC ++で記述されています。 ヘルパーサービスは、ファイル、ユーザーディレクトリ、およびテクスチャ処理の管理を担当します。 ASP.NET Coreで記述されています。 Webアプリケーションも同様に分割されます。 1つはモデリングを直接担当し、TypeScript + WebGLで記述されています。2つ目はプロジェクトとユーザーディレクトリを管理するためのユーザーインターフェイスを提供し、Angular 2 + TypeScriptと組み合わせて記述されています。 クライアント部分とサーバー部分の間の相互作用は、単純なHTTP要求を使用して行われます。 ルームのインタラクティブモデリングを担当する部分は、圧縮されたバイナリデータを送信するWebSocket接続を使用します。 サーバーサービス間のコードの重複を避けるために、HTTPプロトコルを介して必要な情報も交換します。

サーバー側

このプロジェクトの主なハイライトは、サーバーパーツとクライアントパーツの組み合わせです。これにより、幾何学モデリング、視覚化、モデル編集の履歴の保存が行われます。 プロジェクトのこの部分には、パフォーマンス、RAM消費、並列化、およびスケーラビリティの観点から高い要求が課されます。 幾何学的モデリング自体はかなり高価な計算タスクであり、多くのアクティブなユーザーからモデルを作成するという要求を満たすことはさらに複雑になります。 サーバー上で幾何学的モデリングタスクを実行するシステムの「心臓」として、C3D LabsのC3Dコアが選択されました。その理由は、以前の記事「Nuclear Technologies in CAD」[1]で説明しました。 複雑な3Dプロジェクトを管理する機能を実装するために、ゲーム開発者に人気のある階層ECS（エンティティコンポーネントシステム）に基づく独自の3Dモデルデータストレージシステムを開発しました。 モデルのツリー構造を表し、さまざまな要素（エンティティ）で構成されます。各要素には、幾何学的パラメーター、BREPシェル、三角グリッド、ユーザーデータなどの異なるデータセット（コンポーネント）があります。 システムが必要な要件を満たすために、その実装には多くの特徴的な機能があります。

モデルが読み込まれると、その構造のみが読み込まれ、そのすべてのデータ（コンポーネント）はNoSQLデータベースに格納され、コンポーネントにアクセスするときに自動的にRAMに読み込まれ、必要に応じて自動的にメモリからアンロードされます。 これにより、数千のモデルを同時に開いたサーバー上で、低RAMコストで作業できます。

他のエンティティのコンポーネントとの関係は、「エンティティID-コンポーネントのタイプ」のペアの形式でコンポーネント内に保存されます。 モデル要素をコピーする操作中に、すべての要素は古いIDから新しいIDと対称ハッシュ関数を使用したランダムな操作コードを受け取るため、エンティティ内のすべての変更されたIDを置き換える代わりに、古いIDを新しいIDに変換するコードが記憶されます。 これにより、モデル構造の参照整合性を失うことなく、シンプルで高速なバイトコピーでコンポーネントデータをコピーできます。 その結果、コンポーネントの構造を読み取らずに巨大なモデルをコピーできます。これにより、設計された部屋内の大きなアセンブリを即座にコピーできます。

前のメカニズムのおかげで、特別なトランザクションコンポーネントが実装されます。このコンポーネントでは、さまざまなチームがコンテンツを編集している間、モデルの構造の変更の履歴が自動的に保存されます。 エンティティを比較的小さなコンポーネントに分割することにより、各コンポーネントへの呼び出しに「リスナー」を配置し、その変更を自動的に追跡することができました。 これにより、モデル変更の履歴全体を保存し、何ヶ月も前に作成した時点に戻すことができます（履歴全体は、必要なくRAMにロードされないコンポーネントにも保存されるため）。 開発者の観点から見ると、これは、幾何モデルにDBMSに存在するトランザクションに類似したトランザクションの類似性があることを意味します。

モデルの各要素とコンポーネントのバージョン管理により、サーバー上のバージョンと同期させるためにクライアントモデルで調整する必要があるエンティティとコンポーネントに関する情報を含む特別なパッチファイルが迅速に作成されます。 これにより、WebSocketプロトコルのバイナリバージョンを使用して、接続されているすべてのクライアント上のモデルデータをリアルタイムで効果的に同期できます。

実際には、このようなシステムは非常に迅速に動作し、モデルへのほとんどのクエリの処理時間を5〜50ミリ秒以内に提供します。 ただし、システムにはボトルネックがあります：モデルを開くには、すべてのデータを転送して視覚化する必要があります。大規模なモデルの場合、これらのコンポーネントを抽出するためにデータベースを頻繁に呼び出す必要があり、数万要素のモデルで数秒に達する大きな遅延につながります。 Redisでのパッチファイルのキャッシュにより、この問題を克服できました。 パッチは関連性を失わないため（バージョン0からバージョン100のパッチ+バージョン100からバージョン200のパッチは、バージョン0からバージョン200の単一のパッチと同等です）、キャッシュの無効化の問題を簡単に解決します：心配することなくバックグラウンドで更新できますデータの関連性の損失。

クライアント部

クライアント部分の設計は、視覚化のためのエンジンの選択から始まりました。 ほぼすべての人気のあるWebGLエンジンが試されましたが、次の理由により、それらのどれにもこだわることはできませんでした。

• 目に見えない線の削除や曲面のシルエットの描画など、CAD視覚化モードの弱いサポート。
• 任意の太さの線の描画と組み合わせた、3Dモードでの小さいサイズのテキストの高品質出力のためのツールの弱い開発（この組み合わせは、3Dモデルで計画を描画するために必要です）
• 効果的なバッチ技術の欠如。 モデルは多くの場合、さまざまな素材の何万もの小さな要素で構成されており、ユーザーはいつでもオブジェクトを変更できます。そのため、パフォーマンスの許容レベルを達成するには、ビデオメモリ内の大きな頂点バッファーに小さなオブジェクトを動的に接着する効果的な手法が必要です。
• 特定のカメラ制御コンポーネント、オーバーレイマテリアル、アニメーションを記述する必要性 提案された「ボックス化」オプションは、設計システムのニーズに適合しません。

分析の結果、「自転車」を書く方がより速く、より良く、はるかに簡単にサポートできるという理解が得られました。 壮大なライブラリhttps://twgljs.orgが基礎として選ばれました

次に、WebGLでフロアプランと3Dビューを描画する例を示します。

次の質問は、プログラミング言語とプラットフォーム全体の選択です。 私はすでに、約1万行のサイズのJavaScriptアプリケーションを開発した経験があります。 この経験に基づいて、JavaScriptで何かをより個人的に開発するというアイデアは、a敬の念を抱かせてくれました。 次のTypeScriptリリースと、Anders Halesbergがその背後にあるという事実により、言語の選択が事前に決定されました。 Web用のプラットフォームの選択は、Angular 2（現在は4）にかかっていました：私はかなりの数の多様なライブラリからプロジェクトを組み立てる必要があり、Webアプリケーション用に独自のコンバインハーベスターを構築することを少しも望みませんでした。 「包括的」なフレームワークがまさに必要でした。 システムモジュールの遅延ロード、効率的なコード生成（AOT）、および国際化機能の開発された機能は、私の選択を強化しただけです。 現時点でまだ私を混乱させている唯一のことは、ソースファイル内のメッセージのローカライズの欠如ですが、第4バージョンまでにこの機能を実装することを心から願っています）

アイデアの実装

このプロジェクトは、OpenGLでの将来のモデルの構造と実験的な視覚化のプロトタイプのC ++での実装から始まりました。 数か月のデバッグの後、アプリケーションをクライアントサーバーモデルに変換し始めました。 最初に、次のようにこれを行いました。C＃でRESTとWebSocketを組み合わせたサーバーを作成し、ジオメトリックサービスを、ジオメトリックリクエストに対して呼び出されるモデルを操作するためのCインターフェイスを持つダイナミックライブラリとして接続しました。 C ++からCにデータをコピーし、次にC＃にデータをコピーする際に、このようなハイブリッドアプリケーションと不要なオーバーレイをデバッグするという非常に不便なため、代替ソリューションを探す必要がありました。 最終的に、C ++パーツ内のWebSocketサーバーをオンにし、すべてのリクエストをプロキシサーバー経由でルーティングしました。 同時に、クライアントを認証するために、ジオメトリックサービスはメインRESTサービスに対して内部リクエストを行います。

次のステップは、モデルの同期アルゴリズムの実装でした。これは、サーバー上で変更され、クライアント上にモデルが表示されます。 サーバーによってサーバーの状態を監視したり、同期の前にクライアントに現在の状態をサーバーに送信したりする最初のアイデアは、信頼性が低く、実装が困難であるとして却下する必要がありました。 次の実装に焦点を当てました。各コンポーネントは、コンポーネントの整数バージョンを格納します。 したがって、モデル全体のバージョンは、そのすべてのコンポーネントと子エンティティのコンポーネントの最大バージョンによって決定されます。 同期中、クライアントはモデルのバージョンを含む要求をサーバーに送信し、それに応答して、サーバーはクライアントバージョンより古いバージョンのすべてのコンポーネントのデータを送信します。 これにより、最小限のトラフィックでクライアントとサーバー間のツリーモデルの同期が保証されました（同期要求は1つの番号であり、応答には変更されたコンポーネントのみが含まれます）。

クライアントとサーバーのパーツのプロトタイプを作成した後、クライアントとサーバー間で幾何モデルを転送するための最適なデータ形式の検索を開始しました。 この形式では、次の機能が必要でした。

• C ++コードとTypeScriptコードの両方からの簡単な形式の読み書き
• データスキーマのサポート
• データをパックおよびアンパックするための最短時間
• 精度を失うことのない浮動小数点転送
• 100Kb〜10Mbの範囲の平均データパケットサイズでの効率
• 将来の利便性のためのバージョンバージョンと、システムのさまざまな部分の段階的な更新の可能性

実験で使用したJSONはすぐに削除する必要があり、その後、MessagePack、Google Protocol Buffers、Apache Thrift、BSON、および同様のライブラリから選択する必要がありました。 パフォーマンスの向上、圧縮率の向上、便利なコードジェネレーターのため、Google Protocol Buffersを選択しました。 重要な要因は、図書館の普及と、長期的に見捨てられないという希望でした。 その結果、私はC ++でネイティブprotobufを使用し、クライアントで読み書きするprotobufjs、proto2typescript-C ++とTypeScriptの間で単一のスキームを使用します。 さらに、WebSocketsを介して送信される場合、データはzlibによってさらに圧縮されます。 このスキームにより、モデルに従って必要なすべてのデータを非常に快適かつ迅速に転送できました。

PS：最近、同じ開発者のFlatBuffersライブラリを見つけました。このオプションの方がもっと良いと思っていましたが、このライブラリを試してみる十分な時間がありませんでした。さらに、メインブランチではTypeScriptサポートがまだ利用できません。

データ形式を落ち着かせ、システムの各部分で最初の実験を行った後、サービス全体がどのように機能するかがほぼ明らかになりました。 さらに、ボトルネックが評価され、将来のスケーリングオプションがスケッチされました。 次に、プログラムの最初のバージョンが作成され、「ユーザーアクション-シミュレーションサーバーへの要求-ユーザーアクションの視覚化」リンクの操作が示されました。 この段階で、最初の失望が訪れました。このような作業スキームは、「マーカーを引っ張り、マウスを放し、オブジェクトが再構築された」スタイルでデータを更新することを提供します。 カーソルを移動するときに、ユーザーのアクションをインタラクティブに表示するには遅すぎました。

この結果は、サーバーとクライアント部分の境界を再考し、クライアントをより大規模にすること、およびクライアントがインタラクティブなポリゴン視覚化の予備計算を実行し、サーバーがBREPモデルで最終アクションを実行し、すべてのクライアントを同期するように、サーバーとクライアント間の機能を複製することを必要としました自分で。 これにより、WebAssemblyプロジェクトについて深く考えるようになりました。理論的には、クライアントとサーバーの部分に単一のコードベースを持ち、クライアントとサーバー間の計算の実行を迅速に管理し、必要に応じて負荷を分散できます。 しかし、今のところ、それはすべて夢です...

次のステップは、完全なWebGLレンダリングの実装でした。 ただし、その機能はかなり控えめですが、かなり汗をかかなければなりませんでした。 実装の主なポイントをリストします。

現在の段階では、従来のフォワードレンダリングとレンダリングにいくつかのパスを使用しています。 将来的には、Screen Space Ambient OcclusionまたはScalable Ambient Obscuranceに基づいてシェーディングを実装する予定です。

許容できるパフォーマンスを達成するために、グローバルオブジェクト座標系の小さな頂点バッファーに小さなオブジェクトを接着し、ビデオカードに送信します。 オブジェクトを変更すると、必要なすべてのバッファが再びプロセッサ上で再カウントされます。 ワイルドに見えるかもしれませんが、追加の属性でオブジェクトマトリックスを送信することはさらに複雑です。

1ピクセル以外の太さの3Dラインでの描画は、WebGLでは非常に重要です。 すべての頂点が同じ線上にあり、厚さが属性-接線ベクトルに格納されている2つの三角形の描画を通じて実装しました。 三角形の最終的な頂点は、ポイントを画面の座標系に変換し（画面の幅と高さの比率を考慮するため）、必要な線の太さを追加し、正規化された座標に変換することにより、頂点シェーダーで計算されます。 ラインスムージングは​​、フラグメントシェーダーのアルファチャネルを通じて実装されます。

テキストレンダリングは、Valveが公開したSDF技術を使用して行われました。 フォントを準備するために、libgdxのHieroユーティリティが使用されました。 私が得た結果は満足のいくものです。フォントサイズが14〜16ピクセルの場合、テキストはきれいに見えますが、サイズが小さく、テキストが画面の平面に対して鋭角である場合、ほとんど判読できません。 自衛隊の準備方法がわからないだけかもしれませんが、多くの時間を失い、結果を根本的に改善することはできませんでした。 将来的には、 この手法を試す予定です。

また、最新のブラウザーでのWebGLサポートは、OpenGL for Windowsと比較して優れていることにも注意してください。 これは明らかに、DirectXを介してWebGL呼び出しをエミュレートするAngleプロジェクトによるものです。 IE 11でも松葉杖のないコードは問題なく動作します。一方、複雑な構造を持つ大量のデータで動作するアプリケーションでは、対処が非常に難しいメモリリークという深刻な問題があります。

エピローグ

開発の次のステップは、プログラムの主題領域の実装でした-建物のモデリング、部屋とさまざまな構造要素のレイアウト、インテリアアイテムの配置、ユーザーカタログの作成。 もちろん、認証と認証、バックアップ、さまざまな部分のスケーリング、開発プロセス全体の継続的な統合という形で、Webサービスに関連する多くのことは注意と時間を必要とします。 これらの分野では、プロジェクトが一般に公開される前に、かなりの作業が行われています。 それにもかかわらず、実行された作業により、私は膨大な経験を積むことができました。 私の考えが読者の一部に役立つことを願っています。 誰かが経験があり、Webサービスを実装するためのヒントを共有する準備ができている場合、私はそれらを聞くことに非常に興味があります。 個人で書くか、ここにコメントを残してください。