---------------------------------------------------------------------------------------
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: http://morecycles.blogspot.com/ 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