EEVEE’s Future

EEVEE has been evolving constantly since its introduction in Blender 2.80. The goal has been to make it viable both for asset creation and final rendering, and to support a wide range of workflows. However, thanks to the latest hardware innovations, many new techniques have become viable, and EEVEE can take advantage of them. A […]

EEVEE has been evolving constantly since its introduction in Blender 2.80. The goal has been to make it viable both for asset creation and final rendering, and to support a wide range of workflows. However, thanks to the latest hardware innovations, many new techniques have become viable, and EEVEE can take advantage of them.

A new beginning

For the Blender 3.x series EEVEE’s core architecture will be overhauled to make a solid base for the many new features to come. The following are the main motivations for this restructuring.

Render Passes and Real-Time Compositor

A core motivation for the planned changes to EEVEE’s architecture is the possibility to output all render passes efficiently. The architecture is centered around a decoupling of lighting passes, but will still be fully optimized for more general use cases. Efficient output of render passes is a must in order to use the planned real-time viewport compositor at its full potential. This new paradigm will also speed up the rendering process when many passes are enabled, and all render passes will be supported, including AOVs.

Screen Space Global Illumination

The second motivation for the rewrite was the Screen Space Global Illumination (SSGI) prototype by Jon Henry Marvin Faltis (also known as 0451). Although SSGI is not necessarily a good fit for the wide range of EEVEE’s supported workflows, strong community interest in the prototype shows that there is a demand for a more straightforward global illumination workflow. With SSGI, bounce lighting can be previewed without baking and is applied to all BSDF nodes. This means faster iteration time and support for light bounces from dynamic objects.

A demo of the SSGI prototype branch by Hirokazu Yokohara.

Hardware Ray-Tracing

Supporting SSGI brings ray-tracing support a step closer. The new architecture will make the addition of hardware ray-tracing much easier in the future. Hardware ray-tracing will fix most limitations of screen space techniques, improve refraction, shadows … the list goes on. However, implementing all of these will not be as easy as it sounds. EEVEE will use ray-tracing to fix some big limitations, but there are no plans to make EEVEE a full-blown ray-tracer. For instance, ray-tracing won’t be used for subsurface scattering (not in the traditional way at least).

Note that hardware ray-tracing is not a target for the 3.0 release but one of the motivations for the overhaul.

Volumetric Improvements

Volume rendering is also something that should be improved with this update. In the current version of EEVEE released in 2.93, object volume materials are applied to the object’s entire bounding box and are still constrained to a rather coarse view-aligned volume grid.

The goal is to improve that by providing a volume rendering method that evaluates volumes in object space. This means volumes will be evaluated individually and per pixel allowing for high fidelity volumetric effects — without paying the cost of the unified volumetric approach (the current method used by EEVEE). This would also make volume shadow casting possible for those objects.

These changes would make the following use cases trivial to render, compared to current implementation where it would be impossible to get this quality (examples rendered using Cycles).

Water surface with absorption volume, rendered with Cycles
Highly detailed smoke simulation with shadows projected onto the scene, rendered with Cycles

New shader execution model

The current shader execution is straightforward and executes all BSDF nodes in a material node graph. However, this can become very costly with complex materials with many BSDF nodes, leading to very long shader compilation times.

The approach in the rewrite will sample one BSDF at random, only paying the cost of a single evaluation. A nice consequence of this is that all BSDF nodes will be treated equally with all effects applied (Subsurface Scattering, Screen Space Reflections, etc…).

NPR & EEVEE

Update June 7, 2021:
Non-Photorealistic Rendering (NPR) is an important side of Blender. There is no plan to deprecate the Shader to RGBA node, but it will not be compatible with the new deferred pipeline and all the features that come with it. Any materials using a Shader to RGBA node will be treated like alpha blended material regarding render passes. This is similar to the current behavior, but it might look slightly different if a material uses both NPR and PBR shading.

Moreover, Grease Pencil geometry support is going to bring shadow casting and more flexible shading options. This will be a per material option. The current Grease Pencil material pipeline will remain fully supported and have other goals (more traditional 2D workflow & performance).

And many more …

There is a huge list of features that are just waiting for this cleaner code base. That includes Grease Pencil support, vertex displacement, panoramic camera support, faster shader compilation, light linking… etc.

This is also an opportunity to rewrite the whole engine in C++. Hopefully this will help external contributions and encourage experimentation.

Conclusion

This endeavor has already started in the eevee-rewrite branch. Some features listed in this post are actually already implemented, however at this point it is to early for testing. Soon there will be experimental builds for developers to test. At that time the development team will create threads on devtalk.blender.org to follow feature-specific development.

The target plan for Blender 3.0 is to have all features back with the addition of some new features. The final set of feature targets for 3.0 is not yet decided.

Source: Blender