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


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


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.