Cycles Baking gives different results than Cycles Render #43388

New Issue

Miki · 2015-01-23T04:05:39+01:00

Miki commented

2015-01-23 04:05:39 +01:00

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));
}

Test_CyclesBake.blend

**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)); } ``` ![Test_CyclesBake.png](https://archive.blender.org/developer/F138888/Test_CyclesBake.png) [Test_CyclesBake.blend](https://archive.blender.org/developer/F138892/Test_CyclesBake.blend)

Miki commented

2015-01-23 04:05:39 +01:00

Changed status to: 'Open'

Dalai Felinto was assigned by Miki

2015-01-23 04:05:39 +01:00

Miki commented

2015-01-23 04:05:39 +01:00

Added subscriber: @MikiProxima

blender-admin commented

2015-01-23 04:05:39 +01:00

#46831 was marked as duplicate of this issue

Dalai Felinto commented

2015-01-23 04:38:23 +01:00

Added subscriber: @brecht

Dalai Felinto commented

2015-01-23 04:38:23 +01:00

@brecht what do you think? can we uncomment that part of the code? That may fix the #40369 bug, as you mentioned in your original commit.

Brecht Van Lommel commented

2015-01-23 12:23:45 +01:00

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.

blender-admin commented

2015-01-27 21:20:42 +01:00

This issue was referenced by 7b16fda379

This issue was referenced by 7b16fda3799d5b7167ef7ffe533d654810f44e36

Dalai Felinto commented

2015-01-27 21:44:14 +01:00

Changed status from 'Open' to: 'Resolved'

Dalai Felinto closed this issue

2015-01-27 21:44:14 +01:00

Dalai Felinto commented

2015-01-27 21:44:14 +01:00

Closed by commit 7b16fda379.

Closed by commit 7b16fda379.

blender-admin commented

2015-01-28 09:01:41 +01:00

This issue was referenced by blender/cycles@b2b79a08c6

This issue was referenced by blender/cycles@b2b79a08c648cc10abd1788a16cb27961472ac98

marc dion commented

2015-01-28 20:20:02 +01:00

Added subscriber: @MarcClintDion

marc dion commented

2015-01-28 20:20:02 +01:00

This comment was removed by @MarcClintDion

*This comment was removed by @MarcClintDion*

marc dion commented

2015-01-29 07:32:04 +01:00

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.

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. ![comparison.png](https://archive.blender.org/developer/F139787/comparison.png)

Miki commented

2015-01-29 12:14:30 +01:00

@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?

marc dion commented

2015-02-02 20:22:21 +01:00

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 7b16fda379). 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,

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 7b16fda379). 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. ![AO_273_official.png](https://archive.blender.org/developer/F140504/AO_273_official.png) 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. ![patch.png](https://archive.blender.org/developer/F140507/patch.png) 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. ![monkey_OSL_patch.png](https://archive.blender.org/developer/F140510/monkey_OSL_patch.png) Personally, I'd still like the option of being able to use this feature but only as an option,

Dalai Felinto commented

2015-02-03 14:48:59 +01:00

@MarcClintDion can you share your test file?

marc dion commented

2015-02-03 21:49:16 +01:00

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

I left out the texture since it's 2048x. [monkey.blend](https://archive.blender.org/developer/F140750/monkey.blend)

Vilem Duha commented

2015-02-05 21:09:41 +01:00

Added subscriber: @VilemDuha

Vilem Duha commented

2015-02-05 21:09:41 +01:00

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.

Vilem Duha commented

2015-02-05 21:23:11 +01:00

just typing more stuff I found out:

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

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

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

Miki commented

2015-02-06 02:20:23 +01:00

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.

Dalai Felinto commented

2015-02-23 21:57:22 +01:00

Changed status from 'Resolved' to: 'Open'

Dalai Felinto reopened this issue

2015-02-23 21:57:22 +01:00

Miki commented

2015-04-28 22:54:57 +02:00

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.

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. ![Test_ProceduralWood_txt.png](https://archive.blender.org/developer/F167755/Test_ProceduralWood_txt.png)

mathieu menuet commented

2015-06-17 09:28:47 +02:00

Added subscriber: @bliblubli

mathieu menuet commented

2015-06-17 09:28:47 +02:00

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