I do reuse a lot of code. But a lot of the core components that have been hacked over the years to accommodate EEVEE have now been rewritten to not be hacky and support more extensive feature.

Now that I think of it, I’m just taking the time to do some of the ideas I had in mind at the start of the first EEVEE.


Vulkan is not a top priority as the incentives to adopt it are pretty low. The only interesting feature that would be nice for us is hardware raytracing and maybe mesh shaders.

However, it is definitely on the roadmap and we plan to replace OpenGL completely with it.

But I do note that this question is kind of off topic. So I won’t be discussing more about Vulkan here.


Your post falls into the feature request category which is not really appropriate for this topic I created for feedback about what I’m working on.

The first two features are already planned but we lack the resources (developer time) to bring them up to life.
The next two are just not possible with the resources we have. Every real-time engine went into the temporal denoising to increase fidelity. As for the optimizations, many are not possible but we are always looking at how we can improve on specific areas.
I guess the ability to bake meshes is a typo and you meant bake textures maps. This is not part of EEVEE but may be in the new texturing workflow roadmap.
The last one is too specific. But might also be related to the texturing workflow.

1 Like

Thanks for the response, sorry if this wasnt the right place for this sort of feedback.

I would argue that it isnt necessarily a very specific usecase however, its common in all industries to want access to separate render passes for compositing, maybe I just put it in an odd way describing more specifically what I would use it for.

Does this mean that Eevee Next will run on the Mac using Metal, and on the PC it will use OpenGL?

1 Like

Yes. As of today, that is the plan.


Giga awesome. Thanks.

And except for the internal coding improvements we EEVEE Next users can expect. I say this because if the majority of requests is to finally integrate vulkan and raytracing and it is not in the short term planning.

This post covers some of the goals.


But is it still coming for 3.2 or it will be pushed further back? It sounds it still has a long way to go…

you can see the progress here

But with all the added delay and without much real testing possible (because of feature incompleteness and plethora of TODOs) it was starting to feel like a never ending project. So we decided to start pushing the developpement into master in an attempt to guide the developpement using feedback from the Blender Studio. The new implementation is hidden under a new experimental option (rB59f53f580227). My goal with this is to merge the eevee-rewrite branch into master bit by bit making sure each feature is polished.

Oh, you must be the developer because you replied and confirmed that it is indeed coming to 3.2. Can you tell me how do i build “eevee next” ?

It is hardly coming for 3.2 given my workload.

You don’t need to build anything. It is in master and hidden behind an experimental switch as written in the original post. But as of now there is nothing drawn on screen.

The experimental branch eevee-rewrite is not something I can consider usable at all.

1 Like

That’s great news! :+1:

1 Like

Great whenever it comes!

Is there going to be any improvement to irradiance baking in the rewrite?

Please keep the thread on topic.

The status of Vulkan support is not directly related to EEVEE Next, it’s a separate project. This thread is for Clément and other module developers to communicate the status of the render engine.


Thanks for all your efforts! :slight_smile:

From this post, what should we expect to be on master in the short-mid term?EEVEE’s Future — Blender Developers Blog

1 Like

“The first two features are already planned but we lack the resources (developer time) to bring them up to life.”
I don’t know how willing they are but the group behind the BEER/MALT engine maybe able to help ?
Have you tried contacting them ? i’m sure that something can be done and that the community can fund it like they funded the developement of BEER/MALT engine.
Their imput would also be really needed since Eevee suffer from certain limitation concerning NPR.

1 Like

Very happy to see this come into master as an opt-in experimental - we will be able to keep building custom in-house Blender builds for production from master and occasional test this out! I’ll be keeping an eye on it. Big Eevee user here!


Hi, perhaps this is dumb question, but I haven’t been able to find an answer on developers portal nor blog posts, so I’d like to ask here.
In Eevee next, will following “issue” be addressed?

  • during viewport playback or when navigating viewport it allows only one sample, therefore antialiasing is gone and AO and other effects dont work properly. (Denoise doesn’t help much, it erases a lot of details).
    I’m using blender for interactive presentations alot and this is a real downer. Also I believe it’s very relevant for VR\AR as well.
    I’ve heard about possible transition to deferred rendering, so perhaps that would somehow help, or allow for more samples\frame during playback with strong graphic card?
    Thanks for any hints.