Compositing Problems in 2.71 #41067

New Issue

David Brennan · 2014-07-14T12:01:19+02:00

David Brennan commented

2014-07-14 12:01:19 +02:00

System Information
Operating system and graphics card

Windows 7, 64-bit. No GPU/

Blender Version
Broken: (example: 2.69.7 4b206af, see splash screen)
Worked: (optional)

Blender 2.71
WORKED: 2.70

Short description of error

After rendering a frame in 2.71, I have repeatedly had an issue where the resulting render is not shown properly in its default UV Image Editor window. Often times, even when I select the "COMBINED" pass in the window, it will instead show some one of the random Render Layers. Usually, I have "fixed" this problem by just toggling between the various Render Layers in the UV Image Editor, and eventually under "Combined" the combined render will indeed appear.

However, this problem of confusing Render Layers has now reached a critical level. I have a fairly simple animation of some 2D images (just .PNGs) and there are a good number of Render Layers. However, in 2.71, every time I try to render out the animation, all I get are white frames!

When I render out an individual frame, I can work this out as I described at the top: just toggle through the different Render Layers and then eventually the "Combined" version will be correct. But because this is an animation (700 frames), that work-around is not an option.

Exact steps for others to reproduce the error
Based on a (as simple as possible) attached .blend file with minimum amount of steps

Attached is a simple .Blend with all the images attached. Just hit CTRL+F12, and you should see that the result is all white images. But if you check the individual Render Layers, you'll see that everything is okay.

The Bug does not occur in 2.70.

CompositingBug.blend

**System Information** Operating system and graphics card Windows 7, 64-bit. No GPU/ **Blender Version** Broken: (example: 2.69.7 4b206af, see splash screen) Worked: (optional) Blender 2.71 WORKED: 2.70 **Short description of error** After rendering a frame in 2.71, I have repeatedly had an issue where the resulting render is not shown properly in its default UV Image Editor window. Often times, even when I select the "COMBINED" pass in the window, it will instead show some one of the random Render Layers. Usually, I have "fixed" this problem by just toggling between the various Render Layers in the UV Image Editor, and eventually under "Combined" the combined render will indeed appear. However, this problem of confusing Render Layers has now reached a critical level. I have a fairly simple animation of some 2D images (just .PNGs) and there are a good number of Render Layers. However, in 2.71, every time I try to render out the animation, all I get are white frames! When I render out an individual frame, I can work this out as I described at the top: just toggle through the different Render Layers and then eventually the "Combined" version will be correct. But because this is an animation (700 frames), that work-around is not an option. **Exact steps for others to reproduce the error** Based on a (as simple as possible) attached .blend file with minimum amount of steps Attached is a simple .Blend with all the images attached. Just hit CTRL+F12, and you should see that the result is all white images. But if you check the individual Render Layers, you'll see that everything is okay. The Bug does not occur in 2.70. [CompositingBug.blend](https://archive.blender.org/developer/F97773/CompositingBug.blend)

David Brennan commented

2014-07-14 12:01:19 +02:00

Changed status to: 'Open'

David Brennan commented

2014-07-14 12:01:19 +02:00

Added subscriber: @davidbrennan

Lukas Tönne commented

2014-07-14 18:31:53 +02:00

Added subscriber: @LukasTonne

Lukas Tönne commented

2014-07-14 18:31:53 +02:00

Think the problem here is the muted colorramp node. It could be working differently in render and viewer/previews, which is why "the individual render layers" look correct.

Lukas Tönne commented

2014-07-14 19:11:52 +02:00

Added subscribers: @Jeroen-Bakker, @monique

Lukas Tönne self-assigned this 2014-07-14 19:12:01 +02:00

Lukas Tönne commented

2014-07-14 19:12:07 +02:00

Indeed, this is what happens:

When the node viewer/preview is calculated, the muted node gets removed before the compositor even starts:
https://developer.blender.org/diffusion/B/browse/master/source/blender/nodes/composite/node_composite_tree.c;48eececdba17af7d85fc19480be0e34e38362e66$140

When the actual full-screen composite is calculated (F12) it does not remove muted nodes in advance, but replaces them with proxies internally. These proxies are also removed later, but when there is a conversion (like the value->color conversion of the Color Ramp node) the input will still be converted:
https://developer.blender.org/diffusion/B/browse/master/source/blender/compositor/intern/COM_NodeGraph.cpp;48eececdba17af7d85fc19480be0e34e38362e66$122

Now the question is if muting should also disable any type conversion. Arguably passing data into one socket type and using the output of another could be expected to do a conversion in any case, regardless of whether the node is muted or not (i.e. the main operation disabled). OTOH the previous behavior was to disable the conversion as well, so this can be seen as a regression.

Indeed, this is what happens: When the node viewer/preview is calculated, the muted node gets removed before the compositor even starts: https://developer.blender.org/diffusion/B/browse/master/source/blender/nodes/composite/node_composite_tree.c;48eececdba17af7d85fc19480be0e34e38362e66$140 When the actual full-screen composite is calculated (F12) it does not remove muted nodes in advance, but replaces them with proxies internally. These proxies are also removed later, but when there is a conversion (like the value->color conversion of the Color Ramp node) the input will still be converted: https://developer.blender.org/diffusion/B/browse/master/source/blender/compositor/intern/COM_NodeGraph.cpp;48eececdba17af7d85fc19480be0e34e38362e66$122 Now the question is if muting should also disable any type conversion. Arguably passing data into one socket type and using the output of another could be expected to do a conversion in any case, regardless of whether the node is muted or not (i.e. the main operation disabled). OTOH the previous behavior was to disable the conversion as well, so this can be seen as a regression.

David Brennan commented

2014-07-14 23:30:00 +02:00

Well, the "regression" sounds best to me.

Most all viewers will expect animated frames to appear as the same as the individual frames. So I think it's best to just have consistency.

Well, the "regression" sounds best to me. Most all viewers will expect animated frames to appear as the same as the individual frames. So I think it's best to just have consistency.

blender-admin commented

2014-07-15 11:03:07 +02:00

This issue was referenced by 2bdb872cfb

This issue was referenced by 2bdb872cfb90feae214088954d243820e4992c3b

Lukas Tönne commented

2014-07-15 11:05:06 +02:00

Changed status from 'Open' to: 'Resolved'

Lukas Tönne closed this issue

2014-07-15 11:05:06 +02:00

Lukas Tönne commented

2014-07-15 11:05:06 +02:00

Closed by commit 2bdb872cfb.