Autodesk Media & Entertainment
New technological challenges are always required at production sites for blockbuster movies released from major film studios. The production of “Sonic the Hedgehog 3” (hereafter “Sonic 3”) was a series of those very challenges for MARZA ANIMATION PLANET INC. (hereafter “MARZA”). When asked about the various makeovers in the pipeline achieved through the project, MARZA revealed how they made use of Autodesk products including Flow Production Tracking and Arnold in effective ways.
- Mr. Takaaki Kise, Layout Supervisor
- Mr. Takamasa Matsunari, Technology Team Leader
- Mr. Yasuharu Yoshizawa, Compositing Supervisor
- Ms. Natsumi Kasagi, Technology Team Engineer
- Mr. Yuuki Akishige, Systems Administrator
Challenging the USD pipeline anew and creating a hybrid flow
MARZA was in charge of a sequence of about 2 minutes in “Sonic 3” that played after the credits of the film. It’s trailer-like content that makes you feel the story will continue after the curtain comes down.
First, when asked about the biggest challenge in the project for this work, it was mentioned that the main assets provided by the client, Paramount Pictures, were in USD (Universal Scene Description) format. OpenUSD is an open source framework developed by Pixar for describing 3D scenes, and is attracting attention as the technology that dramatically increases the efficiency of data transfer and collaborative activities in large-scale VFX projects. Although the idea of introducing USD at MARZA had been around for a long time, it is said that it was not actualized due to the balance with other developments. However, during the transition period to the new pipeline that has been progressing little by little through the movie “Sonic the Hedgehog” series, USD support has emerged as an essential requirement. It was the first large-scale USD operation in this project.
“We tested the entire flow, starting with simple assets, and progressed little by little. Then, sometimes, a large amount of real go-live data was sent from the client and we tested them again. That was the way we proceeded by feeling our way forward,” recalls Mr. Kise. It was really a constant trial-and-error adjustment to proceed with the project while analyzing the USD data specifications themselves.
This new challenge also brought about a change in the very idea of the pipeline. Conventionally, the task flow was defined on the pipeline side to derive the workflow for artists. However, since there is a clear framework this time, namely USD, the pipeline was dedicated to data management. It specializes in functions as a database that supports the foundation of workflow, such as the path management of data. Interventions were deliberately kept to a minimum so that artists could proceed with their work flexibly.
Character layouts, animations, and camera work are performed in Autodesk Maya, which has excellent operability, and the location information and other data are passed to Solaris (Houdini’s unique layout: the environment for look development and lighting) as a USD file, and the final rendering is completed with Arnold. In order to run this hybrid flow smoothly, there was an evolution into a mature pipeline concept of devoting oneself to data transfer and version control. MARZA has decided on regulations for handling USD through experience with this project, and they inclined to extend the current waterfall-type flow design to allow USD-like task management and use it together.
Evolution of in-house rendering dispatcher “harvester”
For many years, MARZA has operated the “harvester,” which is a rendering dispatcher (a system that distributes and manages computational processing for render farms) developed in-house. However, due to the ever-expanding scale of projects, the old version faced stability issues, and the transition to AWS Thinkbox Deadline was also temporarily considered. However, on the occasion of joining the “Sonic 3” production, the newly developed dependency in “harvester” was introduced.
Mr. Matsunari emphasizes the unique advantages like no other, while citing “familiarity,” such as ease of dependency control which has grown over many years of operation.
The biggest advantage of “harvester” is its flexible resource management. “There is a logic where priority is set on a project-by-project basis, and priority changes dynamically depending on how often users use it,” says Mr. Yoshizawa. “Overall, the ”harvester” is a kind of logic that averagely uses resources overall, so I think this is an aspect not found in other dispatchers,” Mr. Matsunari adds.
Whereas many dispatchers allocate computational resources in a fixed manner for each project, the “harvester” treats the rendering firms as a whole as one large pool and dynamically adjusts priorities as the situation demands. This helps to actualize an environment where processing proceeds smoothly without delay, even for the jobs being put under a big rush or the jobs by artists with low usage frequency. It seems an optimal solution unique to MARZA, which directly links overall production efficiency to artists’ satisfaction.
In addition to the on-premise environment, the cloud computing service Amazon Web Services (AWS) was used for rendering in Arnold. In this project, due to progress reasons, there were times when 80 units were activated per day, and there were times when only 5 units were activated per day. During a production period of 3 months, in cases where such variations in usage opportunities occur, a flexible method of covering it with cloud computing that can be used each time was reasonable instead of purchasing in-house render servers.
Responding to increasingly complicated demands – color management strategies centered on ACEScg
The major change in this film compared to the previous series is the color space of the rendering. Previously, rendering was performed with ARRI LogC Linear, but this time, “ACEScg” that complies with ACES (Academy Color Encoding System), which is an industry standard color management system, has been adopted.
From the start of the series, OpenColorIO (OCIO) has been adopted, thus allowing flexible support. One of the changes in this sequence was the change in the rendering color space. In the past, rendering was performed with ARRI LogC3 Linear according to the color space of the shooting camera, but from this time, specifications were changed because ARRI LogC4 took over the grading base along with the shooting camera, and ACEScg that complies with ACES (Academy Color Encoding System), which is an industry standard color management system, has been adopted.
First, all production processes were unified with ACEScg for the specific flow. It was necessary to perform accurate color conversion according to each application, namely “sRGB,” which is correctly displayed on a conventional PC monitor for verification, “Rec. 709 (gamma 2.4),” which is a broadcast standard for the movie confirmed at the client, and “ARRI LogC4,” which matches the camera format for the final delivery data. In order to perform a wide range of color conversions efficiently without mistakes, MARZA has developed a dedicated movie generation tool in-house. They have established a structure that automatically outputs data converted to an appropriate color space according to the sections the artist belongs to and usages.
Cooperation between Flow Production Tracking , which is the center of production communication, and the in-house pipeline “picore”
MARZA was the first large-scale user of Flow Production Tracking in Japan when they produced “Space Pirate Captain Harlock” (released in 2013). Since the production of blockbuster movies from major film studios is carried out globally, strict security is required. Therefore, MARZA isolated this film’s Flow Production Tracking site alone from various projects carried out within the company, and built an environment that would allow operations where only those involved can access it.
The CG supervisor for “Sonic the Hedgehog” movies is based in Australia. In order to overcome this physical distance and achieve smooth production progress, Flow Production Tracking has functioned as a central hub for communication. First, artists in Japan publish their deliverables and create and share playlists for checking. CG supervisors overseas log in to Flow Production Tracking, check the content directly on that playlist, and write comments on status updates and feedback. Since all exchanges are recorded on the “note” function of Flow Production Tracking, it becomes clear by whom and when a specific instruction is given.
The characteristics of MARZA’s use of Flow PT are its advanced collaboration with the production pipeline “picore” developed in-house. This is a generic term for a group of tools with a database as the core and linked to various content creation tools, and has been newly used since “Sonic 3.” By closely linking this “picore” and Flow Production Tracking, the production flow has been dramatically automated.
“The process is for artists to publish deliverables from tools such as Maya and Nuke to the internal pipeline, and at the same time to link to “picore” data, and to publish the same data to Flow Production Tracking. In projects that use the pipeline, almost all version creation is performed fully automatically.” says Mr. Kasagi.
Once the data is uploaded to the server, a movie (version) for preview is automatically generated at the same instant. Since this series of processes is completely automated, artists are relieved from complicated tasks such as manually creating and uploading movies every time the version is upgraded. Since all feedback and checks are performed in Flow Production Tracking, there is no dependency on the tool used by each artist.
Since the artists at MARZA were used to using Flow Production Tracking for many years, customizing the page layout was almost everything they had to do, and there were no major changes. At MARZA, there is a type of tickets called “ticket flow” for artists and supervisors to exchange within the company, and it was implemented so that it could be transferred with partners for this project, and it was used to share review logs and meeting minutes.
The page layout is also left to individual discretion, thereby leading to the advantage of being able to continue the use of a pipeline for a long time once created. MARZA created an authority halfway between administrator and manager, and PMs with that authority took responsibility for layout and R&D, and customized how far the status of shots was shown. The Admin authority itself is held only by the technology team, and when there is a request, they suggest necessary permissions and consult with Autodesk support.
Playlist-based automated delivery system “SG Delivery”
Flow Production Tracking is also used in the delivery process. In MARZA, PMs are supposed to decide which shots are to be delivered, and at that time, playlists created with Flow Production Tracking are converted into delivery data. The tool used at this time is the in-house developed system “SG Delivery.”
When the tool is executed, the path of an EXR sequence file is acquired from each shot data in the playlist, and a slate (title card) with cut names, lens information, etc. written on it is generated by making full use of image/video processing libraries such as OpenImageIO and FFmpeg. Furthermore, accurate color conversion to ARRI LogC 4, which is the final delivery format, is carried out and a movie file in line with the specified naming rules is exported. The series of processes is completed by pushing a single button. The prototype for “SG Delivery” existed for a long time, but it was from “Sonic 3” that it was introduced into actual use.
“In the past, mistakes such as sending a different version were common, but by defining the target version on a playlist basis, we can now prevent such mistakes” (Mr. Yoshizawa).
Arnold supported MARZA’s visual beauty for many years
The renderer that has supported MARZA’s visual beauty for many years is “Arnold.” It was introduced about 13 years ago. At that time, as a result of testing various renderers, Arnold was finally established as the company’s production base. Mr. Matsunari points out its best appeal as “Arnold is a path tracer, so it is easier, from the start, to create realistic global illumination (GI) than previous mental rays with pure ray tracing” and its physics-based accuracy. However, what is more important than that is summed up in the phrase “the biggest thing is probably the point of being ‘used to it’.” The accumulation of know-how cultivated over many years is the foundation for the stable production of high-quality images.
In this sequence, it was necessary to operate Arnold from Houdini’s Solaris environment based on USD. At that time, two options emerged as a process for executing rendering.
One is the rendering execution command husk provided by Houdini as standard. And the other is the execution command sick, which is included in the Arnold plug-in (HtoA) provided by Autodesk for Houdini, which is more specific to Arnold. At first, operation via husk was tested, but “it was discovered that memory consumption became extremely severe along the way, and at that time, when I tried sick, we were able to process it smoothly.” Eventually, sick with excellent memory efficiency was adopted.
MARZA’s rendering style “baking flow” brings efficiency and stability
Rendering is performed in the “baking flow” at MARZA. This does not directly render a 3D scene created with a DCC tool such as Maya, but rather exports a dedicated file “.ass (Arnold Scene Source)” in which only the information necessary for rendering is extracted and fixed (baked) for each frame. This is a set of Arnold data, which is actually converted into an image by Arnold’s command-line renderer “kick.”
Scene files contain a large amount of information unnecessary for rendering, such as rigs and controllers for moving characters. In the baking flow, all of this information is stripped down, and since it is composed only of data necessary for drawing, such as pure shapes, shaders, and lighting, it is assumed that memory efficiency is good. And “.ass files” do not depend on a specific DCC application.
Therefore, even at rendering firms that do not have Maya or Houdini installed, rendering can be executed as long as there is a kick command. This leads to optimization of license costs and improvement of overall system stability. The exported “.ass file” can also be referenced again in Maya, Houdini, etc. Furthermore, when a problem occurs in rendering, there is no need to reload the entire scene file, and problem solving can be performed quickly.
Mr. Matsunari explains the effects as “Maya rigs at MARZA are usually quite heavy, but I think artists will feel that ‘memory efficiency is good’ because they use the baking flow. Conversely, if I had to point out a disadvantage, it would be that it takes some time and effort since it is frame-based management. I think to some extent, as a project gets bigger, the more advantages will come out.”
Finally, the artists and engineers of this project spoke frankly about current issues and prospects in the CG industry, and requests for Autodesk.
Mr. Matsunari: As a person responsible for technology, I wish Autodesk would further spread the word that there is a field of expertise called “technology” in the CG video industry. There are really no human resources even when we recruit, and half of our technology team are foreign nationals, so there’s almost no one from Japan applying. Even when we receive applications, many of them are game-engine experienced. Engineers in CG video production almost never show up. There are no college departments as there are overseas, and present-day students don’t even know they exist, so I have the will to appeal in that regard. I think Autodesk not only provides tools, but also is a leader in industry knowledge sharing and standard formulation, so I’m looking forward to these issues. In the years to come, AI will replace operations, and we creators must focus on higher-level control of “how to use AI” and “how to accumulate and utilize knowledge.” In that sense, too, the idea of mastering something and applying it as a foundation rather than sticking to specific tools will become more important than ever.
Ms. Kasagi: It also relates to Mr. Matsunari’s remarks, but the current situation is that the career path to becoming a pipeline engineer in the first place has not been sufficiently shown by schools or industry. There is a strong image that “you can’t get a job without going through an artist job,” and while I myself aspired to work in the technology field, I went through an effects artist job in order to learn more about Houdini, etc. Once the steps to aim for are clear, more students will want to enter this field. On the specific technical side, I’m looking forward to having color management standardized, particularly OCIO files. With the current Maya default OCIO file, it is still not directly connected to the actual flow, and each company is in a state of fumbling and researching. If you present the “continuous flow,” which can become an industry standard, a common understanding will also be created, and the tools will become much easier to use. I want Autodesk to take the lead. Also, customization is necessary for RV tools, but the reality is that we are unable to handle maintenance due to lack of resources. Users would be very grateful if you put effort into improving these existing tools.
Yoshizawa: In recent years, thanks to open file formats and tools like USD, it has become much easier to collaborate with outside partners. This is also a huge opportunity for young creators. It is necessary to constantly absorb new information, but if you learn such open technologies including OCIO, it will become a “common language” that can be used both domestically and internationally. If you have even one particular expertise that stands out, it will definitely lead to a profession or assignments. I think an attitude of constantly learning should be the key to getting through in the ages to come.
Story originally published on Autodesk AREA Japan on September 19, 2025, and written by Akiyoshi Hizume.