Dev:2.8/Source/Viewport/Eevee/Roadmap-SeptDec-2017

提供: wiki
移動先: 案内検索

Eevee Planning 2017

September 2017 to March 2018 plans: Discussed the 14th and 15th of September 2017 with Clément Foucault and Dalai Felinto at the Blender Institute.

Overview

The plan for 2017 is to prioritize the main usability issues and the main Eevee remaining features.

For the first part of 2018 the focus is on wrapping up the remaining minor features in Eevee, as well as tackling the workflow oriented task.

That leaves the second part of 2018 for optimisations and polishing of existing features.

We will re-visit this plan at the end of each quarter or even earlier if we drift too much from it. The idea is to get the big picture planned for the upcoming quarters, and have a nitty-gritty week-by-week plan of the current quarter at any given time.

Sep

Week 3

  • done
      Anti-aliasing

Week 4

  • done
     Probe Polish
  • in progress Inprogress50.jpg 50%
     Proper Depsgraph handling of Probes and lamps update

October

Week 1

  • done
     Contact shadows (2d)
  • done
     Gawain problem (2d)
  • done
     Shader compilation time (2d) (was a failure)

Week 2-3

  • done
     Volume Object (10d)

Week 4

  • done
     Bug fixes for Blender conference demo (5d)
  • to do
     Final design for multi-engine material by Blender conference [Dalai]

November

Week 1-2

  • to do
     UI Implement multi-engine material [outsourced]
  • done
     SSS (10d)

Week 3

  • to do
     Object Motion Blur (5d)

Week 4

  • done
     Fix Grid Light leak (5d)

December

Week 1

  • to do
     New DoF (5d)

Week 2-3-4

  • 3 week vacation (15d)

2018

January

  • Shader compilation lazy (5d)
  • Frustum Culling (3d)
  • Render Output (F12) (7d)
  • Multi-window (5d)

February

  • OpenSubdiv (10d)
  • Instancing (10d)

March

  • Hairs Drawing (stripes or strands) (5d)
  • Particles (5d) : Pipe all rendering particle attr to eevee / Optimize rendering.
  • Bug fix / Polish for beta (10d)

Future Plans

Features

  • Material Preview (4d)
  • Batch render (headless) (5d)
  • GTSO (5d)
  • Viewport compositor (1-2m)
  • Shaded UV view
  • Vertex Shader Material
  • Parallax Occlusion Mapping
  • Pixel depth offset

Polish

  • Proper Refraction Math (5d)
  • Documentation for Eevee (10d)

Optimization

  • CPU optimization (BW usage in DRW) (5d)
  • Cluster Forward Shading (5d)
  • GPU Optimisation with Compute shaders


Detailed Tasks

Anti-aliasing

First Implement the FXAA in draw manager (already done by cmr but only for eevee). Then Implement TAA in Eevee (accumulation buffer). Then if times allows, try adding motion vector reconstruction to TAA for animations.

Irradiance grid

Current irradiance grid is displayed with uninitialized memory. We should clear the grid first and then use some progressive rendering to allow fast preview. Ideally the process should be display in the top bar.

Proper Depsgraph handling of Probes and lamps update

We need a way to efficiently trigger probes and shadowmap rendering. Current way involves keeping track of objects themselves in Eevee which is dangerous and against Depsgraph design. This could be done during evaluation phase.

Contact shadows

Currently VSM and ESM have problems with light leaking. One easy way to fix this is to use screen space raytracing against depth buffer to find occluder. This really helps but still suffer from the same thickness problem the SSR have.

Gawain problem

Every time a shader is compiled Gawain is asking for the full list of uniform and their location. The problem is that the UBOs used by eevee containing lamps and probes data are seen as 1000’s of them. This adds an overhead of 30% to the wait time when compiling. We should be smarter and only query the uniforms we need.

Shader Compilation Time

The compilation time is getting higher and higher as we add new functionalities. This is mainly due to for loops that the driver needs to optimize. By doing manual unrolling of these loops via some compile time Macros we might be able to reduce it.

Volume Object

We need to see volumetric objects in the viewport. Doing smoke domain is simple but I would like to try to implement some volume object (creating a distance field/volume representation of the object then evaluating the volume shader if ray is inside the volume). Optimizing the rendering is also needed as the overhead of such technique will be really high.

Final design for multi-engine material

At the time of writing, all the node is identical no matter what render engine is used. But what if we want to use a different output node for each render engine. This task should make it possible to have a different node setup for every render engines.

Subsurface Scattering

We need to review and think about how to implement it in Eevee. This will surely have some limitation compared to the cycles shader.

Object Motion Blur

Current motion blur only support camera based motion. We can easily add a motion vector pass to add object animation support to motion blur. This will not work with skinned or deformed object.

Fix Grid Light leak

Grid probe is currently bad at handling walls between grid cells. Light from one side of the wall can bleed onto the other side. To fix this, we must encode some visibility information alongside the color information.

New DoF

The current DoF algorithm is a straight port of 2.7x high res viewport Depth of field. It has bad limitation and has not a perfect look. This new dof may be even slower but it will not have these limitations. This could be used for render time.

Lazy Shader compilation

Compiling shaders in Eevee can takes up to half a minute of loading time a for complex scenes with lots of materials. The goal is to make this process non blocking and make the interface responsive even if all the shaders are not yet compiled.

Frustum Culling

This is an easy optimisation that was present in pre-2.8. We just need to discard all objects outside of the view frustum.

Render Output (F12)

We need to make Eevee capable of outputting a rendered frame (hitting F12) ensuring maximum quality with a dedicated code path. Renderlayer and data passes (Z, motion vectors, …) support should be tackled at this point

Multi-window

There is a low level problem with multi-window support. For more information go see T51736

OpenSubdiv Integration

We need to bring back OpenSubdiv to all realtime engines. This will require quite a bit of tweaking of all engines shader code.

Instancing

For enabling fast drawing we should rely on instancing as much as possible for dupligroups, object duplis, objects with same mesh data. This requires some changes in DepsGraph and how we handle dupli-objects etc.

Hair Drawing

Hair drawing is currently supported but really slow. We should aim for a more performant solution. Also investigate better hair shading.

Particles

We need to make Eevee compatible with Particle attributes. This is also a good oportunity to optimize the rendering of theses. GPU Optimisation with Compute shaders Some areas in Eevee can be made faster using compute shaders (probe filtering, AO, SSR, ...). But this requires a bit of work to take benefits from it. Also note that this is only a OpenGL 4.3 feature.

Cluster Forward Shading

This is an optimisation technique that allows to render lots of lights in a scene without evaluating them for the whole screen. This means better performance.

Viewport compositor

This is a huge project, make the compositor run on top of the viewport in realtime. This means porting all the compositing nodes and logic to Opengl/GLSL. Not all Compositing nodes will be compatible for real-time display and some may have lower quality fallback.

Shaded UV view

The UV view could have a shaded display option so you can easily identify each part of the unwrapped model. This could also be a preview of baked texture.

Vertex Shader Material

GLSL allow us to manipulate vertices manually before drawing them. This can be used for creating various effects, such as wind effect for vegetation, in a more efficient manner than using modifiers.

Parallax Occlusion Mapping

This would be implemented as a dedicated node. It help create the illusion of a carved surface without any additional geometry.

Pixel depth offset

This feature can allow to refined blending with other geometry on a per pixel basis. This can also help NPR artists to sort 3D object.