Bidirectional Path Tracing and other speed improvements on Cycles


Update: For those interested, Mike Farnsworth has stepped in and started coding features for Cycles, he has already contributed coding Environment Importance Sampling.

He also created a blog: where you can find development updates and you can also donate to support his great work.

Ok, This isn’t really news, but hopefully will become one :)…

Long post but please, keep reading…

First of all, I apologize if there’s any mistake on the technical stuff of this post, I have a fairly good understanding about the subject but if any hardcore programmer or Blender developer find something odd, feel free to point it out.

Most Blender users are familiar with the Blender Internal Render… Well, this engine belongs to an old breed of rendering engines (no matter how this hurts)…

There’s now a “new” (not so new… Rather old to be fair) generation of renderers called Path Tracers… And Cycles belongs to this type or render engine…

The big, huge, enormous advantage of these renderers is their simplicity, this allows them to easily solve realistic materials and light interactions… Also, Cycles algorithms can be implemented on the GPU. That’s why we have already GPU support on Cycles even at this sort of pre-alpha state…

But there’s a problem with simple Path Tracers and is the speed… For Suzanne on a plane, or to be more production oriented, for fairly well lit scenes (day exteriors, few light sources, big sized lights and generally “easy to solve” scenarios), plain Path Tracers hold very well. But for not so well lit scenes (interiors with light coming from a window, lots of indirect lighting, small sized light sources and so on), plain Path Tracers fail miserably to deliver noise free images in reasonable times. And let’s face it, in production, the second case scenarios are present half the times, so we can’t really avoid them.

Fortunately, today there are already a lot of well known improvements that can be implemented to the plain Path Tracing code that make it more “intelligent” and this algorithms “find” relevant light contributions in the scene and dedicate the processing power where is really needed, ergo, the scene is finished much faster… How much?.. 2, 3… 10 and more times faster depending on the case…

Those algorithms are not as easy to implement as the current plain Path Tracer present in Cycles, but there are already a good number of sources of information to implement them, and even better, those improvements are still “simple” enough to be implemented for CPU and also GPU, just like Cycles currently does with its plain Path Tracing.

Some names you could have heard are “Importance sampling”, “Bidirectional Path Tracing”, “Metropolis Light Transport” (MLT for short), “Energy Redistribution Path Tracing” (ERPT for short)… And a lot of variations or different methods with even fancier names.

In case you are not sure, Cycles today is just a plain Path Tracer, It does not have any optimization mentioned (Not sure if it has some Importance Sampling implementation though).

Cycles has a good number of tricks under the sleeve to let the user optimize the scene, things like the great Light Path node and the Ray Visibility Panel are among the coolest… But there’s just so much you can do with this tricks. We need some optimizations at the Path tracing level.

A few days ago I asked in the Cycles mailing list about Brecht’s plan and timeline to implement Bidirectional Path Tracing on Cycles… And his response was:

Actually there is no concrete plan to implement these things soon. (…) Higher priority are things like render passes and layers, more detailed scenes (displacement, subdivision, caching), adaptive sampling, motion blur, … (…) More advanced algorithms may get added at some point of course, and perhaps someone other than me wants to work on them soon…
Brecht is really busy working hard on those cool features, so speed improvements at the Path Tracer level are not in the near or even mid future plans… And this is where comes the purpose of this thread…

Cycles is already being used for production and professional work (me included) and we could benefit immensely from speed gains.

IMHO, we should have at least some of the above mentioned improvements in the short term… And more than that… Brecht is receiving help from some cool developers porting nodes, applying patches and doing general stuff on Cycles… But Brecht needs more help on the hardcore stuff…

Implementing BiDir (Bidirectional Path Tracing) on Cycles is not a trivial task, not to mention MLT or ERPT on top of that… Maybe I’m wrong, but very few developers from the Blender headquarters are able to work on that, so finding a hardcore developer that can implement a high quality BiDir + MLT/ERPT (or whatever other pertinent algorithm) on CPU and GPU can require a little bit of digging. And more important, I think this should be an user initiative, Blender Foundation is busy with regular Blender development and Mango pre-production… So:

We should create a funding or something similar to hire a good programmer to help Brecht and implement the mentioned stuff… If we do a good job, we would actually alleviate BF guys from thinking about that… This could be a great retribution to their hard work.

Depending on your feedback about this idea, I could get in contact with Brecht to gather the necessary information and start the search for a good programmer that can work on this and of course, meets Blender Foundation’s and our requirements.

We basically need a programmer that can work on maybe further optimizing the Raytracer (make BVH building threaded?), other optimizations on the plain Path Tracer (Multiple Importance Sampling?)… And Finally BiDir + whatever algorithms are decided (Of course, for CPU and GPU).

And finally… In case you are skeptic and don’t think there’s enough speed improvement that worth implementing all this… Well, here’s a short video of what can be achieved with BiDir + ERPT compared to plain Path Tracing:

So let’s start the feedback :slight_smile:

