Eevee is awesome in the balance it provides between quality and render times. But it has a little annoyance when it comes to rendering, which might also be a missed performance improvement: There is no support for tiles, everything seems to be rendered at once. Further more, Blender is completely frozen during an Eevee render… you can’t even press esc to cancel it until it’s finished.
I was wondering if support to render with more verbosity is planned. I know Eevee uses the GPU… not sure if OpenGL directly, but clearly not the same system as Cycles which requires CUDA / OpenCL (a bummer for Linux users). But can it support the old model of one CPU / GPU thread per tile? Obviously this is just useful if tweaking the tile size can offer a noticeable variance in performance.
What about the total freeze too? Both in the old Blender Internal and Cycles, you can still play with the menus or press esc to cancel while rendering is ongoing. With Eevee however the whole Blender process is unresponsive till rendering has finished… which probably means that if by accident you manage to use excessive settings that would take an hour to render, you’re gonna have to kill the blender process if you don’t wish to wait that long (haven’t tested this directly of course).
I really don’t know if tiles is possible. You remember that many things are screen space dependent with Eevee, I’m not sure how tile borders would be handled in that case.
I know that it may not be technically the same, but the time I did an experiment dividing the scene into many cameras simulating tiles, it was a headache at the edges/border for each camera. On each render corresponding for one of the cameras I had to set up a large overscan area for better border matching, which greatly increased the final rendering time and made the process impractical at all.
Exactly, and the reason why Eevee has a number of screen-space effects is because there’s no other way to get the equivalent while keeping everything interactive (even with cards like the RTX 2080).
It might be possible to split the renderer into tiles if there was a way to find the optimal amount of overscan for each of them, but any chance of ensuring users don’t face a tradeoff might require the integration of RTX and/or related tech (as a ray is able to access any point in the scene).
Very correct, I actually didn’t think of that: Screen space effects are a requirement for several of the graphical features, which might not be doable with tiles. A tile at the bottom might be reflecting something at the top (or vice versa) which would need to be rendered first. Only way would be with multiple passes, with screen space effects first then the normal world being rendered… which itself might decrease performance thus defeating the purpose.
What about Blender not freezing completely during an Eevee render, allowing the user to operate other menus and most importantly cancel a frame without having to wait for it to finish? I take it a progress bar could also be supported if and when this is solved?
As it seems that people here are doing some weird tricks to open new blender instances to render faster, and even splitting the work like that to multiple cards
It makes me think that rendering passes with same idea would only increase performance and there could even be blender setting for how many instances of eevee render do I want to do, right?
and then, progress bars for each of them would look pretty cool
