Cycles Roadmap

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.

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.

Contributing

If you’re a developer and would like to help out, you can look in these places:

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.

GPU Rendering

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.

Once Cycles can handle render layers, something I’ve been wondering about is if the compositor could use a render layer with Cycles, and another render layer with Blender Internal. In my mind, certain passes don’t necessarily need the complex treatment Cycles provides. You could also consider that Freestyle could be combined with Cycles that way.

I think it would be good if the render API could somehow bring a long with it a generic option to set up multiple layers / passes which are independent of engines.

An example would be to have a generic render layer set-up, with a select-able engine from the add-ons enabled under the layer name, then depending on the engine selected, the required render options / settings / passes would be shown in the render panel.

The generic render layers could then be set up across many different engines to use each to it’s own strength i.e. Blender for hair, Cycles for beauty passes and clicking on each render layer would automatically switch between the active engines.

I think this would probably quite difficult to coordinate as there are several other engines with add-ons for Blender but I really do think it would make Blender such a powerful tool, sort of like Katana for bring everything together in the rendering, except of course you’d use Blender for everything else as well 😉

On-topic:

Brecht, you are making amazing progress and with Cycles improving each day, the future really is looking exceptionally bright.

Great work ! In my opinion a cycles based – bake system useful for game creation could be a very boost to the adoption of blender; an automatic system to UVunwrap + create image + bake starting from cycles materials and throught cycles engine would be a definitive tool !! Am I a dreamer ?!
Thank for your great work !!

There’s a vivid discussion on normal maps right now on BlenderArtists, so if you ever read this Brecht, could you put them somewhere on the roadmap for us please? It’s quite frustrating to not see them mentioned anywhere. And thanks for all the hard work! Cycles is fast becoming my favorite render engine. 🙂

OpenMP is likely going to have extensions for GPUs and other accelerators eventually (OpenACC). Lets see if AMD and Intel get on board with this one. OpenACC might sufficiently lessen the technology coupling of the system, removing the development bottleneck.

thank you Brecht! I cant wait to see the new features in action! Cycles is becoming my favorite render engine. Would it be possible to implement a “sobel-style” edge node in cycles, similar(or better yet identical) to the Edge render effect from Blender Internal Renderer?

Everyone who wants OpenCL, guys it’s the AMD OpenCL driver which has issues and stops us from proper support for it. I guess there are possibilities for workarounds, but that is very time intensive and does not fix the error source (again: the AMD drivers!)
Write mails to AMD 😉

One thing I would love added to the ToDo list is some sort of volume precedence system – something that detects boundaries between dynamic objects – to allow rendering of fluid simulation interacting with glass objects.

I do hope that OpenCL support comes. To me it would have made more sense to go the OpenCL route for GPU accelerated rendering in the first place, since nvidia apparently does support OpenCL as well. Of course, some sort of limitation may exist that I’m not aware of…

in my little opinion the direction of blender development
should always follow the opensource way, therefore OpenCL.

From an implementation point o view, I’d like that developers
have focus on the OpenCL framework and not, for example,
making work-arounds to let AMD products to work well.

Then, each hardware producer can (or not) implement Opencl
for its driver… Is it possible that no one have interest
developing opencl drivers?
There could be free opensource (like blender) and commercial software that can use OpenCL, isn’t it?

The new GeForce cards should be enough indication that CUDA is NOT the way to go. While pre-600 series had just its double precision at 1/8 the single precision performance, the new ones have been capped at 1/24 SP. Check the latest reviews of the new Nvidia cards to find out its truly poor compute performance (the SmallLuxGPU tests are appalling). On AMD’s side, consumer cards have a relatively small cap of 1/4 SP, which makes them much more useful for rendering.

Workstation cards -the only non-capped ones- are just too expensive. Please go OpenCL and make Cycles shine in GPU rendering.

hello and thank you for your great work 🙂
I have a proposal for cycles: Is it possible to have the selection visible in render mode? in fact it corresponds to a layer with the wireframe mode above the rendering. May be we could switch the display of the selection. I hope that the cycles mode will be the main mode and we will work directly on it …

Particle Hair would be so great. Anyways – superb great work. With your help Blender may surpass Maya in no time.

One thing that Maya does well is: it only calculates Pixels or Rays, that are really >in the Camera< and everything else will not be considered to be rendered, which frees a lot of RAMs and power of the GPU/CPU. Just wanted to mention it. 😉

I also am greatly interested in hair with cycles. I have previously converted the hair particle systems to mesh then curve, however with more recent project this is not possible. I look forward to cycles with hair.

Texture baking would be great. Unless you are rich enough to buy super SLI systems, baking would allow amazing quality to come from small studios. Blender in my eyes have always helped the little guy so baking would be a huge step! Cycles itself is a huge step for all though and I am extremely grateful for it. Baking seems like an important feature to complete the possibilities. Render super GI image for hours, bake textures, apply shadeless to BI render. Now you have photo-realistic animation in seconds =)

“OpenACC API allows parallel programmers to provide simple hints, known as “directives,” to the compiler, identifying which areas of code to accelerate, without requiring programmers to modify or adapt the underlying code itself. By exposing parallelism to the compiler, dir”

Another vote here for texture lightmap baking, a massive quality win in gaming and similar scenarios, although I appreciate it is probably not the easiest thing to implement (I can imagine the default renderer is probably itself very much “baked in” to the lightmap generation code)