My personal wish list:

  • OpenCL first, (1/2 of hardware cannot work, it really a pain and NVIDIA vendor lock)
  • on-fly memory management to avoid hardware memory size restriction (no idea how to do it, pure randomness restrict to use caching, maybe simple texture paging system ?)
  • motion blur (very hard to do, need new BVH code, then rewrite core Blender to efficiently pass motion vector to Cycles, avoid huge 3x-4x memory increase for data)
  • network friendly real time preview for happy render farm owners (isn’t it will be cool to make live tiled screen where all tiles are single network nodes?).

Bi-dir, shaders, etc are less important, but more easy and fun, that is the reason i playing with them. So, my vote to pass money to Brecht to finish more important, not fun, boring for average programmer features.

Well, it’s all got to get done. And we want it all now, so passing the money to Brecht isn’t going to get it done any faster. Brecht would just take the money and hire a developer to help him write Bidirectional Path Tracing, I imagine. :slight_smile:

Since Brecht’s todo list consists of the biggest, most important elements, I have no problem at all donating to help pay someone to help code optimizations. Cycles will remain useless in production if we can’t get our renders done in time, no matter what the features are.

For the record storm_st, I agree your list is high priority, especially MOTION BLUR! I’m only interested in OpenCL (or CUDA) if the devs can make it not be limited by the amount of VRAM in your system. Talk about a bottleneck, it makes the GPU useless for any large scene.

Oh, and since we are talking wish lists… I agree with Brecht’s entire todo list, but one thing that has never been mentioned up until now is BAKING! If cycles could light bake, we could use cycles to generate light maps for environments that could be rendered in blender internal, or exported to a game engine. That would make cycles an incredibly useful tool NOW.

Anyway, to reiterate, if someone wants to code optimizations into cycles, I’m in favor of supporting it. If someone wants to code just about anything on the todo list for cycles, I’m in favor of supporting it. We cycles up and running NOW!!! :slight_smile:

This was the kind of feedback I was expecting :slight_smile:

Some of you want Motion Blur first, some of you SSS, some of you Hair, some of you Displacement… Some of you want to render CUDA on your ATi card and some of you want a pretty girlfriend and a yacht.

Let’s not debate then in what we need first (this can be discussed in a poll later if we are organized enough to create this funding or whatever we decide)… The important thing is that Brecht needs help!.. The more help he gets, the earlier we have whatever we want (Disclaimer: I don’t think Brecht can get you a pretty girlfriend and a yacht though)…

And is important to stress the fact that is not about paying Brecht to do what we want… He has his own schedule and he has his hands full already… What he needs is more brains and hands to code.


Then we agree. Sign me up! :slight_smile:

I’d love to see some photon mapping with FG added at some point, but I have Yafaray to tide me over for the time being. My wish list for Cycles includes anything that can make it more adapted to animation, which I’m sure is on the minds of those working on Mango as well.

My brain is to small to help coding but I can do donations if needed :slight_smile:

I’ve done some tests for outdoor architecture visualization renderings and Cycles does a very good job there yet. For example the Instancing-Support is for grass very usable and gives very realistic grass results almost like you can do with Multiscatter for 3dsmax and Vray (other commercial GPU-based Renderes do not support Instancing yet or hard light through windows in interiors mostly is a problem and so on…).
I love Cycles it for the ease of use and it’s very realistic and fast renderresults.
Blender itself is pretty easy and smooth to use as well (I need to work with 3d max but I hate it’s Userinterface and slow Viewport every day).

From my point of view noiseless and fast Interiorrenderings and breaking the (V)RAM-limits would be my first two things to improve. Renderlayers are also very importand to do fast Colorcorrection on facadematerials in architecturebuildings for example.
I’m also very curious about the Volume-Shaders to do reastic water or frosted glass (the things I’ve seen in the forum are not perfect enough for me :-)).

So please help make Cycles to grow as smart, fast, usable, stable and productionusable like it has startet.

Kind regards

photon mapping is outdated in 2011.

this thread sounds very promising! :slight_smile:
If this gets coordinated well, and we find a good developer for it, I am in to support this.

I´d most certainly donate.

However for me personally it would be more important to enlarge the Cycles team to get Cylces up to full functionality with the current render kernel. Once Cycles is to Blender in functionality what BI currently is to Blender the whole team can start to implement new kernels and start optimizing.
I think if a team finishes the functionality with the thought on optimizations in the back of their head already we´ll have a result sooner, the devs can work more relaxed and don´t dance around each others code all the time.
Let´s face it, Cycles can already render nice images, but is not really feature complete with Blender.

As for the speed of development, it´s ridiculously fast. I just can say, look over at Octane. They´re on it for a while now, a whole team of coders, and so far they got a direct lighting, a pathtracing and a pmc kernel, where latter is a RefractiveSoftware alternative to MLT. Currently they are working on SSS among other things.
Or take a look at Indigos half baked OpenCL implementation or at Luxray. Took them forever and it´s not really optimized.
So optimizing and developing is beyond trivial and one can only wonder about Brechts dark magic.

