Excessive BVH build time for dupligroup instances of hair-covered objects #47234

New Issue

Zauber Paracelsus · 2016-01-25T07:24:12+01:00

Zauber Paracelsus commented

2016-01-25 07:24:12 +01:00

System Information
OS: 64bit Lubuntu, kernel 4.2.0-23
CPU: AMD FX-8350 Octacore
GPU: GeForce GTX 650 Ti 2gb

Blender Version
Broken: 2.76b f337fea , 2.76-dev fea44ed
Worked: ?

Description of error
I have found that when rendering instances of hair-covered objects (in this case, a small park covered in grass), the BVH build time seemingly skyrockets compared to when non-instanced versions of those objects are copied. By "instanced", I am referring to empties set up as dupligroups.

For example, if I render two copies of the small grassy park (neither of them instanced), then I see a BVH build time of roughly 24 seconds in a quick test. But when I go to another scene and render to dupligroup copies of that small grassy park, the BVH build time is increased to a minute and 20 seconds.

During both tests, I was monitoring CPU usage. In the scene with the increased BVH build time, I saw that only one CPU core was being used during BVH build. This means that for some reason, the BVH build process is not taking advantage of multithreading when a scene contains hair-covered instance objects (and perhaps other types of instanced objects).

Exact steps for others to reproduce the error
Based on a (as simple as possible) attached .blend file with minimum amount of steps

Download and open the following .blend file: ParticleInstance_NoThreadedBVH.blend
Switch the scene to Original and then render. Note the time for BVH build.
Switch the scene to Instanced and then render. Note the increased time for BVH build.

**System Information** OS: 64bit Lubuntu, kernel 4.2.0-23 CPU: AMD FX-8350 Octacore GPU: GeForce GTX 650 Ti 2gb **Blender Version** Broken: 2.76b f337fea , 2.76-dev fea44ed Worked: ? **Description of error** I have found that when rendering instances of hair-covered objects (in this case, a small park covered in grass), the BVH build time seemingly skyrockets compared to when non-instanced versions of those objects are copied. By "instanced", I am referring to empties set up as dupligroups. For example, if I render two copies of the small grassy park (neither of them instanced), then I see a BVH build time of roughly 24 seconds in a quick test. But when I go to another scene and render to dupligroup copies of that small grassy park, the BVH build time is increased to a minute and 20 seconds. During both tests, I was monitoring CPU usage. In the scene with the increased BVH build time, I saw that only one CPU core was being used during BVH build. This means that for some reason, the BVH build process is not taking advantage of multithreading when a scene contains hair-covered instance objects (and perhaps other types of instanced objects). **Exact steps for others to reproduce the error** Based on a (as simple as possible) attached .blend file with minimum amount of steps 1) Download and open the following .blend file: [ParticleInstance_NoThreadedBVH.blend](https://archive.blender.org/developer/F277141/ParticleInstance_NoThreadedBVH.blend) 2) Switch the scene to Original and then render. Note the time for BVH build. 3) Switch the scene to Instanced and then render. Note the increased time for BVH build.

Zauber Paracelsus commented

2016-01-25 07:24:12 +01:00

Changed status to: 'Open'

Zauber Paracelsus commented

2016-01-25 07:24:12 +01:00

Added subscriber: @ZauberParacelsus

Zauber Paracelsus commented

2016-01-25 07:30:00 +01:00

As a note, I was able to partially alleviate the problem by dividing the hair-covered mesh into quarters, and then splitting each quarter off into a separate group. This brought the BVH build time for instances down closer to what it was for the originals.

Sergey Sharybin commented

2016-01-25 11:31:40 +01:00

Added subscriber: @Sergey

Sergey Sharybin commented

2016-01-25 11:31:40 +01:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2016-01-25 11:31:40 +01:00

Sergey Sharybin self-assigned this 2016-01-25 11:31:40 +01:00

Sergey Sharybin commented

2016-01-25 11:31:40 +01:00

Spatial splits aren't fully friendly with threading, this is a subject for improvement still. Thanks for the report, but it's not yet considered a bug.

Zauber Paracelsus commented

2016-01-25 15:54:54 +01:00

I think I'll just turn spatial splits off then. A quick test render on an urban scene I've been working on showed a 20-30 second reduction in render time with spatial splits disabled, and a small reduction in memory usage.

Are spatial splits simply not worthwhile at the current point in time?

I think I'll just turn spatial splits off then. A quick test render on an urban scene I've been working on showed a 20-30 second reduction in render time with spatial splits disabled, and a small reduction in memory usage. Are spatial splits simply not worthwhile at the current point in time?

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Excessive BVH build time for dupligroup instances of hair-covered objects #47234