Cycles baking is here

I put into the text editor, The part that is failing for me is where the baked image will be outputted.

Stupid little lightmap test but I thought I’d share it:

I baked a lightmap and used it for all secondary rays. Note this is on CPU and this is an interior scene. Even if you factor in baking the lightmap, it’s still just two and a half minutes for a nearly noise-free interior.

Using this Branch: http://graphicall.org/1104

The Bake function does not seem to take Clamp into account. Anyone can confirm?

At the moment it doesn’t seem to take a lot of settings into account.

Wait! What did you do?

1 Bake
2 Use baked texture as diffuse texture?
3 Render?

EDIT: Ok sorry, now I saw your material setup! Have to try that!

EDIT2: Tried it and… omg, how cool is that!!! Speed up things quite ALOT!

Try using it instead only for diffuse bounces, then you’d have something that works similar to photon mapping + final gather. You can also try limiting it to bounces > 1. I find this to be a pretty good solution for interiors.

Tried it, then the balls are horribly noisy because the reflections in them still get pathtraced.

But this is just a stupid test, so yes, you’re right, in a more serious render that’d be the way to go :slight_smile:

Baked one single lightmap 1024x1024 for everything in the scene, 100 samples. Took a minute perhaps. Then rendered:

CPU i7 3,2 GHz, 100 samples - 3min 04sec


GPU Nvidia GTX465, 500 samples - 2min 45sec.


EDIT: And also I tried to “bake the bake” and I get more bounced light, but not less noise since it seem to depend on the number on samples in this case.

My use of baking would be to produce lightmaps for realtime walkthroughs using BGE, and I guess that this will help to render detailed lightmaps for single objects faster, just as POV renders. Could not show that it helped me get rid of the noise this first try but I will for sure investigate further!

That’s odd. Even if you increase path length?

This is really great !

I used the Branched integrator and just forgot to increase the glossy and transmission samples to match diffuse. Mea culpa. No noise in the balls once I fixed it. :slight_smile:

I grayscaled the lightmap, and did some adjustments to the background and sun brightness, and changed the exposure. Same rendertime.

Note that I use a direct light setup similar as for a Blender Internal scene, like:

  • Arealights in windows.
  • Some point lights to accentuate the bounces around the window.
  • Arealights to help Emission textures.


I don’t think you should greyscale it. In fact I’d recommend you bake it to an .exr to preserve the dynamic range.

Unless of course you simply want to go for a somewhat washed out look.

The nice thing about this is that there’s all sorts of things you could do with the indirect lighting in the shader :slight_smile:

Ok that sounds awesome! Is there more material to study these techniques?

I never heard of this, and basically people are really loosing alot of time rendering raw outputs with Cycles. You could even just apply a Blender Internal bake to speed things up, I am surprised that this is not standard practice!

EDIT:
3000 samples, Nvidia GTX465. 16min 20sec. That is fast…


Well, if you wanted to bake with BI, you’d have to set up all the lights and materials for it and match them as best you can with Cycles, which would be rather labor-intensive. I don’t think there’s any more material, I just meant you could add curves, color ramps, etc to get a specific mood if you don’t care about physical correctness.

Another nice thing is that you don’t have to lightmap all of your surfaces - in an interior just walls, floors and ceilings will give a huge performance boost while all the more complicated objects can be rendered without a lightmap and it will give a more or less correct result.

I actually always have materials set up in BI and Cycles, since I am using BI for lightmaps for BGE, and Cycles for stills. I guess that when Cycles have baking, there is no need for BI anymore. But actually there is not much problem switching between the two engines, you only need this script to turn nodes on and off when you switch:

import bpy
for mat in bpy.data.materials:
    mat.use_nodes=True if not mat.use_nodes else False

Actually I find it easy to set up a BI scene, I use the same settings every time, and I even use the same lights in Cycles since the more direct light you have the cleaner it renders.

But yes, tweaking materials in two engines does not make much sense, but I use them for different things, and tweak Cycles materials more. But as I said, once Cycles has baking, using your technique, it will even be faster than BI.

Hey all, Dalai here. Thanks for testing the branch. I’ll try to address some of the questions here, feel free to ask again something I may have skipped.

As I mentioned on the email to bf-cycles/bf-game-dev there are still tons of things to implement. Off the top of my head: anti-aliasing, margins (which should solve the seams issue), cage, selected to active, …

I’m going to write an article to code.blender.org to explain a bit better how does Cycles baking fit in the Blender baking development.

CUDA issue: I’ll look at this tomorrow. I was building with no CUDA, so that compiling error slipped through.

Tried to bake diffuse only, it gives me a kind of normal colors something.

There is no “diffuse only”. You should try: DIFFUSE_COLOR, DIFFUSE_DIRECT or DIFFUSE_INDIRECT.

Regarding saving as .EXR, that’s not possible at the moment. So far it’s hardcoded to save as .PNGs all the time (: I’ll get to that

That explains the missing red bounce light on the ceiling in Piotr’s image. I’ve glanced at the code, just in case you weren’t planning to do so: Please give the user the possibility to decide whether an image is supposed to be linear or not, regardless of whether it’s considered a “data” pass or not.

Oh, lol. I thought something was fishy when the ‘exr’ came back so small. Strange Blender didnt throw an error when I loaded it.

Can we have a Is Bake output in the lightpath node (or as a separate node) that’s always 1 whenever we’re baking and always 0 when we’re not? This is to avoid feedback loops, baking using old (and likely unwanted or incorrect, since you’re rebaking) baked data.

Whithout that you have to go over each material that uses the bake and either disconnect the baked data, or change the object’s material to a different version. Can be quite labor intensive.

Also, I think baking should have its own set of light paths, sampling, ao options - for baking they’re mostly unrelated to the render settings.