In the last post about the Viewport Plan of Action we ended briefly covering the upcoming realtime engine of Blender 2.8, nicknamed Eevee. Eevee will follow the (game) industry PBR (Physically Based Rendering) trend, supporting high-end graphics coupled with a responsive realtime viewport.

Sci-fi armor by Andy Goralczyk – rendered in Cycles with outline selection mockup, reference for PBR

At the time it was a bit early to discuss the specifics of the project. Time has passed, the ideas matured, and now is time to openly talk about the Eevee Roadmap.

Scene Lights

The initial goal is to support all the realistic Blender light types (i.e., all but Hemi).

We will start by supporting diffuse point lights. Unlike the PBR branch, we will make sure adding/removing lights from scene doesn’t slow things down. For the tech savy: we will use UBO (Uniform Buffer Object) with the scene light data to prevent re-compiling the shaders.

Next we can support specularity in the shaders, and expand the light support to include area lights. The implementation implies we expands the GGX shader to account for the UBO data.

We will also need to rework the light panels for the Eevee settings since not all settings make sense for realtime.

Soft shadow

We all like our shadows smooth as a baby butt. But realistic smooth shadows are computationally expensive. For the realtime mode of Eevee we will follow the shadow buffer implementation we have in Blender now. For offline Eevee rendering  (i.e., playblast) we can crank that up and raise the bar.

Regular Materials

Uber Shaders

Things are lit and well, but we still need materials to respond to it.

We will implement the concept of Uber shaders following the Unreal Engine 4 PBR materials. Since Eevee goal is not feature parity with UE4, don’t expect to see all the UE4 uber shaders here (car coating, human skin, …).

An Uber shader is mainly an output node. For this to work effectively we also need to implement the PyNode Shader system. This way each (Python) Node can have its own GLSL shader to be used by the engine.

UI/UX solution for multi-engine material outputs

Multiple engines, one material, what to do?

A material that was setup for Cycles and doesn’t have yet an Eevee PBR Node should still work for Eevee, even if it looks slightly different. So although we want to support Eevee own output nodes, we plan to have a fallback solution where other engine nodes are supported (assuming their nodes follow the PyNode Shader system mentioned above).

Convert / Replace Blender Internal

After we have a working pipeline with Eevee we should tackle compatibility of old Blender Render files. That said, the Cycles fallback option should be enough to get users to jump into Eevee from early on.

Advanced Materials

More advanced techniques will be supported later, like:

• SSS
• Clear Coat
• Volumetric

Image Based Lighting

We will support pre-rendered HDRI followed by in-scene on-demand generated probes. This makes the scene objects to influence each other (reflections, diffuse light bounce, …).

We need the viewport to always be responsive, and to have something to show while probes are calculated. Spherical harmonics (i.e., diffuse only) can be stored in the .blend for quick load while probes are generated.

Time cache should also be considered, for responsiveness.

Glossy rough shaders

Agent 327 Barbershop project by Blender Institute – rendered in Cycles, reference of Glossy texture in wood floor

We can’t support glossy with roughness reflections without prefiltering (i.e., blurring) probes. Otherwise we get a terrible performance (see PBR branch :/), and a very noisy result.

Diffuse approximation

Visual representations of the first few real spherical harmonics, from wikipedia

There are multiple ways to represent the irradiance of the scene, such as cubemaps and spherical harmonics.

The more accurate way is to use a cubemap to store the result of the diffuse shader. However this is slow since it requires computing the diffusion for every texels.

A known compromise is to store low frequency lighting informations into a set of coefficients (as known as Spherical Harmonics). Although this is faster (and easy to work with) it fails in corner cases (when lights end up cancelling themselves).

Eevee will support spherical harmonics, leaving cubemaps solely for baked specular results.

Probe Objects

Like force fields, probe should be empty objects with their own drawing code.

Environment map array

Reference image from Unreal Engine 4, room design by NasteX 

Large objects (such as floor) may need multiple probes to render the environment correctly. In Unreal environment map array handles this on supported hardware. This is not compatible with OpenGL 3.3 core. We can still support this (via ARB extension) on modern graphic cards. But we should look at alternatives compatible with old and new hardware, such as tetrahedral maps.

Post Process Effects

For the Siggraph deadline we need the following effects:

• Motion Blur
• Bloom
• Tone Map
• Depth of Field
• Ground Truth Ambient Occlusion

Other effects that we would like to implement eventually:

• Temporal Anti-Alias (to fix the noisy fireflies we get from glossiness)
• Screen Space Reflection (more accurate reflection, helps to ground the objects)

Epilogue

Blender 2.8 Viewport design mockup by Paweł Łyczkowski, suggesting fresnel wires over a Cycles preview

Just to re-cap, the core of the features mentioned here are to be implemented by Siggraph 2017, with a more polished usable version by the Blender Conference.

The viewport project (which Eevee is a core part of it) development is happening in the blender2.8 branch. It is still a bit early for massive user testing, but stay tuned for more updates.

Edit: You can find the Eevee roadmap organized chronologically and with a more technical wording at the Blender development wiki.