サーバサイドでの街と群衆のシムとリファレンシング
The city and crowd simulation with referencing on the server side
(株式会社ポリゴン・ピクチュアズ / スタジオフォンズ)
(Polygon Pictures Inc. / Studio Phones)
本資料は、会合前の問題意識の共有を目的に書かれています。今後の会合の状況を見つつ加筆修正を含めブラッシュアップを進めていく予定です。
This document is intended to raise awareness of certain issues in advance of an upcoming seminar discussion. We plan to continue making additions and corrections based on the situation at seminars hereafter.
translated by PPI Translation Team
■概要
■Overview
サーバサイドでリファレンシングとインスタンシングの仕組みを完備していく、サーバサイドでのプロシージャルモデリング環境を整備していく、スケールアウト系ストレージを有効活用し制作パイプラインを考えていく。この典型的利用例として、サーバサイドでの街と群衆のシムとリファレンシングというトピックスがあります。
少し想像してみて下さい。サーバ内でスタッフ全てが街をデザインしていく様子を。そこで生活し、そこでストーリーが展開されていくようにキャラクターが動作していく様子を。
アーティストが個別にデザインを進めたインテリアをどこに設置するかは不明なままストレージに抱えていく。それらが貯蓄されインテリアアセットライブラリとしてwebアクセス可能なカタログが完備される。アートディレクターは、ここにはこのインテリアアセットが合うな、と試しにレンダリングしクライアントに見せていく。これらは最近の建築業界でも近い展開に入りつつあるのは周知の事実かと思われますが、BIM(Building Information Modeling)に代表されるデザインアプローチの変遷で、抽象的なドアとか抽象的な壁とかでレイアウトの構造のみを決定し、そこに豊富なアセットライブラリから適用するアセットを選んで組み立てていくようなワークフローです。
このワークフローへの移行を進めた場合、今まで以上にアセットの貯蓄が可能になっていくと思います。レイアウト作業と独立にデザインの作業を進めていく。つまり、レイアウトのプロセスと切り離した形で、アーティストは(ドアなどの)各種カテゴリーで分類された各オブジェクトのデザインにのみ集中し作業を進め、それがどのようにシーン全体へアサインされるかは考えないまま作業するパラダイムへ移行していけると考えています。
これらは衣服のデザインで、パタンナーさんがパターンそのものの自由度を模索しパターンを形成し、テキスタイルとしての素材をデザインする人は工場と相談しながら素材そのものの自由度を探求するのとも似ています。
各工程を担当するアーティストの職人性を発揮し易い環境をインフラレベルで構築していく。そう言い換えてしまってもいいかもしれないパラダイムシフトが今回のトピックで長期的に扱いたい題材とも言えます。
我々、映像制作を扱う領域では、長年の請け負い型での制作が主たる業務となって来た慣行上、長期保管前提のアセットデザインのワークフローやその運用にはまだまだ経験を有してはいないと思われます。
更にそこには、近年のプロシージャルモデリングやプロシージャルテクスチャーなどの、手続きを再実行可能な形式で格納したからこその展開として、手法の再利用や再展開、手法そのものの変形や亜種の考案、など、デザインプロセスそのもののパラダイムシフトをどのように考えていくかが刺激ある課題の一つとなっています。
会合中、スタジオフォンズからは、これらの題材に関しての先行事例としてインフラレベルへの要求事項と、これらを運用した経験からのメリット及びデメリットに関して紹介し、そのあと、ポリゴンピクチュアズからは、プロダクション業務で培われた様々な経験、例えば、セルルック方面の手法をどのようにそのパラダイムへ落とし込めそうか、また、海外の大型シリーズでのプリプロ工程などで養われた数々の経験をそこにどのように展開していけそうか、などをお話ししますが、今回、モデレータとしてこの二社が前述の点に関してお話しするのは下記に記載の理由によります。
サーバサイドでリファレンシングとインスタンシングの仕組みについて考えていくことは、パイプライン上での様々なアッセンブル、つまりシーンアッセンブルやショットアッセンブルなどの各種工程の見直しを、ブラウザ経由で直接アーティストがどのように操作出来ていくのか、開発者との関係は?、などなど、インフラレベルでの大幅な見直しを行っていけるためになります。
これらを実践的な映像制作パイプラインに持ち込むには様々な問題を自然に生じ、例えば、サーバ内でのショットアッセンブルの段階で、効果的にレンダリングやシミュレーションをどう計算クラスタに投げていくか、それらのトラブルへの対応をwebパネル越に行う仕組みの構築は?といったインフラのマネジメントレベルの問題が膨大に出てくることが見込まれます。そこに加えて、2DCG,3DCGとしてのオンプレミス時代のノウハウとして、カラーマネジメントやアーティスト向けのいわゆる便利ツールの類をどのようにサーバサイドに持ち込んでいくかなど、プロダクションユースならではの機能の完備が欠かせない展開になると思います。
加えて、サーバ内でのアイデア貯蓄やアセット貯蓄を行うに辺り、ライツやパテントチェックの見直しや、長期保管可能なプロシージャルなアセットのあり方などなど、実用段階に持ち込むには膨大に存在している課題に関して、参加者間で入念なディスカッションを行っていくことにあります。
これらはデザインプロセスとして考えるべきことを様々な角度から考えていくことになりますが、衣服を扱うのであれば人体を表す形状モデルと衣服の型紙の関係、その際の縫製技術の違いによる物理的なシミュレーションの課題の掘り下げ、人体の動きと皮膚の伸縮によるレンダリング上の手法の課題の抽出、プロシージャルモデリングとしてのキャラクターのデザインスタディの見直し、建物と景観の全体を再構成可能なままアセットを貯蓄して行き、都市の景観スタディとプロダクションモデルの貯蓄をどのようにストレージ内で展開するか、複合用途の建築物とそこでの避難時のシミュレーションとしての群衆シミュレーションと映像制作内での群衆シミュレーションのある種の共存、などなど、実用物を大事にフィクションとして展開していく映像業界ならではの課題を、今回の会合のトピックスである「サーバサイドでのプロシージャルモデリング」が否応なく我々を考えさせてくれることを期待しています。
今回特集したいツールやミドルウェア
https://a-film-production-technique-seminar.com/fppat/materials/ppi_phones_future_tools/index.html
に、City GenerationやSimulation、CADなどの項目で関係する資料をまとめていますので、会合までにチェックのほどお願い致します。
As server-side referencing and instancing are perfected, we start to consider creating pipelines making effective use of scalable storage, and prepare an environment suitable for server-side procedural modeling. An example of how this could be typically used is in the server-side simulation and referencing of cities and crowd scenes.
Imagine the following: staff are work to design a cityscape on the server. Then, characters move about in that setting as though a story is being played out.
The interiors designed individually by the artists are packaged on the server with no specification of where exactly they are to be used. From there, a web-accessible catalog is prepared as a library for this growing stock of interior assets. An art director can test renders of interior assets they feel might fit a certain situation, and show this to the client. I believe it may be common knowledge that the architecture industry has been moving in a similar direction recently, but by transitioning to a BIM (Building Information Modeling)-representative design approach, we may also be able to build a workflow which allows us to simply select appropriate assets from a rich asset library, after having decided on a layout comprising only an abstract door, abstract walls, etc.
If transitioning to this workflow, I believe there will be a possibility that we will need to store many more assets than before. Layout work will be able to be done independently of design work. In other words, I believe that we will be able to transition to a paradigm in which by separating out the layout process, the artists can focus solely on creating the designs for the objects in each category (e.g. “doors”), and while doing so we can think about how these can be assigned in the scene overall.
This is similar to clothing design, where the patterner is free to experiment with and create various kinds of patterns, and then the person who designs the material as a textile is free to explore how to create this, in consultation with the factory side. On an infrastructure level, the work environment is built to allow the artists in each phase to demonstrate their own artisanship. This may be what we could call a “paradigm shift”, but it can certainly be said that this topic will be something we will be grappling with for the long-term going forward.
In our own field of film production, through long years of what has primarily been piecemeal contractor work, I believe that we do not yet have much practical experience in operating a workflow for asset design predicated on long-term storage.
In addition to this, in recent years with procedural modeling and texturing, this development and the re-use and re-development of methods as a result of needing to store data in a format which allows for repeated execution, the approach to changing the methods themselves and creating subsets, etc.; how we think about the design process itself as a paradigm shift will become one of our hottest topics.
During these discussions, to set a precedent for this topic, Studio Phones will introduce some of their requests aimed at the infrastructure level, as well as some of the advantages and disadvantages from their operational experiences. After this, Polygon Pictures will discuss their experiences, gleaned from various production duties; e.g., how methods from cel-look animation can translate to this paradigm, or how to develop on experiences from the pre-production phases in various large-scale overseas television series projects. However, the reason the moderators would like to discuss the aforementioned points from these two companies in this particular session is as follows:
Thinking about the setup for server-side referencing and instancing, for the various assemblies – that is, scene assemblies or shot assemblies that are passed through various production phases, how should these be directly manipulated by the artists via the browser? What relationship to the developers? This will involve large-scale reviews of the system at an infrastructure level.
Naturally, many problems can be expected if we try to implement these features in an already operating film production pipeline, e.g., at the shot assembly stage on the server, how do we effectively send this to the rendering or simulation computing cluster? Do we build a system to handle problems that occur with this via web panels? These and similar infrastructure-level concerns can be expected to increase. Furthermore, how will we implement things such as color management and other convenient tools for artists, which have been developed through our know-how acquired during the “on-premise” era of 2D- and 3D-CG animation production? Perfecting these features which can only be gleaned from actual production use will become an essential component of development.
In addition to this, we would like to hold careful discussions relating to the running of this “knowledge base” and “asset base” on the server, with regards to the large, existing issues with implementation at a practical level, such as rights and patent check reviews, the feasibility of long-term storage of procedural assets, etc.
Thinking of these as part of the design process will require approaches from various angles. To use the example of someone working in the clothing industry, as they would see the relationship between a model representing the human body and a paper dress model, and exploring the issues with physically simulating the difference between this and actual sewing technologies, in the same way we must isolate the issues relating to methods for rendering the stretching and shrinking of skin as a human body moves, reconsider our character design studies as procedural modeling, create a stock of assets that can be used as-is to recreate buildings or scenery - do we deploy these cityscape studies and stock of production models inside the storage? Is there a kind of coexistence with crowd simulations in film production and crowd simulations as used in evacuation simulations using multipurpose architectural models? Etc., etc. In the issues unique to the film and video industry, where we use real objects to create fiction, the topic of this session on server-side procedural modeling may not provide all the answers but I look forward to a thought-provoking discussion.
Materials relating to city generation, simulation, CAD, etc., for the tools and middleware we are focusing on have been collected on the following page, so please take a look at this before the seminar:
https://a-film-production-technique-seminar.com/fppat/materials/ppi_phones_future_tools/index.html
■技術上の課題
■Technical challenges
ここでは少しプロダクションユース面での課題に少し触れたいと思います。
映像制作用の形状モデルや各種計算のプロシージャとしての仕組みの多くは、現在の設計で構築された計算資源、つまり各スタジオで実際に設置している計算クラスターなどの環境に依存していく部分が多々あります。
そこではLOD(level of detail)の展開として、先の例の建造物などを扱う際であれば、例えば無垢材を扱う際に3Dのプロシージャルテクスチャーやボクセルデータを用いた何かの手法を考えることは出来ても、2017年の映像制作スタジオでの実際の計算資源から考えた場合、基本的には、化粧板を張るように形状の表面にテクスチャを貼る、あるいはUVを調整しつつプロシージャルテクスチャをそこに割り当てる、などいった、そのような調整を多くの箇所で必要とします。
これらはそのアセットがいわゆるヒーローアセットであるか、またはメインキャラクターでないサブキャラクターやモブ向けのアセットかでも状況が変わって行きますが、それらはモデリングの際の作り込みにも影響し、例えばキャラクターに着せる衣服を扱う際にも、アセットによってはアンダーウェアまで作り込み、実際の衣服の重ね着をしたような構造でも動作するクロスシミュレーションを適用したり、別のアセットにはメッシュ一枚で衣服を構成するが、シースルー素材なのでそこで扱う細かな形状をプロシージャルに生成しながら透過性を加味して計算するなど、アセットの用途別に作り込みの粒度が変わって行きます。
しかしながら長期保管前提でのアセット制作の傾向を考慮した場合、この粒度の取り扱いを長期的保管の目線で考えて行く必要があり、サーバサイドで展開するプロシージャとしての様々なリソースの管理に関しても、単なる管理ではなく、コンテナなどを利用して計算資源を抽象化したまま管理するのか、デプロイメントの仕組みをもう少し長期保管目線で考えて各種実装のコーディングスタンダード込みでの見直しをするのかなど、広範囲の既存手法への見直しが必要になって来ます。
会合中は、あくまでもサーバサイドでのプロシージャルモデリングの環境構築の課題に関してディスカッションを進めて行きますが、関連する事項としてこれらを視野に、会合までに問題意識を整理して参加頂けたらと思います。
Here I would like to touch on issues in production use.
For most of the geometry modeling and rendering procedures used in film production, the way these are currently set up they rely heavily on existing computing resources, in other words the rendering clusters, etc., already installed in each studio.
Then, regarding the development of LODs (Level Of Detail models), when handling architectural structures as in our previous example, for example in solid wood, if we can consider methods somehow using 3D procedural texturing or voxel data, considering the actual computing resources of a production studio in 2017, basically we achieve this by making things with panel shapes and applying textures, or assigning procedural textures while adjusting the UV, and such adjustments will be needed in many areas.
While the situation can differ depending on whether these assets are so-called “hero assets”, “sub-characters” or “mob” assets for crowd scenes, this can affect the level of detailing in the model, and for example when dealing with the clothes a character is wearing, depending on the asset, we may need to detail down to the underwear, or apply simulation to create the movement of the clothes in their actual layers, or create the clothes as a single layer of mesh in a separate asset; however in the case of see-through parts on the clothing and the fine-detailed shapes these can require, do we generate these procedurally while adding transparency in rendering? The granularity of details can depend on how the asset is intended to be used.
Having said this, if we consider the trend toward creating assets assuming they will be stored for the long term, we need to consider that granularity with an eye to long-term storage, and regarding the management of the various resources deployed procedurally on the server side, these are not simply “managed”, but by using containers or similar to manage these while abstracting the computation resources, or looking at the development setup on a slightly longer timeline, we will need to review a broad swath of existing methods, such as the multitude of implemented coding standards.
In this discussion, we will mainly be covering the issues relating to constructing an environment for procedural modeling on the server side, but I would like to also keep these related points in our field of view, so that we may have an awareness of these potential issues by the time the seminar begins.