Introduction

In a span of approximately four months (November 2021 to February 2022), together with Pablico Fournier and Hjalti Hjalmarsson, and under supervision by Andy Goralczyk and help from Francesco Siddi, we created a short promotional animation for the Snow character. (rigging: Demeter Dzadik, pipeline support: Paul Golter, additional modeling: Julien Kaspar, FX and geometry nodes: Simon Thommes, layout/animation feedback: Rik Schutte)

The idea was to place Snow in a dystopian Aztec-inspired mega-city running away from two drones. After being trapped by a third drone, he uses his secret power, and the animation ends.

An early clay render

We wanted to create a short animation to test Eevee in a production environment. What are the advantages and obstacles when working with Eevee vs Cycles? What are the render times? Which factors increase render times? These are some of the things we wanted to find out.

Keep in mind that some of the aspects mentioned here will change due to the Eevee Rewrite.

Quick peek at shot 0040

Pipeline & Performance Context

Textures (Krita) and shaders are designed to be re-used in a semi-procedural way. The “hotspotting” technique for texturing was used to assign faces (based on proportions & scale) of the object. Using vertex paint to create various effects like puddles, dirt, and rust to make them look more distinct but streamlined.

Hotspotting color texture

Texture example in Krita

The scene was built as if you would render it in Cycles. Meaning no optimizations for models like you would see in modern games. No LODs, baked normal maps or retopology was part of this production. Being aware of this, adding modifiers like subdivision surface or bevels were limited to more important objects. Decimation was used to optimize scene geometry, some destructive and non-destructive.

The production structure was simplified by adding the lighting in the set file. This creates more consistency but is less performance friendly. The lighting.blend contains the drone Spot Lights, the set lighting, and the Snow lighting rig. This is an empty object constrained to the rig with key, fill, rim, and other lights.

Quick Statistics

Beau's machine:

• OS: Pop!_OS 21.10
• CPU: Intel Xeon(R) CPU E5-2697 v3 @ 2.60GHz × 56 threads
• GPU: NVIDIA Corporation GA102 GeForce RTX 3080 10GB vram
• RAM: 4 x 16 Micron 64GB DDR4-2133 MT/s
• Storage: ATA Samsung SS 860 512GB

Paul's machine:

• OS: Pop!_OS 21.10
• CPU: AMD Ryzen 7 3800X 8-Core Processor (16 threads) Max Speed: 4550 MHz
• GPU: AMD RX 590 16GB vram
• RAM: 4 x 8 32GB DDR4-3200 MT/s
• Storage: Samsung SSD 970 EVO 1TB

Animation:

• Shots = 13
• Resolution = 1920 x 1080
• FPS = 24
• Average render time per frame = 3 minutes
• Textures including Snow = 141

---

Experiences

Eevee and Cycles have their own strengths and weaknesses when rendering animations. It is possible that Eevee has the potential to render faster and with better image clarity; however, during the compositing stage, the passes were missing the refinement of the sample-based “Combined” pass. Specifically, the Depth of Field and Motion Blur are reverted to a lower fidelity version, as well as any materials with Alpha Blend will be missing from the image.

This ultimately caused the reconstructed image to be noisier and incomplete making compositing less effective. That is why a lot of smaller adjustments and iterations were made before creating the final renders.

Current compositing is limited when using all of the passes to reconstructed the combined result

When rendering (F12) the CPU is being used for object evaluation, this process is on a single thread. After spending time logging performance it became more apparent that the single-thread performance plays a larger role determining render times, no matter the GPU power. This is context sensitive and applies mostly to Snow and the Drones having Subdivision Surface modifiers (when downloading the production files, a good way to limit render times is enabling simplify).

As you can see in the image below, Paul's machine has faster single thread performance (see Paul's Machine above, under 'Quick Stats'). Event though my machine has a better GPU the server processor has a much lower single thread performance. This could use more testing where the GPU is the same, but with different CPU.

Overview of the log

Practicalities

Eevee requires the compilation of shaders to load on the GPU in order to render. This might take some time at the beginning of the production, fortunately, this will be faster when almost all of the shaders have been written.

Rendering in the viewport to change the lighting with eight or more samples will slow down the responsiveness a lot. That is why the viewport samples are set to two, with a scaled down viewport. To improve the performance we used “Simplify” to lower the object evaluation time.

Artistic

Lights in Cycles can influence the various channels like the Diffuse and Glossy to be turned on and off. But lights in Eevee allow more control by treating the Diffuse, Glossy, and Volumetric as slider parameters. This is one of my favorite aspects of working in Eevee, especially increasing the values above 1.0 to boost a channel’s influence.

