# We need a faster BVH build time

**URL:** <https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334>\
**Category:** Blender and CG Discussions\
**Created:** [September 9, 2020, 1:13pm UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334 "2020-09-09T13:13:01Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![enilnacs](https://blenderartists.org/user_avatar/blenderartists.org/enilnacs/32/1464731_2.png) [@enilnacs](https://blenderartists.org/u/enilnacs)\
**Post date:** [September 9, 2020, 1:13pm UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/1 "2020-09-09T13:13:01Z")

</div>

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 ?

---

<div class="post-metadata">

**Author:** ![lsscpp](https://blenderartists.org/user_avatar/blenderartists.org/lsscpp/32/3452_2.png) [@lsscpp](https://blenderartists.org/u/lsscpp)\
**Post date:** [September 9, 2020, 3:06pm UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/2 "2020-09-09T15:06:46Z")

</div>

> [@enilnacs](#):
>
> But i remeber that Blender HAD a fast dynamic BVH back at 2.79

Did Blender have what?

---

<div class="post-metadata">

**Author:** ![enilnacs](https://blenderartists.org/user_avatar/blenderartists.org/enilnacs/32/1464731_2.png) [@enilnacs](https://blenderartists.org/u/enilnacs)\
**Post date:** [September 9, 2020, 4:10pm UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/3 "2020-09-09T16:10:59Z")

</div>

\< **Static/Dynamic BVH:**

- _Static BVH_ needs to be rebuilt after **any** object modification, however it provides faster render times
- _Dynamic BVH_ allows objects to be rebuilt individually, so that BVH rebuilding times will be much lower at the cost of longer render time.
- **Note:** The final render _ **always** _ uses _Static BVH_ , while the viewport render uses the settings in _Properties \> Render \> Performance \> Viewport_ .

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.

---

<div class="post-metadata">

**Author:** ![Ace\_Dragon](https://blenderartists.org/user_avatar/blenderartists.org/ace_dragon/32/1067926_2.png) [@Ace\_Dragon](https://blenderartists.org/u/Ace_Dragon)\
**Post date:** [September 9, 2020, 5:43pm UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/4 "2020-09-09T17:43:58Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Ztreem](https://blenderartists.org/user_avatar/blenderartists.org/ztreem/32/506137_2.png) [@Ztreem](https://blenderartists.org/u/Ztreem)\
**Post date:** [September 9, 2020, 7:07pm UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/5 "2020-09-09T19:07:41Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dbalex](https://blenderartists.org/letter_avatar_proxy/v4/letter/d/7ea924/32.png) [@dbalex](https://blenderartists.org/u/dbalex)\
**Post date:** [September 9, 2020, 7:16pm UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/6 "2020-09-09T19:16:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![lsscpp](https://blenderartists.org/user_avatar/blenderartists.org/lsscpp/32/3452_2.png) [@lsscpp](https://blenderartists.org/u/lsscpp)\
**Post date:** [September 9, 2020, 9:28pm UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/7 "2020-09-09T21:28:57Z")

</div>

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…)

---

<div class="post-metadata">

**Author:** ![Ace\_Dragon](https://blenderartists.org/user_avatar/blenderartists.org/ace_dragon/32/1067926_2.png) [@Ace\_Dragon](https://blenderartists.org/u/Ace_Dragon)\
**Post date:** [September 10, 2020, 2:45am UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/8 "2020-09-10T02:45:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dbalex](https://blenderartists.org/letter_avatar_proxy/v4/letter/d/7ea924/32.png) [@dbalex](https://blenderartists.org/u/dbalex)\
**Post date:** [September 10, 2020, 5:26am UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/9 "2020-09-10T05:26:59Z")

</div>

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

[![](https://blenderartists.org/uploads/default/original/4X/9/d/8/9d8a20e54743f391825377b50d8f68b55baa9240.jpeg "Clarisse Genk - 3D animation trailer 1") ](https://www.youtube.com/watch?v=317m--6FX-c)

---

<div class="post-metadata">

**Author:** ![Voidium](https://blenderartists.org/user_avatar/blenderartists.org/voidium/32/805263_2.png) [@Voidium](https://blenderartists.org/u/Voidium)\
**Post date:** [September 10, 2020, 7:57pm UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/10 "2020-09-10T19:57:47Z")

</div>

I’m no expert in BVH but I found this 2012 Nvidia Optix presentation with the following slide:

[![](https://i.imgur.com/UULtvrT.png) ](https://i.imgur.com/UULtvrT.png)

- Sbvh
- Bvh
- Mbvh
- Lbvh

Source: [https://on-demand.gputechconf.com/gtc/2012/presentations/S0366-Optix-Out-of-Core-and-Cpu-Rendering.pdf](https://on-demand.gputechconf.com/gtc/2012/presentations/S0366-Optix-Out-of-Core-and-Cpu-Rendering.pdf)

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.

---

<div class="post-metadata">

**Author:** ![dbalex](https://blenderartists.org/letter_avatar_proxy/v4/letter/d/7ea924/32.png) [@dbalex](https://blenderartists.org/u/dbalex)\
**Post date:** [September 11, 2020, 9:17am UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/11 "2020-09-11T09:17:56Z")

</div>

No idea what Cycles uses, but it’s way too slow

---

<div class="post-metadata">

**Author:** ![Alor](https://blenderartists.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@Alor](https://blenderartists.org/u/Alor)\
**Post date:** [September 11, 2020, 10:22am UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/12 "2020-09-11T10:22:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![lsscpp](https://blenderartists.org/user_avatar/blenderartists.org/lsscpp/32/3452_2.png) [@lsscpp](https://blenderartists.org/u/lsscpp)\
**Post date:** [September 11, 2020, 9:18pm UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/13 "2020-09-11T21:18:13Z")

</div>

I found this reference: [https://wiki.blender.org/wiki/Source/Render/Cycles/BVH](https://wiki.blender.org/wiki/Source/Render/Cycles/BVH)

---

<div class="post-metadata">

**Author:** ![Voidium](https://blenderartists.org/user_avatar/blenderartists.org/voidium/32/805263_2.png) [@Voidium](https://blenderartists.org/u/Voidium)\
**Post date:** [September 12, 2020, 6:02am UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/14 "2020-09-12T06:02:26Z")

</div>

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:

- 2009: Fast BVH Construction on GPUs  
[https://research.nvidia.com/publication/fast-bvh-construction-gpus](https://research.nvidia.com/publication/fast-bvh-construction-gpus)
- 2011: Simpler and Faster HLBVH with Work Queues  
[https://research.nvidia.com/publication/simpler-and-faster-hlbvh-work-queues](https://research.nvidia.com/publication/simpler-and-faster-hlbvh-work-queues)
- 2012: Maximizing Parallelism in the Construction of BVHs, Octrees, and k-d Trees  
[https://research.nvidia.com/publication/maximizing-parallelism-construction-bvhs-octrees-and-k-d-trees](https://research.nvidia.com/publication/maximizing-parallelism-construction-bvhs-octrees-and-k-d-trees)
- 2013: Fast Parallel Construction of High-Quality Bounding Volume Hierarchies  
[https://research.nvidia.com/publication/fast-parallel-construction-high-quality-bounding-volume-hierarchies](https://research.nvidia.com/publication/fast-parallel-construction-high-quality-bounding-volume-hierarchies)
- 2013: On Quality Metrics of Bounding Volume Hierarchies  
[https://research.nvidia.com/publication/quality-metrics-bounding-volume-hierarchies](https://research.nvidia.com/publication/quality-metrics-bounding-volume-hierarchies)

On AMD side there is this 2020 “news”

[![](https://i.imgur.com/ETzZ79W.png) ](https://i.imgur.com/ETzZ79W.png)

Source: [https://wccftech.com/amds-radeon-rays-4-0-announced-as-closed-source-then-mostly-opened-again-after-backlash/](https://wccftech.com/amds-radeon-rays-4-0-announced-as-closed-source-then-mostly-opened-again-after-backlash/)

As for CPU, “Intel embree” search returned this:

[![](https://i.imgur.com/BxYaSOa.png) ](https://i.imgur.com/BxYaSOa.png)

With the latest SIGGRAPH 2018 presentation showing this “interesting” comparison:

[![](https://i.imgur.com/lsDedXX.png) ](https://i.imgur.com/lsDedXX.png)

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.

---

<div class="post-metadata">

**Author:** ![mib2berlin](https://blenderartists.org/user_avatar/blenderartists.org/mib2berlin/32/7715_2.png) [@mib2berlin](https://blenderartists.org/u/mib2berlin)\
**Post date:** [September 12, 2020, 8:16am UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/15 "2020-09-12T08:16:02Z")

</div>

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?

> **[Embree for GPU — Weekly Reports](https://devtalk.blender.org/t/embree-for-gpu-weekly-reports/7703/22)**
>
> @MetinSeven Nothing is merged yet, but my next step is to polish code, and work for it to be accepted in master @nokipaike This work isn’t specific to OpenCL or CUDA, the goal is to use Embree to build the BVH and then to use it on something...

Cheers, mib

---

<div class="post-metadata">

**Author:** ![dbalex](https://blenderartists.org/letter_avatar_proxy/v4/letter/d/7ea924/32.png) [@dbalex](https://blenderartists.org/u/dbalex)\
**Post date:** [September 14, 2020, 5:29am UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/16 "2020-09-14T05:29:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ARC9](https://blenderartists.org/user_avatar/blenderartists.org/arc9/32/502237_2.png) [@ARC9](https://blenderartists.org/u/ARC9)\
**Post date:** [September 14, 2020, 8:17am UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/17 "2020-09-14T08:17:56Z")

</div>

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

> **[Faster scene initializing](https://devtalk.blender.org/t/faster-scene-initializing/13725?u=arc4g)**
>
> Hello, I’m wondering if there’s anything that can help with the scene initializing phase in a render, i have a fluid sim with lots of data and the scene initializing & synchronizing objects period seem to take a considerable amount of time...

---

<div class="post-metadata">

**Author:** ![zeauro](https://blenderartists.org/user_avatar/blenderartists.org/zeauro/32/443778_2.png) [@zeauro](https://blenderartists.org/u/zeauro)\
**Post date:** [September 14, 2020, 8:21am UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/18 "2020-09-14T08:21:22Z")

</div>

According to wiki’s Cycles roadmap, it needs to be polished.  
[https://wiki.blender.org/wiki/Source/Render/Cycles/Roadmap](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](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.

---

<div class="post-metadata">

**Author:** ![enilnacs](https://blenderartists.org/user_avatar/blenderartists.org/enilnacs/32/1464731_2.png) [@enilnacs](https://blenderartists.org/u/enilnacs)\
**Post date:** [September 14, 2020, 4:03pm UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/19 "2020-09-14T16:03:29Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dimitribastos](https://blenderartists.org/user_avatar/blenderartists.org/dimitribastos/32/42671_2.png) [@dimitribastos](https://blenderartists.org/u/dimitribastos)\
**Post date:** [September 22, 2020, 1:40pm UTC](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334/20 "2020-09-22T13:40:38Z")

</div>

Yeah, I think we should express this to the developers.

[Next page](https://blenderartists.org/t/we-need-a-faster-bvh-build-time/1252334.md?page=2)
