eevee next is in the alpha (3.5)
1 Like
only if the size of the passpartout is equal to the 3dView size or smaller , wont scale up on zoom in
This is amazing. That’s it, it’s all in the viewport. I love it.
Does Eevee Next support global illumination? Is there a document with all the new features eevee next will bring to the table compared to old eevee?
It’s supposed to support GI. You can see the planned features here: https://developer.blender.org/T93220
6 Likes
This has been a long ride but…
The new shadows (maps) have been merged!
Note that this isn’t the whole new shadow implementation. Other shadow related features will come later.
For instance current implementation is lacking soft shadows.The benefits of the new implementation:
- Fixed shadow budget (user controlled)
- High number of shadows maps (4096 visible instead of less than 1024 per scene) without per light type restriction (there can be 100 sun in the scene now)
- Cached directional shadow (less costly when navigating)
- Improved scalability (simplify option)
- Optimized shadow map density (precision is put only where it is needed)
- Really high precision / sharp shadows (up to 8K shadows per cube-face projection)
- Less peter-panning artifacts due to shadow bias
- No more self shadowing artifacts (but aliasing is still present)
- Less quality settings to tweak (no more cascades control, bias, high bit-depth) because quality is adaptive
Downsides:
- Needs big shadow pools allocation upfront that cannot be shared between viewports.
- The rendering of the shadow-maps is more expensive.
- Sampling them is a bit more expensive.
There is 3 ways to hit memory limitations:
- If the shadow pool is bigger than what the GPU can support, then performance could degrade drastically as it will start to swap the textures to CPU memory or even to disk. The application could also run out of memory and quit unexpectedly.
- If there is many visible shadow enabled lights in the current view, then it is possible to run out of shadow mapping tiles. This results in missing shadow tiles and an error message will be displayed in the viewport.
- Too many shadowed lights might result in completely missing shadows on some lights.
This implementation of virtual shadow mapping was not as straight forward to make and required a lot of refactors of the draw manager to be made efficiently. The implementation itself was rewritten twice and the project grew in complexity. Along with that came other projects that needed my attentions. Future updates will be more regular.
There is still discussions about whether or not we will add some more parameters:
- Maximum resolution: Would allow adding a higher bound to the quality of sun shadows. This could be split between volume and opaque options as volumes might ask way too many shadow pages.
- Normal Bias: The new shadows being way sharper than previous implementation, it makes the shadow terminal problem much more noticeable. This bias would be a way to avoid this artifact. We cannot provide a per object solution like cycles does, so we have to make it either a per light option or a global per scene / render option. The later is preferred for simplicity of use.
23 Likes
I heard something about faster eevee in the latest blender today stream, but don’t know if that was relaetd to eevee next or not. I’m out of the loop, does old eevee still recieve updates?
Eevee next is supposed to replace Eevee and I don’t think there are new feature planned for Eevee.
Most users will probably won’t make much difference, we switched to CycleX, grease pencil 2.0 (recent refactor) and a GP 3.0 is on it’s way. There is also workbench next !
All these are fancy name for major rewrite/updates. But the main features stays very similar.
About performance boost, for sure, in general these rewrite aim (for user POV) for better performance and better quality ( =allow more features) but of course like here sometime better quality means worse performances. But since other areas will be improved , hopefully it will be globally faster !
5 Likes
potentially were you hearing about how apple systems got a metal backend which gave eevee a boost? although its less that anything changed in eevee itself and more that apple replaced a deprecated api on their platform that was getting increasingly buggy and likely hurting performance.
1 Like
Question is, what more can they do with workbench as far as features and performance go?
Yeah, TBH I didn’t give that project a close look, but from my understanding for workbench it’s more about updating the code to the changes eevee next will bring, rather than bringing a lot of new functionalities.
But we’ll see, eevee next too in some way is more about allowing new features rather than implementing all of them.
1 Like
Lots of 2.79 users find certain thing about 2.80+ viewport to be inferior, less helpful, less useful. For example people want to have the areas outside of the render preview box as solid or wireframe. Many people want the object color to be automatically overidden by the color value in the material that is closest to the material output node. I personally want the solid textured workbench view to respect the texture mapping node values.
1 Like
Normal Bias: The new shadows being way sharper than previous implementation, it makes the shadow terminal problem much more noticeable. This bias would be a way to avoid this artifact. We cannot provide a per object solution like cycles does, so we have to make it either a per light option or a global per scene / render option. The later is preferred for simplicity of use.
I’m sweating bullets thinking Grease Pencil objects will not be able to make this easy for EEVEE.
In other words: Will a grease pencil 3.0 object work with this in the future?
Also: It looks like great news for Sun light.
I asked for that too, but the answer was that such feature would introduce big lags in the drawing of the frame
It looks like shadows for GPO is beyond compatibility task scope.
The task for Workbench Next
In fact, those Next tasks are about making what exists compatible whit a new draw manager.
https://archive.blender.org/developer/D15817
What is expected is mainly better culling, better instancing, less complex draw calls.
So, probably, result for user should be faster display and less culling, hiding issues on modern GPUs.
1 Like
Thinking of this… maybe if the jobs done during that lag could be cached as eevee does…
I don’t do animation so I wouldn’t care if it lags. It could be a viewport setting: Follow Mapping Nodes (warning, lags the viewport)
This has been a long ride but…
The new shadows (maps) have been merged!
Note that this isn’t the whole new shadow implementation. Other shadow related features will come later.
For instance current implementation is lacking soft shadows.The benefits of the new implementation:
- Fixed shadow budget (user controlled)
- High number of shadows maps (4096 visible instead of less than 1024 per scene) without per light type restriction (there can be 100 sun in the scene now)
- Cached directional shadow (less costly when navigating)
- Improved scalability (simplify option)
- Optimized shadow map density (precision is put only where it is needed)
- Really high precision / sharp shadows (up to 8K shadows per cube-face projection)
- Less peter-panning artifacts due to shadow bias
- No more self shadowing artifacts (but aliasing is still present)
- Less quality settings to tweak (no more cascades control, bias, high bit-depth) because quality is adaptive
Downsides:
- Needs big shadow pools allocation upfront that cannot be shared between viewports.
- The rendering of the shadow-maps is more expensive.
- Sampling them is a bit more expensive.
There is 3 ways to hit memory limitations:
- If the shadow pool is bigger than what the GPU can support, then performance could degrade drastically as it will start to swap the textures to CPU memory or even to disk. The application could also run out of memory and quit unexpectedly.
- If there is many visible shadow enabled lights in the current view, then it is possible to run out of shadow mapping tiles. This results in missing shadow tiles and an error message will be displayed in the viewport.
- Too many shadowed lights might result in completely missing shadows on some lights.
This implementation of virtual shadow mapping was not as straight forward to make and required a lot of refactors of the draw manager to be made efficiently. The implementation itself was rewritten twice and the project grew in complexity. Along with that came other projects that needed my attentions. Future updates will be more regular.
There is still discussions about whether or not we will add some more parameters:
- Maximum resolution: Would allow adding a higher bound to the quality of sun shadows. This could be split between volume and opaque options as volumes might ask way too many shadow pages.
- Normal Bias: The new shadows being way sharper than previous implementation, it makes the shadow terminal problem much more noticeable. This bias would be a way to avoid this artifact. We cannot provide a per object solution like cycles does, so we have to make it either a per light option or a global per scene / render option. The later is preferred for simplicity of use.
Edit: There seems to be a driver issue affecting AMD GPUs which makes shadows not work at all. This has been reported and is being worked on by AMD.
10 Likes