Page MenuHome

Cycles Baking gives different results than Cycles Render
Closed, ResolvedPublic

Description

System Information
Windows 7 x64, NVIDIA GTX970

Blender Version
2.73

Short description of error
Cycles Baking gives different results than Cycles Render, which is particularly visible on procedurally generated materials and it makes them unusable for baking. This issue is probably caused by lack of anti-aliasing or some kind of sampling, which is enabled for Render, but not enabled for Baking. I have found that after enabling certain parts of code in kernel_bake.h, I can get more consistent results from Cycles-Baking (not the same as from Render, but really usable).

Exact steps for others to reproduce the error
I created 2 procedural materials, which I used to test rendering and baking (everything using CPU, 20 samples render, result images 512x512).

The baked images "No AA" come from official release 2.73.

The baked images "AA Enabled" come from my compiled version of Blender (64bit build, no OSL), where I enabled the following parts of code in kernel_bake.h:

ccl_device_inline float bake_clamp_mirror_repeat(float u)
{
	float fu = floorf(u);
	u = u - fu;
	return (((int)fu) & 1)? 1.0f - u: u;
}

uint rng_state = cmj_hash(i, kernel_data.integrator.seed);
float filter_x, filter_y;
path_rng_init(kg, &rng_state, sample, num_samples, &rng, 0, 0, &filter_x, &filter_y);

/* subpixel u/v offset */
if(sample > 0) {
	u = bake_clamp_mirror_repeat(u + dudx*(filter_x - 0.5f) + dudy*(filter_y - 0.5f));
	v = bake_clamp_mirror_repeat(v + dvdx*(filter_x - 0.5f) + dvdy*(filter_y - 0.5f));
}

Event Timeline

Miki (MeshLogic) raised the priority of this task from to Needs Triage by Developer.
Miki (MeshLogic) updated the task description. (Show Details)
Miki (MeshLogic) set Type to Bug.
Miki (MeshLogic) added a subscriber: Miki (MeshLogic).

@Brecht Van Lommel (brecht) what do you think? can we uncomment that part of the code? That may fix the T40369 bug, as you mentioned in your original commit.

It's not the real solution as it does not AA the geometry, but I think it's better than nothing, so seems reasonable to uncomment it.

Bastien Montagne (mont29) lowered the priority of this task from Needs Triage by Developer to Normal.Jan 23 2015, 2:24 PM

Some bad news to go with the good news. It seems that this change is only useful for situations that do not involve lighting. For the Emit pass, it appears to offer and improvement of the standard method, when using GI, the resulting bake has very distinct black artifacts across the entire image.

Maybe this should only be used when the pass type is set to Emit since it offers a tremendous benefit there but ruins the Combined bake pass.

@marc dion (marcclintdion) I also have tried to bake Combined pass and set Sun as a light source, and it looked very well with my procedural materials (which use mix of diffuse and glossy BSDF shaders). But my mesh geometry wasn't so deformed. Maybe that problem might rise with baking highly deformed meshes?

Here's another test. The first render is done with 2.73 official. The second is done using a build that has this new change(commit rB7b16fda3799d). Both use identical settings. The usual monkey head, Smart UV Project(default Settings). Direct Lighting, Branched path tracer 256 AA samples, the other samples are all set to default '1'. The material is Diffuse white(1,0, 1,0, 1,0) and the sky is also white(1,0, 1,0, 1,0).

The results for the 2.73 official release are the same as usual, there are no unexpected problems. The first image shows the same results I always get.

And the results from this new change are shown in the next image. Errors like that have not shown up in any build that I've used for the past year, it's specific to this new change.

I mentioned earlier that I thought that maybe this change should only be applied to Emit passes but it unfortunately also shows up there as well. It just didn't show up for the test case posted on the other bug report. This next image shows the OSL AO shader that is posted for https://developer.blender.org/T40369 It also shows the errors even though it was baked with an Emission shader and baked using the Emit pass.

Personally, I'd still like the option of being able to use this feature but only as an option,

I left out the texture since it's 2048x.

Ok, just tried to play with tile size and got rid of artifacts. bigger tiles and odd numbers somehow break up the vertical patterns that appear in the textures.

just typing more stuff I found out:

with image 512x512
tile 64x64, - repetitive pattern each 8 pixels vertically
tile 128*128 - each 32 pixels
tile 32*32 - each 2 pixels

tile 64x64 and :
image 512*512 - each 8 p
image 1024 - each4 p
image 2048 - each2p

I tested the monkey head (without subsurf mod) and noticed the artifacts appear only along the triangle's edges where the mesh surface gets concave. On convexly curved surfaces and edges there are no artifacts. Hopefully this could be used to fix the problem. I still want to look closer on the filter algorithm.

Thank you Lukas Stockner! I compiled Blender with your AA fix and it really works even for concave meshes. I can finally use my procedural wood for my creations :-)
The picture bellow shows the amazing quality of baking with your AA fix compared to result from official Blender release.

maybe integrating the patch as it is for 2.75 would make things not perfect but at least better looking at results form users? A better patch can then be made for 2.76 like for https://developer.blender.org/T44662