Dev:2.8/Source/Viewport/Eevee

Eevee

The Eevee engine will be a PBR realtime engine for Blender 2.8 viewport. The following are the plans laid out in March 2017, 14th by Clément Foucault and Dalai Felinto at the Blender Institute in Amsterdam.

Scene lights

Support for all realistic Blender light types (i.e., all but Hemi).

We will start by supporting diffuse point lights. We do this by creating an UBO containing scene light data. This means adding/removing lights from scene is not re-compiling shaders (as we have in the PBR branch).

Next we can support specularity in the shader, 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.

Soft shadow

For the records, the initial implementation will follow the quick approach Blender currently does for the BGE and Blender Internal. For real soft shadow the buffer size should be taken into account, which is a very expensive solution. This will only be implemented for offline Eevee rendering.

Regular Materials

Uber Shaders

Initially we can use basic PBR shaders (from UE4). In order to use them in production we need the PyNode Shader system implemented.

UI/UX solution for multi-engine material outputs

A material that was setup for Cycles and doesn’t have yet an Eevee PBR Node should still work for Eevee. When we have an Eevee PBR node side-by-side with a Cycles we probably should use the Eevee PBR node.

But then how can the user test the “Cycles output” in Eevee? So far the only solution is to mute all Eevee PBR nodes and have the fallback active output node to be picked instead.

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

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

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

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 demo we need the following effects:

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

Temporal anti-alias

If time allows, implementing Temporal AA will fix the noisy fireflies we get otherwise. Epic expertise may be required to fully implement that (as they did for UE4 in 2014).

Screen Space Reflection

This is not a priority, but something nice to have eventually.

Advanced Materials

More advanced techniques will be supported later, like:

• Sub Surface Scattering (SSS)
• Clear Coat
• Volumetric

Convert / Replace Blender Internal

After we have a working pipeline with Eevee we should tackle compatibility of old Blender Render files.

PyNode Shader

To be tackled as part of the Regular Materials task. Also, see PyNode GLSL API