Tiles: Map Range Node

This node allows the user to convert an input value range into a destination range.

One important use case is to easily map the z channel from its original range in real world meters (i.e.: 0 - 150) to a more usable range of 0-1 (or similar) for use as a matte for colorization or filtering operations.

Currently there are two options to acchieve this

a) through the use of the normalize node, however this node is not animation safe since the color values will jump whenever a close or far away object enters on frame

b) through the use of the map value node which is based on scaling and offsetting of the original values. This is an unintuitive method that requires a large amount of trial and error

Sample test file (after patch):
http://www.pasteall.org/blend/17478

Screenshot:
http://www.pasteall.org/pic/40381

Patch by Daniel Salazar (idea, tests) and me (implementation).
Developed during the BlenderPRO 2012, in Brasília :)

committed on rev. 52214

[jbkkavt, 2012-11-14 05:27:18]

Hi Dalai,

I won't be able to review this patch until christmas. Perhaps someone else
can do this.

Jeroen.

On Wed, Nov 14, 2012 at 4:40 PM, <dfelinto@gmail.com> wrote:

> Reviewers: bf-codereview_blender.org, jbkkavt,
>
> Description:
> This node allows the user to convert an input value range into a
> destination range.
>
> One important use case is to easily map the z channel from its original
> range in real world meters (i.e.: 0 - 150) to a more usable range of 0-1
> (or similar) for use as a matte for colorization or filtering
> operations.
>
> Currently there are two options to acchieve this
>
> a) through the use of the normalize node, however this node is not
> animation safe since the color values will jump whenever a close or far
> away object enters on frame
>
> b) through the use of the map value node which is based on scaling and
> offsetting of the original values. This is an unintuitive method that
> requires a large amount of trial and error
>
> Sample test file (after patch):
> http://www.pasteall.org/blend/**17478<http://www.pasteall.org/blend/17478>
>
> Screenshot:
> http://www.pasteall.org/pic/**40381 <http://www.pasteall.org/pic/40381>
>
> Patch by Daniel Salazar (idea, tests) and me (implementation).
>
> Please review this at
https://codereview.appspot.**com/6850047/<https://codereview.appspot.com/6850...
>
> Affected files:
>   source/blender/blenkernel/BKE_**node.h
>   source/blender/blenkernel/**intern/node.c
>   source/blender/compositor/**CMakeLists.txt
>   source/blender/compositor/**intern/COM_Converter.cpp
>   source/blender/compositor/**nodes/COM_MapRangeNode.cpp
>   source/blender/compositor/**nodes/COM_MapRangeNode.h
>   source/blender/compositor/**operations/COM_**MapRangeOperation.cpp
>   source/blender/compositor/**operations/COM_**MapRangeOperation.h
>   source/blender/editors/space_**node/drawnode.c
>   source/blender/makesrna/RNA_**access.h
>   source/blender/makesrna/**intern/rna_nodetree.c
>   source/blender/makesrna/**intern/rna_nodetree_types.h
>   source/blender/nodes/**CMakeLists.txt
>   source/blender/nodes/NOD_**composite.h
>   source/blender/nodes/**composite/nodes/node_**composite_mapRange.c
>
>
>


-- 
Jeroen Bakker

[sergey.vfx, 2012-11-14 14:09:46]

Hi,

From implementation ans usability point of view it's all fine. However, not sure
having bot Map Value and Map Range nodes makes much sense and doesn't sound
intuitive.

Couldn't we change Map Value and write do_versions for this?

https://codereview.appspot.com/6850047/diff/1/source/blender/compositor/opera...
File source/blender/compositor/operations/COM_MapRangeOperation.cpp (right):

https://codereview.appspot.com/6850047/diff/1/source/blender/compositor/opera...
source/blender/compositor/operations/COM_MapRangeOperation.cpp:25:
MapRangeOperation::MapRangeOperation() : NodeOperation()
Would think m_useClamp better be initialzied here

[lukas.toenne1, 2012-11-14 14:40:26]

LGTM except for the initialization issue Sergey already found.

Just a quick comment: in general i would discourage making a do_versions for
node types to "switch them over" to a different behavior. In this case it may be
simple, but my experience (image node, file output node) is that this can become
really really messy and hard to maintain later on, because it can conflict with
expected behavior and make impossible corner cases.

I wouldn't mind having an extra node for this. The conversion between MapValue
and MapRange is simple with a bit of math, but i think a destination range is
more common than a scale factor.

It can also be done easily with a node group btw ;)

[dfelinto, 2012-11-14 21:42:32]

Thanks everyone for the review.
Committed on rev. 52214 (fixed the initialization of use_Clamp)

As far as removing Map Value, if someone is driving a value of the Map
Value Node I can't see how to doversion it.
-- Dalai