Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSergey Sharybin <sergey.vfx@gmail.com>2015-12-15 14:23:33 +0300
committerSergey Sharybin <sergey.vfx@gmail.com>2015-12-31 18:40:22 +0300
commitc81e6ffdf942a7e8ac58ef3a48ca1bcab78f01fd (patch)
tree29356854ccb93701edd3c6eaad62ea0b1206b9c8 /intern/cycles/blender/blender_util.h
parent70fa2f69c9609c811522b6e0675ba7d8a2a74c08 (diff)
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
Diffstat (limited to 'intern/cycles/blender/blender_util.h')
-rw-r--r--intern/cycles/blender/blender_util.h29
1 files changed, 14 insertions, 15 deletions
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();