Blender Internal: Inverting alpha looks odd in material node setting. #38773

New Issue

Leon Cheung · 2014-02-23T11:30:15+01:00

Leon Cheung commented

2014-02-23 11:30:15 +01:00

System Information
Win7 64bit | FX2700M

Blender Version
Broken: 2.69.11 10f4c62
Worked: n/a

Short description of error
When trying to invert alpha output for material node, it works differently from what it does in Compositing mode.

Exact steps for others to reproduce the error
Please see attached image and .blend file. Here, it seems that the Fac and Color input for the Invert node function sort of "inversely", or I can be wrong on this? Thanks for checking.

alpha_invert_mat.blend

**System Information** Win7 64bit | FX2700M **Blender Version** Broken: 2.69.11 10f4c62 Worked: n/a **Short description of error** When trying to invert alpha output for material node, it works differently from what it does in Compositing mode. **Exact steps for others to reproduce the error** Please see attached image and .blend file. Here, it seems that the **Fac** and **Color** input for the Invert node function sort of "inversely", or I can be wrong on this? Thanks for checking. ![alpha_invert_in_material_mode.png](https://archive.blender.org/developer/F78600/alpha_invert_in_material_mode.png) ![alpha_invert_in_compositing_mode.png](https://archive.blender.org/developer/F78601/alpha_invert_in_compositing_mode.png) [alpha_invert_mat.blend](https://archive.blender.org/developer/F78604/alpha_invert_mat.blend)

Leon Cheung commented

2014-02-23 11:30:15 +01:00

Changed status to: 'Open'

Leon Cheung commented

2014-02-23 11:30:15 +01:00

Added subscriber: @ZhangYu

Lukas Tönne commented

2014-02-23 12:22:22 +01:00

Added subscriber: @LukasTonne

Lukas Tönne commented

2014-02-23 12:22:22 +01:00

This is a bad inconsistency in conversion of the "value" alpha type to the "color" input type of the invert node.

What should happen is that a value x is converted to a color (x,x,x) using this function:
https://developer.blender.org/diffusion/B/browse/master/source/blender/nodes/shader/node_shader_util.c;cb1b6b549e8cd8eb6cb40fa03818a913e1f45c00$55

Most nodes do this correctly by reading input stack values through this function, so they get the desired type no matter what the input is,
e.g.:

However, a lot of nodes don't actually use this function and simply access the input stack values as-is,
e.g.

This should be unified, so all nodes use the same conversion methods. However we need to be aware that this might break a lot of existing node setups that are based on the faulty behavior!

Also the opposite case of converting colors to single values is a bit questionable in the aforementioned function: From a color (r,g,b) you get a "grayscale" value of (r + g + b) / 3, while just using the r component might be more appropriate. This could happen for example in the math node, which also omits the conversion function:
https://developer.blender.org/diffusion/B/browse/master/source/blender/nodes/shader/nodes/node_shader_math.c;cb1b6b549e8cd8eb6cb40fa03818a913e1f45c00$53

This is a bad inconsistency in conversion of the "value" alpha type to the "color" input type of the invert node. What *should* happen is that a value x is converted to a color (x,x,x) using this function: https://developer.blender.org/diffusion/B/browse/master/source/blender/nodes/shader/node_shader_util.c;cb1b6b549e8cd8eb6cb40fa03818a913e1f45c00$55 Most nodes do this correctly by reading input stack values through this function, so they get the desired type no matter what the input is, e.g.: * output node https://developer.blender.org/diffusion/B/browse/master/source/blender/nodes/shader/nodes/node_shader_output.c;cb1b6b549e8cd8eb6cb40fa03818a913e1f45c00$49 * color band node https://developer.blender.org/diffusion/B/browse/master/source/blender/nodes/shader/nodes/node_shader_valToRgb.c;cb1b6b549e8cd8eb6cb40fa03818a913e1f45c00$53 * RGB mix node https://developer.blender.org/diffusion/B/browse/master/source/blender/nodes/shader/nodes/node_shader_mixRgb.c;cb1b6b549e8cd8eb6cb40fa03818a913e1f45c00$58 However, a lot of nodes don't actually use this function and simply access the input stack values as-is, e.g. * hue/saturation/value node https://developer.blender.org/diffusion/B/browse/master/source/blender/nodes/shader/nodes/node_shader_hueSatVal.c;cb1b6b549e8cd8eb6cb40fa03818a913e1f45c00$74 * invert node https://developer.blender.org/diffusion/B/browse/master/source/blender/nodes/shader/nodes/node_shader_invert.c;cb1b6b549e8cd8eb6cb40fa03818a913e1f45c00$54 This should be unified, so all nodes use the same conversion methods. *However* we need to be aware that this might break a lot of existing node setups that are based on the faulty behavior! Also the opposite case of converting colors to single values is a bit questionable in the aforementioned function: From a color (r,g,b) you get a "grayscale" value of (r + g + b) / 3, while just using the r component might be more appropriate. This could happen for example in the math node, which also omits the conversion function: https://developer.blender.org/diffusion/B/browse/master/source/blender/nodes/shader/nodes/node_shader_math.c;cb1b6b549e8cd8eb6cb40fa03818a913e1f45c00$53

Lukas Tönne commented

2014-02-24 10:43:37 +01:00

Added subscriber: @brecht

Lukas Tönne commented

2014-02-24 10:43:37 +01:00

@brecht: What's the best course of action here? Changing it could break existing nodes quite badly as well ...

Brecht Van Lommel commented

2014-02-24 15:50:46 +01:00

Well this is pretty bad. I think if we are going to break compatibility then now for 2.70 is the right moment, so I think we should do it.

From a color (r,g,b) you get a "grayscale" value of (r + g + b) / 3, while just using the r component might be more appropriate

I think the average is the right behavior, there's no reason red should be more important than other channels.

Well this is pretty bad. I think if we are going to break compatibility then now for 2.70 is the right moment, so I think we should do it. > From a color (r,g,b) you get a "grayscale" value of (r + g + b) / 3, while just using the r component might be more appropriate I think the average is the right behavior, there's no reason red should be more important than other channels.

Lukas Tönne self-assigned this 2014-02-25 09:40:13 +01:00

blender-admin commented

2014-02-25 10:15:28 +01:00

This issue was referenced by blender/blender-addons-contrib@3ae641eb02

This issue was referenced by blender/blender-addons-contrib@3ae641eb020ea61a595840eee8cbcc9f7ee36043

blender-admin commented

2014-02-25 10:15:28 +01:00

This issue was referenced by 3ae641eb02

This issue was referenced by 3ae641eb020ea61a595840eee8cbcc9f7ee36043

Lukas Tönne commented

2014-02-25 10:20:43 +01:00

Changed status from 'Open' to: 'Resolved'