Cycles Status

by - 2012/05/14 37 Comments Uncategorized

Here’s an updates on what we’re working on in Cycles. Up to now, the features that we’ve added for the 2.64 release are BVH build time optimizations, exclude layers, motion/UV passes, filter glossy option, a light falloff node, a fisheye lens (by Dalai Felinto), ray length access (by Agustin Benavidez), and some other small things.

There’s also now a page in the Cycles manual about Reducing Noise in renders. All of these tricks are used in production with other render engines and should apply to path tracers in general.

Currently there’s still three major features on my list to implement: motion blur, volumetric rendering and a contribution pass. We already have a vector pass now for doing motion blur in compositing, but real raytraced motion blur would be nice as well. The code for this is mostly written but work is needed to make this faster, currently it’s slowing down our raytracing kernel even if the there are no motion blurred objects.

Cycles Motion Blur

Volumetrics should be a target for 2.65, so the release after the one we’re working on now. There’s already a developer who has patches to add volumetrics to Cycles, we’ll need to review the design and add support for rendering smoke and point cloud datasets. Currently volumetrics are being rendered with Blender Internal, and probably in production they end up in separate layers anyway, but it’s not very convenient to mix render engines and have to switch back and forth.

The idea for the contribution pass is that’s it’s like the only shadow material in Blender Internal, but more flexible and interacting with indirect light, to help compositing objects into footage. How this will work exactly is unsure still.

Everything else is related to optimizing performance in one way or another, either by making things simply render faster, reducing noise levels or adding tricks to avoid noise. Baking light to textures for static backgrounds may be added too, but if at all possible I’d like to avoid this. Most of the optimizations we are looking at will be CPU only, on the GPU there’s not as much that we can do due to hardware restrictions. Some directions we will look in:

  • Improving core raytracing performance (SIMD, spatial splits, build parameters).
  • Decoupling AA sample and light sample numbers. Currently one path is traced for each sample, but depending on the scene it might be less noisy to distribute samples in another way.
  • Better texture filtering and use of OpenImageIO for tiled image cache on the CPU, so we can use more textures than fit in memory.
  • Texture blurring behind glossy/diffuse bounces. Like the Filter Glossy option, this can help reduce noise at the cost of some accuracy, especially useful for environment maps or high frequency noise textures.
  • Non-progressive tile based rendering, to increase memory locality, which should avoid cache misses for main memory and the image cache.
  • Adaptive sampling, to render more samples in regions with more noise.
  • Better sampling patterns. I’ve been testing a few different ones but they couldn’t beat the Sobol patterns we use yet when using many samples (> 16), still hope we can find something here.
  • Reducing memory usage for meshes (vertices, normals, texture coordinates, ..).
  • Improve sampling for scenes with many light sources (just rough ideas here, not sure it will work).
