Now that Cycles is in a Blender release, the next step is to extend it further and improve performance. Remember that Cycles is intended to be a render engine for individuals / small studios, aimed primarily at rendering animations, and this goal is what we evaluate priorities of features by.
For the next few months, the main priorities are:
- Render layers, passes, full sample, compositing layer, ..
- Performance improvements / noise reduction for typical two bounce animation scenes
- Some smaller things for completeness (blender integration stuff, ramps, multi GPU, ..)
After that, we should get to some more exciting features, which ones are a bit unclear, but this will be influenced by project Mango. Volume rendering and motion blur seem like good candidates, but we’ll see. Performance work will be ongoing during Mango of course, and we see that quite broadly, it’s about low level performance tuning, better algorithms and better user control.
Beyond that, there is a feature list which contains roughly what we’d like to see added over the next 2 years.
If you’re a developer and would like to help out, you can look in these places:
If you need more details about how features should work, how to implement things or just to announce that you’re working on something, contact the bf-cycles mailing list. Another way to help is to improve our documentation in the manual.
There are some things obviously missing that people would like to see added. Bidirectional path tracing, photon mapping, MLT and similar algorithm are not a priority for me, since we do not believe they are the main possible performance improvements for animation frames. Shading language support, resumable rendering, is another one that we do not think should get very high priority.
Lastly, GPU rendering can be somewhat of a bottleneck to development. It seems that with older cards and current OpenCL support in the drivers, we’d have to considerably complicate the code to get Cycles working fully, to the point where it would be too hard to add new features. This also means we’re dependent on improving driver implementations or language features. We’ll keep track of this, but also can’t justify spending too much time on this, to try to work around issues with every possible card / driver combination.