Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blender Cycles Turbocharged: how we made rendering 10x faster

cloud.blender.org

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Blender Cycles Turbocharged: how we made rendering 10x faster

#11

Post by boulos »

__s wrote: post #8
boulos wrote: post #4

They don't say how, but I assume like all of us they moved to a motion-blur friendly time-based BVH. I'm surprised this only recently came up for Blender!

> After a few days of investigation, Sergey improved the layout of hair bounding boxes for BVH structure. What does this mean? A more in-depth explanation is coming soon. Sounds more that they optimized their BVH implementation

Sorry if I wasn't clear. Using a time-dependent BVH (where instead of two vec3 for the corners you store four, one pair for t=0 and one for t=1) is an "optimization". Given the later sentence:

> After that, he applied the same optimization to triangles (for actual character geometry)

it suggested that the bug was just using a single bounding box that ignored the motion (which is correct, but slow).

Re: Blender Cycles Turbocharged: how we made rendering 10x faster

#12

Post by berkut »

boulos wrote: post #4

They don't say how, but I assume like all of us they moved to a motion-blur friendly time-based BVH. I'm surprised this only recently came up for Blender!

Looking at the diff they did it doesn't really look that way (only had a quick glance though).

Looks like they're not using a swept BVH (interpolated time segments) for motion blur which seems weird, instead leaf nodes seem to be duplicated for each time sample.

So it looks like they're just making savings by skipping motion segments outside the current ray time, and I'd assume the bboxes of the parent inner nodes are all much bigger than they need to be (as they're not swept), and so intersection performance is still quite bad (compared with how it could be)?

Re: Blender Cycles Turbocharged: how we made rendering 10x faster

#13

Post by londons_explore »

theoh wrote: post #10
Ericson2314 wrote: post #9

It just occurred to me that motion blur not some gimmick, but temporal rather than spatial anti-aliasing. It's fundamental to accurate sampling.

Yes, both problems can be solved by the same sampling technique, e.g. https://en.wikipedia.org/wiki/Distributed_ray_tracing In theory, upping the resolution will also remove the need for spatial anti-aliasing, though it's not efficient. Distributing rays in time feels a bit different because what you're really trying to do is integrate over an interval of time. So I'm not sure I agree that they are the same thing.

Remember that to remove aliasing (spatial and temporal), you want no frequencies above the nyquist rate.

Typically, anti-aliasing uses an average of multiple samples across the width of the pixel (MSAA), or across the timespan of the frame to eliminate this.

That is in fact a rectangular function in the time/spatial domain. Which is wrong. A rectangular function reduces rather than eliminates the frequency components above the nyquist rate, and also attenuates frequencies near but below the nyquist rate (leading to blur).

In fact, you want a rectangular frequency domain function, which in the spatial/time domain is a sinc function.

This isn't done in real cameras because it is technically too hard, but in 3D rendering, it should be done, and will produce smoother animations.

I have never seen anyone do this, but results should be theoretically better. I’d also like to see a freeze frame of a sinc time domain sampled motion blur - it would probably look very weird, even though it looks good at the playback rate.

Re: Blender Cycles Turbocharged: how we made rendering 10x faster

#14

Post by CyberDildonics »

Ericson2314 wrote: post #9

It just occurred to me that motion blur not some gimmick, but temporal rather than spatial anti-aliasing. It's fundamental to accurate sampling.

That is true. This is the reason the film industry has been rendering with motion blur for 30 years.

Re: Blender Cycles Turbocharged: how we made rendering 10x faster

#15

Post by CyberDildonics »

theoh wrote: post #10
Ericson2314 wrote: post #9

It just occurred to me that motion blur not some gimmick, but temporal rather than spatial anti-aliasing. It's fundamental to accurate sampling.

Yes, both problems can be solved by the same sampling technique, e.g. https://en.wikipedia.org/wiki/Distributed_ray_tracing In theory, upping the resolution will also remove the need for spatial anti-aliasing, though it's not efficient. Distributing rays in time feels a bit different because what you're really trying to do is integrate over an interval of time. So I'm not sure I agree that they are the same thing.

They aren't different, just different dimensions. If you increase the frame rate you would need less temporal anti-aliasing. You can actually see noise artifacts in the motion blur of the first ice age movie (and many other places to be fair, like the slices in the transitions on Big Bang Theory).

Re: Blender Cycles Turbocharged: how we made rendering 10x faster

#16

Post by CyberDildonics »

Every article I see where it is a blog about 'making X Y times faster' the answer is always 'by doing something that reasonable people would assume we had already tried' and this article is no different. This is just cycles implementing a crude version of the cutting edge from 15 years ago.
Post reply on HN