The GPUs are so fast now that i really wait for the BVH buildup. Its soooo sloooow. 30 Sec vs 5 sec rendering. And the reason is that we dont have a geometry/texture cache like Octane.
But i remeber that Blender HAD a fast dynamic BVH back at 2.79. What happened to that ? It did cache everything really fast. And now 2.90 is even slower… arrrgh…
@lukasstockner97 @brecht @developers is there no way ?
Did Blender have what?
<Static/Dynamic BVH:
This existed in pre 2.80. Now the final render is forced to use only static BVH. Whyyyyy ??? 
It was so much more faster. Cause yes the sampling was slower but the sampling now nobody cares about cause the GPUs are so insanely fast.
Embree integration has greatly helped build times in complex scenes (even with use spatial splits enabled). That is for CPU rendering at least, I do not know if that benefit is also there for the GPU.
There is also a patch that attempts to multithread the object synchronization stage (with spectacular results for some scenes), it is not in master yet though.
Yes, this is a big problem. I’ve had render times of 1-2 sec with Eevee and a build time of the BVH thing of over 90 sec. The only solution was to make a AHK script that takes a screenshot of the viewport every 5 sec. Works quite good but it limits the resolution of the render to the screen resolution you are using and you can’t work while rendering.
I don’t understand how the viewport can update and render every frame in seconds when the renderer needs minutes per frame without any different result. This must be possible to optimize much more.
I’ve had the same exact problem and can’t understand why nobody cares about this from the blender team. The pre-rendering phase just takes forever in blender/cycles. With our latest animation it was rendering for 8-10min per frame and from this already 2-3m where lost to pre-processing, in some case it was even worst.
Oh yes, sorry, I already forgot that…
Also I was in confusion because of that old lost patch for animation rendering that let blender not build again the tree in case only the camera is moving (I also had my share of rendered clips where over 50% of the rendertime was spent in BVH building…)
It is better than it used to be at least. At the worst point several years ago, a complex scene with lots of instancing could take over an hour before the first tile started rendering.
In addition, lsscpp is talking about a patch (by Lukas Stockner) that allows Cycles to create persistent data (which it won’t touch once it does the process again). I don’t think he ever finished it.
maybe better then it used to be but still this alone makes working in blender not possible for me in real world use cases (archviz). I need fast iterations and 2-3 minutes between clicking on f12 and the start of the render is just waaaay too much for real work. I do iterations all day until my scene is complete so this makes it impossible to work in blender. I don’t know how other people work on bigger scenes maybe it’s optimisation tricks I need to learn, but blender seems to just crawl under the highpoly assets and textures.
This following animation was rendered in blender so you can judge the size of the scenes I’m talking about
I’m no expert in BVH but I found this 2012 Nvidia Optix presentation with the following slide:
What type of BVH does Cycles use currently and is it calculated on the CPU or the GPU ? are there any newer methods in the past 8 years ? LuxCoreRenderer for reference uses Mbvh.
No idea what Cycles uses, but it’s way too slow
For the iterations you do, wouldn’t it be better to use viewport rendering (possibly with optix or Intel denoiser).
I of course understand your plight. I also noticed the BVH build up was slower post 2.8. Although, I initially thought it was just my perception.
I found this reference: https://wiki.blender.org/wiki/Source/Render/Cycles/BVH
Interesting…
The only link that worked from the 3 down the wiki page is talking about stuff made between 1980 and 2006.
A quick “Bounding Volume Hierarchies” search on Nvidia’s website returned the following 5 researches:
On AMD side there is this 2020 “news”
As for CPU, “Intel embree” search returned this:
With the latest SIGGRAPH 2018 presentation showing this “interesting” comparison:
a $30k solution (Intel® Xeon® Platinum 8180 x2) vs 1 Tesla P/V100 16GB (~ $7k)
My take on this (I may probably miss the mark, but nobody cares, i guess…)
The future is moving towards hardware accelerators for “specific” tasks in a chiplet design, and no matter how much money you throw at a general purpose method, it will not be able to compete on the “speed” department.
Hi, I was testing GSOC 2019 Embree on GPU, it was about 4 times faster on my medium GTX 760 than my i5 3750K.
Does anybody have information about, was it finished?
Cheers, mib
It only works if you don’t have tons of particles and high poly trees which I hide in the viewport to keep blender responsive. In archviz it’s not possible to do everything with viewport unfortunately
I made a thread on this topic a few months ago on the Blender devtalk and unfortunately didn’t get much insight, the flip fluids add-on dev helped with providing a test blend file though which was useful
According to wiki’s Cycles roadmap, it needs to be polished.
https://wiki.blender.org/wiki/Source/Render/Cycles/Roadmap
Stefan Werner is in charge of Embree. It looks like he spend his summer on bugfixing Embree for CPU.
Since 2 weeks, he is reviewing and updating libraries to handle Patrick Mours’s patch about NanoVDB support.
There are 2 points to finish regarding expected Embree improvements.
https://developer.blender.org/T73778
According to Cycles Roadmap, developers will focus on Performance from now to the end of the year.
Cycles Workboard contains 9 tasks related to performance. 4 tagged as 2.90. 5 tagged as performance.
Priorities are improving Embree, OIDN, Adaptive Sampling , Blue Noise dithered sampling. The following tasks are Many Light Sampling, Texture Cache, Branched Path Unification and ability to display objects as wire in rendered view.
Most of these tasks have short description or no description at all. So, I suppose that Cycles developers will take them one by one and detail this description when they will start to work on it.
Stefan will probably work on Embree for GPU when he will consider that feedback on Embree for CPU would have been sufficient.
But for the moment, handling of motion blur has just been released in 2.90.
So polishing Embree for GPU GSOC will probably not be done for 2.91.
2.92 is the release that should happen at 2/3 of performance focus.
If it does not happen for it, it probably would be in 2.93 that should be enough distant from last Embree for CPU improvements.
The BVH slow build is the ONLY reason I use Blender Octane for now which is HIGHLY responsive. But with a TON of compromises, cause octane can’t understand many Blender specific nodes that i highly miss.
Please guys. Could you guys not make a switch in the performance settings where you can final render with the viewport BVH ??? That’s ALL I need.
Yeah, I think we should express this to the developers.