On top of that I´d ask Brecht and Ton if they even want someone for the task, else the fundraiser here might fork Cycles, create a new branch and who knows what´ll happen to it. A render engine is rather delicate who knows if you’ll ever be able to merge it :slight_smile:
Dead branch anyone?
And if they think it´s a good idea to get more manpower for Cycles ask if they think it´s smarter to finish implementing functionality with Blender or to work on 2 things at once.

PS: And I don´t really want to have “noise-reduction”. Remove the cause, don´t try to fix the effect.
I´d rather have a solid MLT implementation of any kind to solve difficult lighting setups, especially for interiors or low light emmision scenes correctly in the first place. :wink:

Well if we are just throwing out potential coders here I would nominate Wenzel Jacob (the Mitsuba developer), he could probably come up with some entirely new algorithms that would work with realtime previews, I know that he is researching new rendering algorithms and that he probably don’t want to work on something else before he has completed that research but nothing to loose by asking him right? :slight_smile:

MTL, bidir, ERPT are not speed improvements always, in a outdoor scene, except you want caustics, they are actually slower than path tracing, and interior rendering is something that most animation productions always try to avoid, no matter what rendering algorithm you can use.

Arnold render is an example of a raytracing animation production render, and in its years of high level productions they never find a justification to implement such algorithms.
Cycles is a render born to follow that direction, it is not intended to satisfy all needs. And i would prefer that all the efforts go to make it very strong in that direction.

My personal wish list could be:

  • Backgraound importance sampling
  • Irradiance cache!!! at least for final render!
  • Adaptative subdivision
  • SSS


If this can indeed be coordinated along with all the other developments it would be great.
Irradiance Cache +1
… hmm, +1 to anything that helps the team actually… :slight_smile:

Caching in just about any form is bad for animation isnt it? Great for arch walkthroughs, a flickering mess for anything animated. Cycles is designed for animation, so with that in mind, things like final gather and irradiance caching goes against that philosophy. The improvements to the api should allow renderers like yafaray, lux and vray to integrate better for arch users.

Bidirectional path tracing sounds like a terrific speed up for interior scenes and is animation friendly. This is the direction cycles should go and this is what is proposed.

I’m in.

Great to see a positive response from all of you!

Also great you said that, there’s probably more people concerned about this… OF COURSE there’s a plan to contact Brecht to coordinate before even thinking on contacting a possible developer…

Sure, but BDPT is barely slower than PT in those scenarios if I’m not mistaken… And anyway, theoretically, the user could have options to decide between plain PT or other Sampler so I don’t see any issue here.

(…)and interior rendering is something that most animation productions always try to avoid, no matter what rendering algorithm you can use.

I work on productions, I work on animations… And 75% of it consists in interior rendering with dificult lighting (client directions, not my decision)… So no, it can’t be avoided always… And I’m sure I’m not the only one who works on interior renderings and wants to make fair use of Cycles just as anyone else.

That being said, tonight I’ll contact Brecht and fill him in with this initiative, explain ideas and of course, make clear there’s not a “wishlist” for features… We just want another talented developer to help him coding features for Cycles. I’ll even ask him for possible names/contacts of developers he thinks can do the job!..

Depending on your feedback and how good we organize this, I’ll try to organize with Brecht a more concrete timeline for features HE considers to be priorities… So we know what to expect and when :).

I’ll keep you updated.

But i agree with this that first let Brecht finish important things like OpenCL (i have 6850 prepared), easy bumpmapping like BI, ,multithread BVH and more speed speed speed… I know if there would be second developer then there will be beginning of MLT, ERPT etc greatness.

If this is related to my post, it’s wrong, since that proposal is not a trick to “reduce noise” but a method to have smarter real sampling, so: same results as path tracing but in less time

Nop, caching is indeed good for animations, Renderman is the caching king :), but caching introduces latency in the workflow so is not nice for interactive rendering, thats why i’ll activate it in the final render, besides Brecht also implemented Irradiance cache for Durian but it nevers gets in trunk.
Flickering will occur if you don’t sample enough, but obviously the amount of samples is generally way less with IC.

It seems your have very particular needs which are not common in classical cgi animations productions, is the feedback i can give you in these years that i have been working in the industry. Do you make archviz ?

Don’t misunderstand me, is really nice your initiative, but for most guys that make animation in blender, we don’t have yet a really nice global illumination/ tight integrated and shader consistent render, and cycles is the only hope we have right now. And i repeat you, rendering interiors in animations is not common in the industry, and if they have to, its quite common to cheat, for example with AO ray lenght, some light sources to fake indirect light etc…

If we are talking about conventional cgi animations (not archivz) is way more important to have right now Motion blur, render passes, I-Sampling, detailed scenes with subdivision, and more optimization of the things that are working now.

So thats why makes me sad to see this effort is not taking care of the conventional animations needs, thats it.


If Luxrender Knowledge could be transfered to cycles…

If Luxrender Knowledge could be transfered to cycles…

If I had a nickel for every time someone suggested the ole’ copy n’ paste, I’d be a one-percenter.