There is some news on https://thisweekinblenderdev.github.io/, but it’s hard to tell what’s going to be done next week or two next weeks. On one hand, I would like to see a list of thing that are missing/are taken from blender to be rewritten from scratch/are done already, on the other, I think it would be very hard to make one and to follow it.
But I just think that people these days do not read anything with attention. Just to download Blender 2.8 you have to click “Lates experimental build” subpage on a red background, just under the text “These builds use the latest snippets of magic code developers write. Give the upcoming Blender 2.8x a try! Although it is absolutely not recommended for use on production environments.” with “Go Experimental” title. Then, inside just above the download Blender 2.8 button, you have again, warning: “Currently we are aware of many issues in 2.8 and actively working to fix them. Since replying to reports takes time, we have decided to limit bug reports to module team members.” English is not my first language, but I can understand clearly, that it is in so early development stage and there is sooo many lacks, bugs, and glitches, that just reading reports about them would take most of the development team days.
Indeed it is - but with 2.8 still being at such an early stage - anyone critiquing it won’t really know if they are commenting on a genuine bug or simply a feature that has yet to be reinstated or finished.
Once the devs think they have the software in a reasonable state - they will release an official beta for people to feed back on. At the moment most feedback to the devs would probably be met with “yep we know about that and we’re working on it”.
It is also possible that complaints about 2.8 are starting to drive developers up the wall as well.
No, I know. I just wanted to see what it’s like. My biggest complaint are not the bugs (I get it is really early) but with the new UI and user stuff that seem to make it impossible.
The UI and UX are not more ready than anything else.
This is true - and if they get too bad, the devs may decide not to do preview builds like this which will be a real shame.
Look peeps. 2.79 is the current official version - if you don’t like bugs, incomplete features etc - then don’t use any build beyond official 2.79.
Use any build beyond official 2.79 and fully expect to encounter bugs or incomplete features. That’s just the price to pay for the devs being open and gifting us preview builds.
everything is open to criticism. I have said it somewhere on the forums before…sometimes in development you get so caught up in your idea that it makes no sense to the end user…
Now say you never let anyone criticize it during all those hours of development…only to find it is total garbage…or even worse it is fantastic…but no one understands it because you were not allowing people to criticize it??..criticism is valid whether we know if it is a planned feature or a bug. I get the impression that sometimes you just feel the need to be ‘right’ or…ok, I have no idea what goes through your head, but you certainly come across an an ass at times. I’ll just leave it at that…I’m almost certain you will have something to say, but I will not respond…I feel this is enough distraction from the thread and not really helpful to anyone.
You absolutely should not bother developers with bug reports until they’re ready for them. If a developer thinks their code is good and you find errors, that’s noteworthy. If a developer knows their code is still a mess, beating them over the head with issues you’ve found is just an annoying waste of time. This is the exact reason that alpha, beta, and RC processes exist. 2.8 is still in early alpha days. If this weren’t an open source project, it’s likely that people wouldn’t even know about it. Open Source devs just have the unenviable reality of users being able to play with their blemished code to deal with. Unless they’re asking for feedback, it’s best to just let them work. Blender has a great code review system these days, and teams of vested internal people doing meaningful testing. If they don’t catch something by the time 2.8 makes it to beta, then is the time to make a complaint or report.
That is certainly true. But this was not the point I was making. Whatever…
I just don’t see the logic behind a rule that EVERYTHING is open to criticism. Criticism is a part of feedback. Feedback is very important thing in many areas of life. There is no failure, there is only feedback as they say. It is extremely important to get feedback in any kind of design process, yes, that is most definitely true. However, it is logical to see some sort of results and provide the feedback for the results or the process that led to them. There are no results at the moment. The builds let the developers see what they are doing and we can download and have a look as well, that’s all. Users cannot understand what is going on in there and are not supposed to. You cannot provide meaningful feedback if you do not understand what is going on, can you? Unless you are a developer there is no way of knowing why and what things are as they are and how they are being changed or worked on. How is choosing to ignore this useful for the design process in any way? It is not, the way I see it. It’s pointless if not harmful. It could be harmful I imagine. I imagine it should be like having a five year old looking over your shoulder when you start modeling a character: ‘Why is there a cube? Why is it grey? Why is there nothing around? There are no shadows. Why are there no shadows? Where is his head? Why are you making his feet without toes? Why doesn’t he have any arms?.. Why are you making only one side?..’ Come on… This is ridiculous. It’s not time yet. There will be time for feedback. It’s not that it’s open or closed for criticism, criticism does not apply yet. There is nothing to criticize now as there are no results yet.
If hardware constraints are too tight (requiring a specific architecture to do anything), I wouldn’t be surprised in there being a following if an LTS fork was created on the 2.79 codebase. (Not everyone shells out for the latest hardware still supported by the manufacturer, and some computers like laptops aren’t always easily upgradable.) I’d also think that some people would prefer trying to make or use something bulletproof and more polished in the rough spots over implementing shiny new toys.
Maybe that’s something that should be considered for users and devs finding 2.8 not working for their needs despite all the spiffy new features. The one downside is how much cross-compatibility would there be longer term?
Just mentioning it because the few times I’ve tried 2.8 on any computers it doesn’t work at all. If that’s still the case, I’d prefer to use something that does. A less buggy 2.79 would satisfy that requirement.
I remember very clearly when 2.5x came out. It takes take to port over all (or most) features. In between several releases, *.blend files were not compatible, and games built for one version wouldn’t work on others at all. It wasn’t until 2.6x that all the major core functionality was ported over. 2.7x series continued to add more wonderful functionality.
Similarly, the 2.8x will first focus on the major functionality (ie 3D Viewport). Only when the underlying technology works, can stuff like BGE be added, this is logical and obvious. It took several years for 2.6x/2.7x to be feature complete ---- Blender does lack audio, raster2vector, music creation (and others) abilities ---- But the core base code is there. You just need a capable knowledgeable programmer.
Even though OpenGL 1.4 / 2.1 is “old”, it has several benefits. First, it is widely available on nearly all GPUs. Second, programs written with it is stable and just works. But with OpenGL 3.3+, the complexity leads to more erratic behavior. It works better (if at all) on certain high-end GPU brands. The major benefit however, is you can utilize the full power of modern GPUs.
Last time I did a thorough test on my mid-high range Gaming Laptop, running the installed Windows 10 + Nvidia drivers. EEVEE took a long time to load / compile the blend files. But it handled those large files with ease in Viewport. But rendering in EEVEE wasn’t anywhere near real-time. I’m not complaining.
If I remember correctly, EEVEE is based on Unreal Engine’s render code, which was released as GPL. So we should expect to see similar gaming performance in future. It should also take a few years. In the mean time, you have 2.7x or even 2.6x to rely on. As a long time blender user, it took me a while to “forget about” blender 2.49b. Several years ago, I took the leap, worked hard to learn about 2.7x. That decision was a good one. 2.6x and 2.7x works now, you can use it for your projects until OS and hardware stops support for it. For now see how you can give back to Blender and the community. 
I got the impression that most hardware supports OpenGL3.3 and that it is available on nearly all GPUs. The technology is 8 years old. It’s not like it’s unreasonably new and only high-end hardware supports it as it may seem reading what you wrote. I don’t think that is a serious problem to be honest. If somebody is using something that does not support it for work with 3d it is reasonable to say that it is in their best interest to upgrade anyway.
Perhaps Eevee will be unusable to work with heavy scenes with old not powerful but still supported GPUs. That is why it is also necessary to have a light engine designed to work and performance (supposedly 2.8 will have that Workbench engine). So if you have an old not powerful GPU but supported, you can continue working on that lightweight Workbench engine in 2.8, and for example then render in Cycles with CPU or even render in Eevee if it is still advantageous vs Cycles.
By the way, it would be great if that lightweight Workbench engine also had a simple/basic (but nice) Material view mode.
Edit:
Trying this scene with intel HD4000 iGPU on Linux:
This is really slow, it takes around 5 minutes to open the scene to compile materials and to calculate Irradiance Volume. All the OS goes slow while eevee/gpu works. Then it is very slow (almost impossible) to work in Eevee, play animation run at 1.2 fps. In any case, the scene looks the same than with nvidia. And Render Image at 1080 takes about 1:36 minutes. So it’s still very fast compared to Ray Tracing.
(Right click over the image and view/see image to open at 1080)
hi, and this is not a really heavy scene.
Clément is working on reduce loading time:
https://developer.blender.org/rB47cfdb3c0ce62d3ceba8b52c3cf276e7562e361a
Cheers, mib
I am running an i3-4150 3.45Ghz cpu with a NVidia GTX1050 Ti 4GB GPU and one of my scenes is just the same. Takes forever to to process the file as it loads and then is unusable as a viewport (OpenGL 4.5).
I am guessing it’s just the way it is at present.
Hi mib!
Yes, surely there will be many improvements and optimizations. But I really think that those with old or low end cards should not expect to work fluidly with Eevee. For performance it is supposedly Workbench engine designed.
Anyway, if developers can optimize Eevee to the level that it is even possible to work with those GPUs, well, much better then.
You may need to adjust your expectation of a “heavy” scene. First of all, all materials need to be compiled, which can take a while and that depends on your CPU and your driver, not so much your GPU (though a low-end GPU may well be harder to compile for). Secondly, with all its lighting features, Eevee is “heavy” by default, even if it’s just rendering a single cube. Every pixel becomes expensive.
The minimum version of OpenGL has little to do with that, you can totally nuke a low-end Intel GPU that purportedly supports OpenGL 4.5 with a shader that is written to OpenGL 3.0 (or even 2.1) spec.
It’s the CPU side that will be slowing me down, only being an i3.
I’m not sure about that, but I’ve done a test with the scene above. When I open the scene my system monitor shows only one CPU thread working at 100% at the same time while compile materials, so for now it is single thread task. While compiling materials, the system runs smoothly, so I do not think it uses GPU intensively there. Then at the end of the compilation of materials, when the scene begins to calculate lights and mainly irradiance volume, the operating system slows down and hangs a lot (with HD4000 iGPU), so at that point I think that it starts to use GPU intensively. So when materials are compiled, any future slowness depends primarily on the GPU.
So apparently it’s like BeerBaron said.
Luckily for you, your i3-4150 seems to not have a bad single thread performance:
https://www.cpubenchmark.net/singleThread.html
Edit:
By the way, using nvidia GTX 960, CPU also uses a single thread, but the materials are compiled much much faster. So I think that GPU is also used for this.
Don’t expect too much improvement as far as utilizing CPU threads. Multithreaded GPU task management is notoriously difficult and buggy with both DirectX and OpenGL. In fact, the major selling points of (and the impetus for creating) Vulkan are the ability to be more granular with your GPU/CPU workload, and the fact that all shaders are precompiled into SPIR-V bytecode. Perhaps some day we’ll get a Vulkan Eevee port.
Must admit, looked at the max my m/board could hold, but can’t really justify i7 costs, did contemplate shifting to an i5-4690 but not sure my 550w psu can handle that alongside the GTX1050-ti.