Cycles Dynamic BVH

Current situation is, the only option for rendering in cycles is to use static bvh, which has to rebuild the whole lot every frame if something moves, but is meant to finish the actual rendering part quicker.

However the viewport uses dynamic bvh, which builds just the items that move again.
In my experience the time taken to render any reasonably complex scene with animation in it at the same resolution and with no difference in subsurf levels is substantially faster in the viewport, especially after the first frame.
(other things may happen in the f12 render but i can’t see the result of them)

In fact, the difference is so extreme that i made a script for autoHotKey that screenshots the viewport after a certain time and then presses right arrow to go to next frame and repeats.

This drops my render time from about 29 seconds a frame to 14.5 seconds a frame, half.
Obviously this is not without big drawbacks, no control over color depth, render layers, transparency, fiddly to set up…

My question is, with such a dramatic speedup in render time in quite a few scenes, would it be possible to add the ability to use dynamic bvh to the F12 render?

Surely it can’t be that hard as it is already used for the viewport?
Please note this is primarily for GPU rendering as bvh build and copy etc don’t seem to take as long on CPU ( i assume it doesn’t have to copy it across)

******This certainly isn’t the best method, but it does at least prove the point.

In the meantime here is the autoHotKey script if anyone finds it useful, i am not a programmer and this is probably the biggest bodge in the history of computing, but i find it useful, once set up.

To use you will need AutoHotKey and IfranView and the viewport in separate window of the dimensions you want to render.
( i put it fullscreen on another monitor then set that monitor to the resolution i want to render in)
Tip: Home key fits viewport to camera.

***#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
; #Warn ; Enable warnings to assist with detecting common errors.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory.

#Persistent
SetTimer, PressTheKey, 14500
Return

PressTheKey:
Loop
{
if loopCount > 275
exitapp
if loopCount < 275
Send, ^{F11}
Send, {Right}
EnvAdd, loopCount, 1

/*MsgBox, Iteration number is %loopCount%.
*/

Return
}

/* this script is supposed to work with blender and ifranview in order to capture viewport renders,
which are faster for animation as they don’t have to rebuild bvh every time.

the number under persistent above is the ms delay. SET THIS TO SLIGHTLY LONGER THAN THE TIME IT TAKES FOR YOUR VIEWPORT TO RENDER, after which it runs PressTheKey, which sends “ctrl f11”
( the shortcut for ifranview taking a screenshot)
and then presses right arrow which moves the frame forward by 1 in blender.
reference links



http://www.autohotkey.com/docs/commands/Send.htm

*/
***IfranView Setup (press c to get to this window)

1 Like

Very good point and a clever AHK execution. If you wanted a different bodge, you could try running it via python within blender… But a real solution would be nice.

There is a major downfall with Dynamic BVH though, and that is scenes with high poly counts can slow it down to the point where it seemingly is unable to figure out a solution. (to the point where it’s just a lot faster to use static BVH).

There have been some building optimizations in the last few months (especially when spatial splits are used) so animators would find less of a slowdown during that phase than they used to.

A python script would be really nice, one that’s a bit more integrated, i wouldn’t know how to do it though. I suppose changing frames after a time would be easy enough, but i don’t know how to build the ui, or how you’d capture the screen.

You could be right in some scenes but i just did a test in mine with a recent build, and the latest buildbot goosebury branch, and using spatial splits put the render time to above 60 seconds per frame, the problem is that the build time far exceeds the actual render time.
I’m not saying that it’s not faster in some scenes, but that in this scene (around 900k faces) and quite a few others i’ve had, using dynamic bvh seems to be quicker, and that it would be nice to have the option to use in the right scenario.

If you can wrestle with the AHK scripting format, you could pick up python pretty quick. There is a screenshot function within blender that I believe you could use to output the file directly.

Again, I support you doing this from the standpoint of it being a clever way to bodge a solution, but it really should be a render option to enable dynamic BVH.

Have you tried rendering via commandline? that to me is usually a 20-30% speed increase over straight f12 / animation rendering in blender.

wow… is there a reason for that?

GPU does not have to do any work as far as rendering or computing anything in Blender. You don’t even need blender open.
Although the most I’ve ever seen it personally benefit me was like 18%.

On another note… Should I be using Dynamic of Static? And what about spatial splits, Should that be on?

I have had that happen a number of times, seemingly randomly. Endless build reset loop. Not sure if it would be feasible to add some method of manually hinting for some scenes prone to that problem?

I do believe there should be an option for dynamic bvh f12 render though. Just the same, very annoying to try to render an animation where the build time exceeds the render time.

A potentially better optimization would be to do subdivisions at render time so the BVH only has to deal with the poly cages. It would allow us to render millions upon millions of polys while only having to export thousands. If the devs took it farther and implemented adaptive subdivisions (which opensubdiv has) then it would only tesselate what the camera sees, making the scene even more efficient (although that’s not really a BVH optimization).

I simply can’t understand why this doesn’t even seem to be on the table for discussion as far as the devs are concerned. It would be HUGE for render displacements, for example.

The more complex the scene, the bigger the speed up in my experience.

I just want to say thanks for posting your solution for this! I don’t suppose you ever found or made a python script that does the same thing a little more directly?

Lukas made a patch to do this but as all good things go in blender this is basically a dead patch though 2.8 is supposed to be making it easier to implement such a method of persistent scenes

1 Like