Eevee Roadmap

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

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)


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.

36 comments 86,474 Views
  1. >>Since Eevee goal is not feature parity with UE4…

    That’s quite sad, in fact.

    How, btw, realtime reflections are going to be implemented? Unity has so-called “reflection probes” for this, but they have some drastic limitations and occasionally may make things ugly (such as floor reflection getting “detached” from the object on this floor as distance between a camera and the object increases). What is Blender devs’ plan for it?

  2. Thank you for sharing this. Is it planned to strive towards visual parity between Blender’s real-time viewport shaders and Cycles materials, and unified look dev workflow?

    I.e. will the user get the PBR materials in the viewport automatically while doing lookdev and setting up their Cycles materials – similar to how MODO does it?

    Or will real-time PBR viewport shaders/materials have to be set up independently, and Cycles materials re-assigned when the scene is to be rendered in Cycles?

    The latter is how Maya does it – where setting up pretty viewport shaders is basically only eye candy in the viewport, but actually useless for final renders because final render materials, be it Mental Ray, Arnold, or whatever, don’t look anything like the final render when seen in the viewport.
    Which in turn means that in production it’s rarely worth going through the trouble of making shaders look pretty in the Maya viewport, since you cannot use them for final (non-realtime) renders.

    Personally I think the MODO approach is the vastly superior one, and the one all DCCs should strive towards. Give the user as close a representation of their final render (using final offline render engine materials) as is possible in the viewport.

    • totally agree, and from what i read it seems like it’s going this way, though you can override that behaviour with open gl nodes for some other stuff…

  3. To illustrate my previous comment: Here are three videos demonstrating how MODO’s Unity shader as well as its Unreal Engine shader (just like MODO’s own Physical Material) all look virtually identical between the viewport and the non-realtime production renderer.

  4. What about rendering out layers/passes ? Will they stay or is compositing all supposed to happen in the viewport?

    • They will stay at first, though compositing should be able to support real-time engines as well. Perhaps even mixing them both (e.g., Cycles and Eevee composed together).

  5. Impressive works guys, THANKS, I hope new viewport be useful for Architecture-Visualization and Cartoon Rendering.

  6. Just throwing this out there. One of the things I had always wanted in the BGE was the ability to use Python to change every parameter in every material (some objects have multiple materials) in realtime. The closest thing we had to this was obj.color , which was very, very limited. What if you have a car with a 3-color paint scheme and want to change the colors? You would have to basically have 3 copies of the same object using alpha masks in order to change each color seperately, which is way too complicated. I don’t claim to know how to make this work, it may have even been impossible in the BGE, but please keep this in mind.

  7. Sounds very much like what we are working on for the Qt 3D engine too. Lots of fun times and exciting work ahead. 🙂

  8. Pre-computed GI?

  9. talking about blender internal a bit, is there any plan to port the stress Coordinte system mode to evee or even cycles, it would be so cool to do mix with normals or other effects on viewport ^^

  10. This sounds amazing! and remember to stress performance. It was mentioned in one of the podcast, but that’s important.

    What happened to OpenGL render engine?

    I tend to agree with YURI and Chris, and that how it works in MODO is pretty awesome.

    Will there only be Uber Shaders output? or will we have like in cycles, so if we want we can make our own Uber shader output, i.e. to mimic Unreal Engine 4 material as close as possible in Eevee as in UE4.

    There are some pretty big names involved in real-time rendering, that are contributing to the development fund, Valve, Sketchfab. And if I recall Epic once made a donation.

    Is it possible to reach out to them, and try to get more people involved and have their help/opinion to achieve this?

    If you ever have used UE4, you will be impressed with the viewport performance.

    This will be great when 2.8 is out! Thanks and best of luck!

  11. Sounds really really nice.

    Its really important not to forget the option of Render Layers. Recently the Mill and ILM presented there work with Unreal Engine in a film enviroment. So it would be nice if this is possible too. Also an important feature is to make it possible to play alembic caches in real time!!! Thats a must.
    That would make the blender realtime engine superior in some cases to unreal. Because to work with unreal is a mess when you only want rendered images and not a game.
    Please also take a look at i found it recently and there are nice features in it…. keeep up the good work;) bye

  12. Impressive !

  13. the “Diffuse approximation” image are atom orbitals!

    • just the angular solutions (legendre polynomials) aka spherical harmonics, as they are called in the images descriptions, whats left to make it an atoms orbital is the radial besselfunctions… 😉

  14. For Scene Lights and shadows I would like to see the approach from Geomerics enlighten employed. Real-time baking of light maps with interactivity.

    For shadows, eventually I would like to see usage of newer technologies such as VXGI and could you do vector (SVG) shadow maps instead of bitmaps?

  15. I really hope the developers are keen on concurrent programming. If you’re going for realtime, this new viewport should use every drop of processing power both from multiple cores and GPU. Initially, I thought this was only possible with Vulkan API but Pixar’s demo of USD shows some pretty incredible realtime performance on OpenGL 4. Anyway great stuff!

  16. Are probes/environment textures for roughness going to use different blurriness amounts with each level of blurriness stored at a different level of the mipmap-chain so different levels can be mixed together to achieve full gloss or dullness and mostly anything in between?

    It’s hard to word this clearly… mipmap level 0:no blur, mipmap level 1:stores some pre-blur, mipmap level 2 stores a bit more pre-blur, etc…

  17. So we will be able to define custom shading models for Eevee ? That’s really nice, my main worry was not been able to integrate NPR shaders into the new viewport.
    Is Eevee deferred or forward rendered ?

    Anyway, thanks for all the great work you guys are doing. Everything I’ve seen so far looks fantastic.

  18. Please make sure that you could export the material set up together with the model into UE4 or similar engines, it’d really prove useful and shouldn’t be too hard to implement with the Eevee’s own output node.

  19. The only issue I see in all this is how could I wait for that stuff to be release without going insane !
    This look very promising ! Keep up the good work guys !

  20. The blender render will stil working?

  21. Mwahahahaha! Should be amazing.

    One minor thing:

    A blue hemi light on low intensity is a useful simple way to do a sky light. Just because it’s not realistic for a main scene light doesn’t mean it has no use.

  22. Will this viewport benefit from GPU’s?

  23. Will the material preview of Cycles be the fallback version of Eevee? It would be nice to have that basic functionality without having to switch to Eevee in the engine dropdown menu everytime you want to preview your Cycles materials

  24. Why Eeevee crashes Blender?

  25. Viewing materials on hair and particles will be great.

    Hair please please please plereeeeeease.

    Great work guys

  26. Will eevee be-able to export to fbx?
    I have been using substance painter and quixel to texture my blender models to take into but im finding the fbx/pbr support lacking compared to maya stingray as I have to apply the textures in blender render. Will the eevee update the fbx export to work in a similar way to stingray?

  27. What about interface simplification, I was thinking about one just mesh type!

  28. Please do not break compatibility with BI.

    Also I agree that the viewport main goal should be to get a good approximation of the final rendering. But for this to happen a good conversion of materials plus light matching from the various rendering engines is required. So I guess it will be a long trip to go. The way MODO gets it is impressive and I believe it should be used as reference.

    I like the PBR branch ideas and Armory. A good UE4 exporter/importer would be great also.

    Finally, of course getting a good rendering in the viewport makes all the difference in the world. I believe it can’t be stressed enought. To render an animation in minutes instead of hours is simply a CGI revolution.

  29. When I start Blender, it crashes, and log says Error: EXCEPTION_ACCCESS_VIOLATION.
    But if I start with blender –debug-gpu it works fine.

  30. Anyone know if the Viewport shading will be added?

  31. Sir in eevee mode… shapekeys not working. it would be great if it works in eevee render mode. thank you for great update

  32. I wonder if Blender eevee would do the animation job. I see the animation stuff needs to be improved. (Mesh animation works but Bones? )
    1. Will it work with Unity or Unreal?
    2. Will Bone Animation on Meshes weight painted work?
    3. I am willing to participate in the Test Stage of blender 2.8 “The Eevee Engine” like reporting bugs
    My current feedback for this engine is good enough in terms of graphics.

    Developers tends to do drafts… Me too.

  1. Leave a Reply

    Your email address will not be published. Required fields are marked *


share this story on