Hopefully these changes together with careful scene setups will be sufficient to keep render times within reason, but beyond that we can still look at things like irradiance caching or other caching type tricks. I hope to avoid these because they don’t extend to glossy reflections well, I’d like to try to keep things unbiased-ish, it seems to be the direction many render engines are moving in, and it’s easier to control, maintain and parallelize over many cores.
  1. Dusty says:

    Happy days! You’re really working hard on this (as usual) and I really appreciate your efforts!

  2. bo de anrr says:

    is it now possible to render Smoke, particles, fire and such nice stuff in cycles ? (perhaps it was possible all the time but I has not known it …)

    • brecht says:

      That’s the volumetrics mentioned in the post, it’s not yet possible but is a target for 2.65.

      • Tycho says:

        or you can use something from storm branch :) volumetrics are already good implemented (even some bidir and MLT) :) if its not for smoke sim but only to make fog or cloud, it works very well …

  3. Alessio says:

    It’s always a pleasure to hear Cycles news directly from the source! ;)
    One thing i’m curious about: “Adaptive sampling, to render more samples in regions with more noise.”
    I get it like Cycles will be “noise aware”, my doubt is: will it just throw more samples for the same pass in difficult areas, or will it drop sending samples in already clean areas? The latter would need the implementation of a sort of “smoothness parameter” that could be useful to always achieve renders with the same (visual)level of smoothness

    • brecht says:

      I’m not sure yet how it will work exactly, it will depend on the algorithm, making it really robust is very hard and most algorithms fail already on simple things like soft shadows so I haven’t decided yet which one to use. Probably there will be a way to configure the integrator in such a way that it renders to a certain smoothness level.

  4. Dimetrii says:

    Motion pass, light falloff node. Coooool!
    Thank you, breht! :)

  5. Aidy B says:

    This is great! Was there any plans to add normal map support into cycles? Is it even possible?

    I imagine some game artists (like me!) would love to use cycles as a user friendly rendering engine for showing off work.

    • brecht says:

      Probably at some point, but it’s not a priority at the moment.

      • Aidy B says:

        WOOHOO! Thanks for the response Brecht, that’s great to know it’s possible and on the list.

        There’s plenty to be excited about with the current mango related list.

  6. Rob says:

    Sounds very promising!

  7. Hi,

    I’m curious when is the support for Kepler and Cuda 3.0 (Driver 4.2) planned in? Do you have a plan for that?

    Thanks in advance, great work Brecht!

    • brecht says:

      2.64 will almost certainly come with support for these cards, but we need to work around a bug in the 4.2 toolkit that’s causing wrong renders still.

    • Miranda says:

      This might not need to be as big of a priority as many make it out to be. The Keplar architecture simply isn’t very optimized for GPGPU tasks. The GK104 has been castrated in terms of compute in favor of gaming performance. The 680 only performs as well, if not often worse, than a 580 in compute speed.

  8. Ace Dragon says:

    “Most of the optimizations we are looking at will be CPU only”

    Thank you, CPU-compatible optimizations was one of the things I was hoping to see developed during the Mango project. Something which would reduce the speed gap between CPU and GPU rendering so you can have faster rendering while taking advantage of the extra RAM that usually wouldn’t be found on the GPU. All while allowing many users like me to not have to pay an extra cent for brand new hardware to get closer to the speeds that people using the GPU were enjoying for months.

    Meanwhile, it looks like the list of items that could be done hold the promise of significant improvements when it comes to optimizing the Cycles engine, here’s hoping that there’s still some algorithms out there that will be able to do exactly what you are looking for. :)

  9. monsterdog says:

    Great work on this Brecht & Co. :)

    With various performance optimizations, would it be difficult for you to implement some that gives a big boost at the cost of visual fidelity, but with the option to turn them on/off on a per frame basis?

    So if you have a fast moving shot sequence with lots of motion blur, maybe they could be turned on, but then for another sequence that is slow or has no blur at all turn them off?

    Could Random Parameter Filtering be implemented across both CPU and GPU code bases? (again with an on/off switch) :

    • brecht says:

      There’s been interesting research in this area, filtering of monte carlo renders, but very little of it seems usable for production rendering. If you look at the video that comes with the RPF paper, you’ll see a lot of flickering. The render results are blotchy, the simple scenes or the textures just hide it in still images.

      I think for any method that does this kind of noise smoothing, there should be a feedback loop to guide the sampling (like e.g. irradiance caching has). If you blindly smooth out noise after all the samples are taken, no matter how advanced the method, it will never be reliable. Interesting to think about but not immediately applicable.

  10. Ace Dragon says:

    “Could Random Parameter Filtering be implemented across both CPU and GPU code bases? (again with an on/off switch) :”

    One of the Luxrender developers has actually tried an RPF implementation, I believe he came to the conclusion that it wasn’t worth the enormous amount of memory that would’ve been needed for a high quality render.

    True, it’s one of the most advanced denoising algorithms out there right now, but last I read it requires a truckload of RAM if you want to make good use of it. So in part because of that, I personally think we should avoid post-process denoising effects if possible and reduce/eliminate the noise issue through the performance and sampling enhancements and optimizations like seen in the list.

    • monsterdog says:

      “One of the Luxrender developers has actually tried an RPF implementation, I believe he came to the conclusion that it wasn’t worth the enormous amount of memory that would’ve been needed for a high quality render.”

      Oh well, what a shame, I had high hopes for it :(

      • Ace Dragon says:

        Here is the actual post from the Luxrender forum for reference

        And the actual conclusion.
        “The result isn’t very exciting. Again, it isn’t the complete filtering process described in the paper but it has very very high disk, memory and cpu requirements and I’m not obtaining very interesting results. At moment, I hesitate to spend more time on this work because I’m not sure if it will take me somewhere.”

  11. An eye vu production says:

    drivers from amd would ready soon say ccc 12.6
    Despite all that optimizations sound wiked

    good BF

  12. Irve says:

    Mesh light in manual probably needs a third image of the wireframe as I didn’t get it.

  13. Dewald says:

    My Cycles wish list is almost completely fulfilled (obviously the optimizations can certainly keep coming). As a character artist one thing I am absolutely dying to have is hair and sss in Cycles. I can’t wait.

    I wonder if vector pass for motion blur in compositing will work OK with render time depth of field?

    Thanks guys!! Cycles is nothing short of amazing. Soon we will be seeing amazing work done with Cycles.

  14. SamCameron says:

    Can’t wait to start playing with motion blur in cycles, please add a GPU compatibility for the motion blur as well, would be awesome. Any estimation date of real motion blur in cycles?

  15. Ki1o says:

    So sooner or later rendering hair and fur will also be possible in Cycles?

  16. see360 says:

    Your cycles development is progressing so fast I am almost embarrassed to trouble you, but… could we have a texture image sequence node to allow rendering animations with dynamic paint in cycles?

    Thank you!

  17. Tycho says:

    Brecht probably you can add the “geometry|incomming” node in the how to reduce node page. See the result in BA :
    I ve never heard about that but it’s impressive …

  18. Darren says:

    Great work Brecht! I’m very impressed and excited with these speedup improvements planned for 2.64.

    One quick question: will the new version of cycles also incorporate Mike Farney’s “glossy anisotropic” shader? From the thread, it looks pretty much completed, and just needs some code review before being incorporated.

  19. David Haymond says:

    Great work Brecht! I’m really looking forward to the CPU optimizations, motion blur, and volumetrics.

  20. Phil says:

    Have you had any help from AMD/Nvidia/Intel with this Part/Project of Blender. I really think they could help? I would be a big Win to get a Large company to support/sponsor the Cycles project. Also they could help with rendering of Mango.

  21. Thomas says:

    I wonder if the use of random calculation of reflections might be replaced by something deterministic. I mean the calculation of for example reflections, where either the reflection is calculated or the diffuse value, depending on chance.

    Could this choice be made deterministic? I’d think a binary mechanism could work. It could work as follows:

    First iteration: Is the top bit of the reflection value set? then calculate a reflection path, otherwise the diffuse. The result gets weight 128 in the buffer.

    Second iteration: Check the top-1 bit. Calculate either reflection or diffuse path again. The resuklt gets weight 64 in the buffer because of the bit position.

    Multiple reflections will become a problem if the the same bit of every reflectivity in a ray is checked. A pattern could be devised for sampling where the first reflection gets the most bits sampled and later reflections are sampled in the old way.

    Does the above make sense or is it total nonsense?

  22. Minchiozzo says:

    I hope too Cycles will optimize more on CPU. Actually, in commercial software CPU continue to do great work and improve drastically the performance and quality result (take a look at clarisse FX). All the commercial software seems move again on CPU, and all GPU rendering look practical stop (octane, airon etc.

  23. FCore says:

    What is current status of 2.64 CPU optimizations, i am certain too that in future we get very fast and powerful CPU-s. My vote goes to CPU.