Dev:2.8/Source/Viewport/Eevee/Roadmap-CodeQuest-2018

提供: wiki
< Dev:2.8/Source‎ | Viewport‎ | Eevee
2018年4月19日 (木) 17:38時点におけるwiki>Dfelintoによる版 (Created page with "=Eevee CodeQuest Kickoff= This is the list of topic discussed at the start of the CodeQuest. It <i>may</i> not represent the entirety of what is going to be worked on. ==Eevee T...")
(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)
移動先: 案内検索

Eevee CodeQuest Kickoff

This is the list of topic discussed at the start of the CodeQuest. It may not represent the entirety of what is going to be worked on.

Eevee TAA improvement

The temporal supersampling is reset every time the view or one object moves. This translate to very distracting noisy image popping, which is not ideal for most of the workflow (like mesh editing). Unfortunately the anti-aliasing algorithm (jittering the projection matrix) is not compatible with how the outline algorithm works. But we can still jitter the secondary rays directions and lower the overall noise of the screen space ray tracing techniques by reprojecting the previous frame. This maybe a bit tricky because some effects could conflict with such method.

Eevee Lightprobe Cache System

This is some of the most requested feature. Creating a cache system in which we can freeze the current indirect lighting without fear of loosing the result. Also since the indirect lighting computation can be expensive, we can lock it’s update for animation and only rebake on demand. We should also store the cache on disk / in blendfiles, maybe even support for baking over time . We could try to use alembic to compress this data since it’s likely to be redundant over time. The only problem with this is cache synchronisation. If a file uses linked assets from other files, there is no way of knowing if the cache is still valid. But this sync issue is the same for the other cache we have in blender (particles, physics …). The depsgraph should handle the cache invalidation.

Eevee Lightprobes Visibility

This is another usability concern. We want to be able to exclude some objects from Reflection/Irradiance probes. Usually, only static (non animated objects) are captured inside thoses. The problem then is that this assumption only hold for games, and some other application could need more flexibility (probes attached to character). We propose to be able to specify an exclusive or inclusive object group, per probe. This has more flexibility than a simple visibility flag and could be used in complex case.

Background render

We need background mode support for Eevee (-b option) for several reasons. We can easily support a background render mode if there is a display connection (a graphical interface). However, rendering without a display connection (i.e: a headless server) maybe tricky for most opengl implementation. We have to evaluate the feasibility of this.

Vertex Performance

The data format we use for storing the mesh datas on the graphic’s card has a big impact on the performance of high poly scenes. Using thighter formats with some compression tricks could really improve the performance on lower bandwidth hardware at the cost of some precision. This could be a global option in the user preferences or a per mesh/collection option. We agree to consider this only after evaluating the perf and quality impact of such optimisation on a production scene.

Editing Performance

This is an important one. Because eevee is using more data for it’s shading (namely the tangent space) mesh update is quite slow compared to say 2.79. Also this data modification delays the rendering, lowering the framerate. Partial data update (only touch IBO/UV/POS) can be done if depsgraph tells us if the final mesh (with modifier applied) can have its data reused, which is not always the case. This is the most feasible improvement. Range update maybe done in some corner cases (selection being one). But it’s much more involved when we are talking about modifier support. Threaded (non-blocking) updates is too far in the future to be a goal for code quest.

Multi Engine Materials

How material node tree behaves when working with multiple engines. Most external engine use their own set of nodes, or even their own nodetree type. They cannot be mixed with internal nodes. This is only a problem with cycles and eevee where we want to be able to reuse the same nodetree. We agreed on keeping one output node type and displaying every inputs for cycles and eevee. Invalid inputs for the workspace active engine will be grayed out. Active output behaviour remains the same as it is now but the UI for it could be improved (with a button / checkbox to make an output active).

Object Motion Blur

It needs some adjustments to be done in the depsgraph. This will be postponed to after the codequest.

OpenSubdiv

It needs the modifier stack to be ready for it. Also postponed to after codequest.