Fix T46915: Non-intuitive behavior of Vector Curve Mapping node

Vector mapping node was doing some weird mapping of both original and mapped
coordinates. Mapping of original coordinates was caused by the clamping nature
of the LUT generated from the node. Mapping of the mapped value again was quite
totally obscure -- one needed to constantly keep in mind that actual value will
be scaled up and moved down.

This commit makes it so values in the vector curve mapping are always absolute.
In fact, it is now behaving quite the same as RGB curve mapping node and the
code could be de-duplicated. Keeping the code duplicated for a bit so it's more
clear what exact parts of the node changed.

Reviewers: brecht

Subscribers: bassamk

Differential Revision: https://developer.blender.org/D1672

3 files changed, 36 insertions, 16 deletions

diff --git a/intern/cycles/blender/addon/version_update.py b/intern/cycles/blender/addon/version_update.py
index 2fbb01ba5b8..eb6d5d957ad 100644
--- a/intern/cycles/blender/addon/version_update.py
+++ b/intern/cycles/blender/addon/version_update.py
@@ -100,6 +100,19 @@ def mapping_node_order_flip(node):
         node.rotation = quat.to_euler('XYZ')
 
 
+def vector_curve_node_remap(node):
+    """
+    Remap values of vector curve node from normalized to absolute values
+    """
+    from mathutils import Vector
+    if node.bl_idname == 'ShaderNodeVectorCurve':
+        node.mapping.use_clip = False
+        for curve in node.mapping.curves:
+            for point in curve.points:
+                point.location.x = (point.location.x * 2.0) - 1.0
+                point.location.y = (point.location.y - 0.5) * 2.0
+        node.mapping.update()
+
 @persistent
 def do_versions(self):
     # We don't modify startup file because it assumes to
@@ -140,3 +153,6 @@ def do_versions(self):
     # Euler order was ZYX in previous versions.
     if bpy.data.version <= (2, 73, 4):
         foreach_cycles_node(mapping_node_order_flip)
+
+    if bpy.data.version <= (2, 76, 5):
+        foreach_cycles_node(vector_curve_node_remap)
diff --git a/intern/cycles/blender/blender_shader.cpp b/intern/cycles/blender/blender_shader.cpp
index 74dee206c0e..2b4d0e4af9c 100644
--- a/intern/cycles/blender/blender_shader.cpp
+++ b/intern/cycles/blender/blender_shader.cpp
@@ -231,8 +231,13 @@ static ShaderNode *add_node(Scene *scene,
 	}
 	if(b_node.is_a(&RNA_ShaderNodeVectorCurve)) {
 		BL::ShaderNodeVectorCurve b_curve_node(b_node);
+		BL::CurveMapping mapping(b_curve_node.mapping());
 		VectorCurvesNode *curves = new VectorCurvesNode();
-		curvemapping_color_to_array(b_curve_node.mapping(), curves->curves, RAMP_TABLE_SIZE, false);
+		curvemapping_color_to_array(mapping,
+		                            curves->curves,
+		                            RAMP_TABLE_SIZE,
+		                            false);
+		curvemapping_minmax(mapping, false, &curves->min_x, &curves->max_x);
 		node = curves;
 	}
 	else if(b_node.is_a(&RNA_ShaderNodeValToRGB)) {
diff --git a/intern/cycles/blender/blender_util.h b/intern/cycles/blender/blender_util.h
index 029d0af0fd2..a1508fc6a07 100644
--- a/intern/cycles/blender/blender_util.h
+++ b/intern/cycles/blender/blender_util.h
@@ -101,21 +101,20 @@ static inline void curvemapping_color_to_array(BL::CurveMapping cumap,
                                                bool rgb_curve)
 {
 	float min_x = 0.0f, max_x = 1.0f;
-	/* TODO(sergey): Vector curve mapping is still clipping to 0..1. */
-	if(rgb_curve) {
-		/* TODO(sergey): There is no easy way to automatically guess what is
-		 * the range to be used here for the case when mapping is applied on
-		 * top of another mapping (i.e. R curve applied on top of common
-		 * one).
-		 *
-		 * Using largest possible range form all curves works correct for the
-		 * cases like vector curves and should be good enough heuristic for
-		 * the color curves as well.
-		 *
-		 * There might be some better estimations here tho.
-		 */
-		curvemapping_minmax(cumap, rgb_curve, &min_x, &max_x);
-	}
+
+	/* TODO(sergey): There is no easy way to automatically guess what is
+	 * the range to be used here for the case when mapping is applied on
+	 * top of another mapping (i.e. R curve applied on top of common
+	 * one).
+	 *
+	 * Using largest possible range form all curves works correct for the
+	 * cases like vector curves and should be good enough heuristic for
+	 * the color curves as well.
+	 *
+	 * There might be some better estimations here tho.
+	 */
+	curvemapping_minmax(cumap, rgb_curve, &min_x, &max_x);
+
 	const float range_x = max_x - min_x;
 
 	cumap.update();