I was just comparing the speeds of the Rendered view between Blender 2.79 and Blender 2.8. I tested a very heavy scene with lots of textures and polygons and Blender 2.80 takes much longer until the first sample appears (more than twice as long).
2.79 - 32 seconds
2.80 - 75 seconds
The “Initializing” process alone take 35 seconds in 2.80. I have a GTX 1060 plus a GTX770 - my Xeon CPU is enabled as well.
Any ideas, why the speed difference is that big?
The speed difference is even more dramatic when I start the rendering. Here are the times it takes until the first bucket appears …
2.79 - 40 seconds
2.80 - 120 seconds
You can try to remove as much as possible from the scene while still keeping the speed difference. Without a simplified .blend it’s not that efficient to guess what might be wrong.
It’s not just related to one scene. I tested some other heavy scene and the difference occurs as well …
2.79 - 50 seconds
2.80 - 80 seconds
If you have no idea what the reason might be, it’s very difficult to test it for me. The scene has hundreds of elements. You can image how log it takes to remove elements and always wait 2 minutes before the rendering starts.
Most of the time this can be figured out in a couple of minutes, in my experience. Enable simplify and set everything to the lowest levels, override material with a simple diffuse material, delete half of the objects each time, etc.
I’ve done some tests. Here are the results for the times from hitting F12 until the first bucket appears …
2.79
Full scene - 34 seconds
Override material - 22 seconds
2.80
Full scene - 100 seconds
Override material - 75 seconds
Simplify (there are no subdivs in the scene) - 105 seconds
Half of the objects deleted - 53 seconds
Not sure what conclusions you can draw from this. Seems as if I take some burden from the the scene the time gets shorter. Still the times are way longer than in 2.79, even with half the objects deleted.
I did some tests and I think I narrowed the problem down. There seems to be an issue when using objects that share the same object data - the ones you create by using ALT-D. They are initialized much faster in 2.79 than in 2.80. When using non-linked objects, the times are about the same.
Here’s a scene that you can use to test.
http://www.andreasresch.at/upload/Blender_PerfTest_03.zip
On my machine from hitting F12 until the first bucket appears …
2.79 - 3 seconds
2.80 - 16 seconds
Maybe you can verify that for me.
Ah, that sounds like this bug:
https://developer.blender.org/T58251
I don’t know if that’s the same bug. You will know that better than me. I hope this gets resolved. If it was just about the rendering, I would not bother too much. But it also affects the Rendered View which I use rather often - probably many users do.
object alt d instancing dont work for me either, but instance collection work, i dont know if its revelant, but you may try this script, it replace every instance by a duppli-collection
and see if the result change
for me nature scene, drop from 18gb to 3gb for vram taken…its quite a huge bug i hope it will be fixed soon
Thanks for the reply. But as Alt-D works great except for the issue with the rendering, I would rather stick to that workflow. For now I still use 2.79 and hesitate to switch to 2.80 because of problems like this and some missing addons. Let’s just hope that programmers will have some time to fix this.
yeah add-on constantly updating and changing build is a nightmare… + api change, i try to learn to code and this doesnt help
I just did a test with Dupli Groups and can confirm, that both 2.79 and 2.80 are equal in speed. Nice suggestion. Also the file size seems to be smaller as well. I might actually think about using them in some of my more demanding scenes. Cheers.
Here’s a test file … http://www.andreasresch.at/upload/Blender_PerfTest_04.zip
For instancing with minimal memory usage it’s indeed best to use duplis/instances.
Cycles tries to detect cases where objects share the same mesh, but if the object has modifiers that feature does not work since those are different per object.
I just found out that my grup instaces are moved when I move my original Dupli Group (even in another file). That’s an issue and can lead to chaotic situations. Can this be avoided?
wait did you use group pro ?
Sorry. I don’t understand what you mean.
What I saw is, that if the original group is off the center of the coordinate system, that offset is trnasfered to the duplicated groups. So if I want to have a set of groups they all might have to be in the center of the coordinate system. But maybe I need to investigate more. Maybe you have a tip for me.
Hey.
I wasn’t aware of “Group Pro”, sorry. Man - this looks great. This should be in master not an addon. It basically maked groups really usable now.
Another addon that I have to buy that could be in master. Same for E-Cycles - should be in master as well. Instead it’s over $100 extra just to get a faster performance out of Cycles and an alternative option for denoising. And I also have a separate build to use instead of being able to keep up with the nightly builds. That’s all very chaotic.
same situation im on e-c too
it will but its not even ready to be merged (if it will at all, theres some controversy about that i dont understand why?) right now he is working on rtx, and theres a lot of pre processing time ready to be done in 2.8, if you take a look of the work he’s done so far its incredible
That is not correct, you don’t have to purchase E-Cycles, that’s a custom build BliBluBli is doing, he does some experiments, implement some features and optimizations and he updates it, after some time he wants to share his patches with anyone, but you can implement the patches yourself if they are already public.
Bear in mind that some of the features present in E-Cycles have not been reviewed by Core Developers, hence they don’t know if those are stable or not, in other cases, like with Dithered Sobol or Scrambling Distance, they simply did not have time to review and implement it in master, they will after 2.80 but not right now,they are working on stability.
Also, Intel Denoiser is completely new, not 100% stable and uses, for the time being, a lot of memory, we use it and we love it, and we hope to see it in master ASAP, but if they are working in 2.80 stability they cannot implement it either.
Theory Studios is doing builds, based on 2.79 because is what they use, but you can ask someone, or you can implement those things by yourself if you want them before they are in master, remember that 2.80 is beta, and the latest official release of Blender was 2.79b, that is really behind 2.79 daily builds in many things.
Even BliBluBli has a course to teach you how to modify C++ code and how to implement new features, he even keeps updating the course, I have it and it is pretty neat!
So don’t think you have to pay 100$ to get those features, they are public patches and you can implement them.
Also you can go to the new graphicall and you will find I myself uploaded a pair of Theory Studios builds, for Windows and Linux, with Scramble Distance, Dithered Sobold and Intel Denoiser, they are not updated to today’s master, but we use them to work.
Core devs are now focused on removing bugs and bringing stability to make the 2.80 release, not to add new features, we will see new features after release and when they com back to the 3/4 months release cycles for 2.8x.
Cheers!
EDIT: BTW, don’t get me wrong, I’m not saying that you don’t have or have to purchase E-Cycles, you can purchase it to support BliBluBli and his work if you want, he is doing some great things with different experiments and improvements, or to use those new experimental features, it’s just that I want you to be aware that you don’t have to purchase anything in a mandatory way to get new features and improved performance, there are other builds out there that are also experimental and optimized 