4
$\begingroup$

I have a "Map Range" node with the following inputs:

Value: 10000, From Min: 9995, From Max: 10005, To Min: 0, To Max: 1

Because 10,000 is right in the middle between 9,995 and 10,005, I expect the output to be 0.5, and indeed it is.

If I now increase the value by one:

Value: 10000, From Min: 9995, From Max: 10005, To Min: 0, To Max: 1

I expect the value to be 0.6, but instead the node outputs 1.0. Even if I put the value ever so slightly above 10,000 (say, 10,000.001), I still get 1.0 as the result.

If I decrease the value to 9,999 instead, I get a result of 0.4 as I expect.

So clearly the behavior changes precisely at the 10,000 mark. What limitation am I running into? Is this documented somewhere? Are there other places where I need to be aware of similar issues when doing calculations in the compositor?

If it matters, this is 2.79b 64bit on Windows 10, but I'm getting the same behavior in 2.72b on Linux Mint.

$\endgroup$
7
$\begingroup$

By viewing the source of this node in:

source/blender/compositor/operations/COM_MapRangeOperation.cpp

We see in line 46 this comment:

/* The code below assumes all data is inside range +- this, and that input buffer is single channel */
#define BLENDER_ZMAX 10000.0f

So it is not a bug, this range is defined by the developers for some reason. If the input value is larger than BLENDER_ZMAX then the To Max input is returned, if the input value is less than negative BLENDER_ZMAX then To Min is returned.

$\endgroup$
  • 1
    $\begingroup$ This limitation was added via this commit for consistency with the "normalize node". I think in both cases it's an arbitrary value, and recompiling with a larger value should work fine $\endgroup$ – Nicola Sap Sep 24 '18 at 11:09
  • $\begingroup$ Huh. That's a bit unfortunate, given that the documentation advertises this node as a more intuitive replacement of "Map value", where you wouldn't expect such limitations. Well, the workaround is easy enough. Thanks for finding this! $\endgroup$ – balpha Sep 24 '18 at 11:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.