But realistic smooth shadows are computationally expensive. We all like our shadows smooth as a baby butt. We will also need to rework the light panels for the Eevee settings since not all settings make sense for realtime. The implementation implies we expands the GGX shader to account for the UBO data. Next we can support specularity in the shaders, and expand the light support to include area lights. For the tech savy: we will use UBO (Uniform Buffer Object) with the scene light data to prevent re-compiling the shaders. Unlike the PBR branch, we will make sure adding/removing lights from scene doesn’t slow things down. We will start by supporting diffuse point lights. The initial goal is to support all the realistic Blender light types (i.e., all but Hemi). Time has passed, the ideas matured, and now is time to openly talk about the Eevee Roadmap. Sci-fi armor by Andy Goralczyk – rendered in Cycles with outline selection mockup, reference for PBRĪt the time it was a bit early to discuss the specifics of the project. Eevee will follow the (game) industry PBR (Physically Based Rendering) trend, supporting high-end graphics coupled with a responsive realtime viewport.
In the last post about the Viewport Plan of Action we ended briefly covering the upcoming realtime engine of Blender 2.8, nicknamed Eevee.
