In the following article we would like to talk about the upcoming realtime engine (well-suited to create 3D configurators) called Eevee by Blender 2.8. Eevee will follow the trend of the faming industry and support high-end graphics in combination with a responsive real-time viewport.
The following video illustrates the features of Eevee:
At that time it was a bit early to discuss the specifics of the project. But that time is now over, the ideas are mature and it`s time to talk openly about the Eevee-Roadmap.
Lighting the scenes.
The first goal is to support all realistic Blender light types.
We start with the support of diffuse point lights. Unlike the PBR industry, we make sure that adding/removing lights in the scene does not slow down. For the tech fanatic: We use UBO (Uniform Buffer Object) with the scene light data to prevent recompiling the shaders.
Next, we can support mirroring in the shaders and add area lights to the light support. The implementation means that we extend the GGX shader to include the UBO data.
We will also have to rework the light panels for the Eevee settings, as not all settings make sense in real time.
Soft shadows.
Like everyone else, we like our shadows as smooth as possible. The realistic smooth shadows are computationally expensive. For the realtime mode of Eevee we follow the shadow buffer implementation we now have in Blender. For offline sleeve rendering (e.g. Playbast) we can raise the bar.
Regular materials.
About shaders.
Things are bright and good, but we still need materials to respond.
We will implement the concept of Uber shaders based on the Unreal Engine (UE) 4 PBR materials. Since the goal of Eevee is not feature parity with UE4, you shouldn`t expect to see all UE4 over shaders here.
A 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 that can be used by the engine.
Multiple engines, one material, what to do?
A material set up for cycles that doesn`t have an Eevee PBR node should still work for Eevee, even if it looks a little different. So although we want to support Eevee`s own output nodes, we`re planning a fallback solution that supports other engine nodes.
Convert / Replace blender internally.
After we have a working pipeline with Eevee, we should look at the compatibility of old blender render files. However, the cycles fallback option should be enough to get users to get into Eevee from the beginning.
Advanced materials.
Advanced techniques will be supported later, such as
- SSS
- clear coat
- volumetric
Image Based Lighting.
We will support pre-rendered HDRIs followed by in-scene on-demand generated probes. Thus the scene objects influence each other (reflections, diffuse light…).
We need the viewport to always be responsive and show something while the probes are being calculated. Spherical harmonics can be stored in the .blend to allow fast loading during probe generation.
Time cache should also be considered for responsiveness.
Shiny rough shaders.
We cannot support high gloss with Roughness Reflections without pre-filtering the probes. Otherwise we get a terrible result.
Diffuse approximation.
There are several ways to display the irradiance of the scene, such as cubemaps and spherical overtones.
The more accurate way is to use a cubemap to store the result of the diffuse shader. However, this is slow as it requires the calculation of the diffusion for each text.
A well-known compromise is to store low-frequency light information in a set of coefficients. This is faster (and easy to handle), but fails in corner cases (when the lights extinguish themselves).
Eevee supports Spherical Harmonics, so Cubemaps are only available for baked Speculars.
Probe objects.
Like force fields, probes should be empty objects with their own character code.
Environment Map Array.
Large objects may require multiple probes to correctly represent the environment. In the Unreal environment, the map array handles this on supported hardware. This is not compatible with OpenGL 3.3 Core. We can continue to support this on modern graphic cards. But we should look for alternatives that are 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
- Reason Truth Ambient Occlusion
Other effects that we would like to implement
- Temporal Anti-Alias (to repair the noisy fireflies we get from the shine)
- Screen Space Reflection (more accurate reflection, helps ground objects)
Epilogue.
The core of the features mentioned here will be implemented by Siggraph 2017, with a more sophisticated version from the Blender Conference.
The Viewport project (whose core is Eevee) will be developed in Blender 2.8. It`s still a bit early for massive user testing, but keep up to date on further updates.
Leave A Comment