I am one of them 
I agree, and it looks fantastic. I’m just concerned about performance…
for example texture painting in Eevee on a dense creature with a large map…is something I see extremely handy…but if performance is lacking…and it is not buttery smooth…it sorta defeats the purpose.
Do not misunderstand…I love Eevee and the general direction 2.8 is going…but I still have to ask “are we making the art for interest or interesting art?”
When you developers something on the very beginning you just want it to work. Then you can polish it and improve performance. Blender with some luck will be ready in 4 months. Now it is not in the stage, when we should look at the performance.
1 Like
There’s the old programmer’s adage that it’s not a good idea to prioritize optimization out of the gate, but rather prioritize it after the code is in a working state.
The model used by Blender’s developers is similar, “get it working first, make it pretty later”. It has worked well for them for over 10 years.
2 Likes
and 2.7x performance was never stellar either. I think it is time to improve the performance…not the visual quality.
how many of you have had a scene with a high number of objects only to have to wait several seconds after selecting one…before you can make any adjustments?
polycounts are ever growing…(verts) If you want to do any extremely detailed work in blender you need to rely often on a lot of tricks…instead of worrying about the art it self. This is my whole point.
and I like how everyone suddenly knows how developers work and think…no two developers are the same…and developments plans are also very different from project to project. Please do not act as if you are all in the ‘all knowing’ circle of blender development…you are not. 
1 Like
That’s why they are working on the dependency graph, which now only updates what is needed and it can be multi-threaded. Further, by using a newer OpenGL version, they can also get a performance boost. They are clearly working in that direction!
No two developers are the same, but the ones that finish tasks are usually the ones which first get something to work, before they optimize it! First you have to understand what is needed. Then you can measure the actual performance and find the actual bottleneck. That gives a solid basis for improvements.
The dependency graph is a huge task and they are currently getting it to work properly. It was designed with performance in mind. But if they had started the actual implementation and had constantly focused on the performance, they would be finished in 10 years.
1 Like
What I referred to (the quote) was said by the developers themselves some years back. It’s not pretending to be all-knowing, it’s simply sourcing from what they said.
I do agree that viewport performance in editmode especially needs a lot of work, but 2.8 should have the foundation needed to do just that.
Even Pablo said that I think twice in videos - first devs add think, and when it’ll work how it should, they will start to improve performance for real.
1 Like
you should be concerned about texture painting performance in wokrbench, being concerned about texture painting performance in eevee is same as being concerned about texture painting performance in cycles…
1 Like
I think already said , debug phase which is where Blender 2.8 will require some slow downs to make sure the internals work as expected first. Performance come after that.
Technically you should not be using Blender 2.8 , these builds are for us developers that want to contribute and beta testers that want to help find serious bugs. Beta testers is not even the correct term cause 2.8 is nowhere near beta version.
I got it’s source code yesterday and there is a big chunk missing. You wanna talk about performance that early on ? Seriously ?
You going to be severely disappointed , stick with 2.79
4 Likes
What? Eevee is a realtime viewport, it’s normal to paint textures/ materials in it. Like Substance Painter’s.
It’s not the same as being concerned about texture painting performance in Cycles.
EEVEE was designed as a an internal replacement, it’s a complete rendering engine that emphasizes quality over speed (in contrast to say susbstance’s viewport or most game engines renderers )
I think painting on EEVEE for now is a byproduct of blender becoming render engine agnostic thanks to the overlay engine, maybe the workbench can get a stripped down version geared towrards that particular task in the future, or maybe the devs can come up with something to optimize it better,
At least users sould not expect to get perfect framerates with all the costly effects turned on, samples crancked up or using low end hardware…
ps : untill recently (2017 releases) painting high res in substance was also rather slow
1 Like
Test i did today : translating, scaling or rotating a 8 millions poly model in object mode in the viewport is extremely slow
playing an animation where this model is translated is very smooth
When i parent the model to an empty and move the empty : smooth
Night and day
1 Like
because not all operators have been updated yet
Is it a known problem for eevee to be unable to sculpt with it ?.
When i try to sculpt (i dont have a fancy gpu, i’m pure cpu) then the model screws up, switching back to object mode, then i can see what was sculpted, in short its not possible to sculpt if you cannot see what you do.
(this amazes me a bit since its now used in production by the institute?)
They’ll surely add it soon.
In the last build today, somehow the viewport feels more snappy… 
They know that modifier effect is only working in Object mode.
So currently, no sculpt with multiresolution modifier is possible.
They know that unfinished future overlay of brush on surface is disturbing. You have to disable overlays to avoid it.
And they know that dyntopo may screw up things.
But testing of brushes is still possible without dyntopo.
It is tested in production. But they are switching between 2.79 and 2.8.
Maybe Spring was scheduled a little bit too early if we consider that community feedback done, based on 2.8 daily-builds and Pablo’s videos was important enough to derive a little bit from first proposals.
Spring will probably not be the ultimate test of 2.8.
But it should still be in production to validate basics for 2.80 beta. Spring team will be able to expose what a user should expect from first beta.
There are still months or years of work before every corner of 2.8 will be polished.
So its not that there are technical impossibilities, eventually live sculpting using eevee render (with mesh overlay) would becomme possible ?, that would be so awesome.