Page MenuHome

Excessive BVH build time for dupligroup instances of hair-covered objects
Closed, ArchivedPublic

Description

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:
  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.

Event Timeline

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 (sergey) changed the task status from Unknown Status to Unknown Status.Jan 25 2016, 11:31 AM
Sergey Sharybin (sergey) claimed this task.

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.

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?