To avoid uniformity in the drone spot lights and give it more variation - like an old flashlight - small "shadow caster" objects are placed to block the light. There are two spot lights, one for lighting the scene and the other to affect volume only (see image below).

The shadow caster is closely placed near the source of the spot light

Difference without and with shadow casters

The textures were created in a way that they can be re-used in various ways. Either by making a copy of the existing material and assigning different colors using a ColorRamp node. Or by using vertex blending or textures driving unique changes.

A simple yet effective way to create variation

Vertex painting and the use of modifier offsets to create variation

Using the Asset Browser - first time during a project - to drag and assign materials was a good way to iterate and experiment. I recommend using the Asset Browser to keep an overview which materials you need to create.

---

Recommendations

My general suggestion is to build and create your scene like you would for external game engines. Which is to optimize your models and bake to image textures when rendering animations in Eevee.

Geometry

• Strongly suggest not using any subdivision surface modifiers. The model will always be double the triangle count when rendering in Eevee (triangulation and without subdivision surface modifiers). By setting the level to two, for example, will use 16 times the base triangle count!
• Retopologize or decimate your models to lower scene geometry.

Shading

• Using any bump or displacement nodes for shading can degrade performance, it needs to calculate an additional two graphs. Bake to normal maps if possible.
• Avoid rendering glass that overlaps itself using Alpha Blend. Use an opaque material with a refraction shader for an approximation.
• The current Subsurface Scattering (SSS) implementation can cause “bleeding” or “glowing” areas in the mouth. To fix this, remove the SSS values if these areas should be less noticeable.

Lighting

• Limit the distance of the light influence to prevent additional computation on shadows (and have more artistic agency)
• Lights in Eevee have various performance cost, specifically geometry passes that need to be calculated for shadows. The more “projections” each light uses, so does the performance cost increase.
  • Point Lights needs 6 projections, making them performance heavy.
  • Area Lights always use 5 projections
  • Spot Lights can use only 1 projection, this is based on the cone angle. If the angle is <90 degree it will use 1 projection (can cause small imprecision). By increasing the angle to >90 degrees the performance cost equals that of an Area Light.
  • Sun Light uses cascade shadow mapping which is tied to the amount of cascade and complexity of the scene. Cascade shadows are always updated.
• If you want the best performance when lighting your scene, use Spot Lights with an angle below 90 degrees to save calculation time for shadows.
• Separate lights into different collections based on contact shadows. This makes it easier to keep track of which lights have a greater performance cost.
• The “Cube Size” and “Cascade Size” shadow resolution was almost always 1024 px. The reason was to avoid longer render times and a significantly slow viewport. Be careful with increasing the shadow resolution if the scene is highly detailed.

Rendering

• Overlapping volumetric effects can be solved by lowering the tile size and increasing the samples.
• This production used one set file that included the set lighting with probes for baking. It isn’t possible to exchange baked data between scenes and re-use it more efficiently, we had to re-bake the lighting for each shot. Keep this in mind when rendering the same scene in different files.
• Motion Blur enabled but set to zero steps will use a Vector Motion Blur which is not as accurate but faster to render.
• Keep an eye on the amount of motion blur steps, don't use more than you need.

Compositing

• As mentioned before, reconstructing the image to match the “Combined” output isn’t possible. The only solution is to make sure everything is correct before rendering.
• Alpha Hashed materials will be visible in the passes but the downside is the additional noise. A solution could be to increase the render samples, unfortunately, this will increase render times significantly.

Conclusion

Creating the Snow Parkour in Eevee was incredibly fun, but also required a more thoughtful approach. For example: baking Irradiance Volumes & Cubemaps, deciding which lights use contact shadows, avoiding bump or displacement nodes, and the limitations that come with screen space effects. On the other hand, Eevee gives a lot of creative freedom when using lights, great volumetric effects and to render without much or any noise.

As mentioned in the ‘Recommendations’, the best way to approach rendering in Eevee is building your scene as efficient as possible, like exporting models to game engines. This includes optimizing your models and baking all of the channels to texture files. And to avoid using subdivision surface modifiers that increases object evaluation time, when possible.

There is an interesting balance between flexibility and performance when talking about the shader nodes. More flexibility, such as using vertex paint to blend textures, takes additional shader graph processing time for Eevee. While the performance friendly use of baked textures might use more vram, but is faster to load in the shader graph. This comes down to the art direction and goal of the project.

---

If you wanna learn more about Eevee, check out the documentation

Thanks to Clément Foucault for more in-depth explanations