# Description

This patch adds a input node that gets the pixels coordinate as a vector and a node that calculates the distance between two points (given as vectors).

However, there seems to be a bug somewhere. The two nodes are very simple so I really can't figure what I did wrong.

See the attached screenshots for the bug. Both times the preview should be a blurry black sphere, but one time it's a bar. Both time the "other" input coordinate is (0, 0, 0).

Essentially the Coordinate Node does:
static void valuefn(float *out, float *coord, bNode *node, bNodeStack **in, short thread)
{
out[0] = coord[0];
out[1] = coord[1];
out[2] = coord[2];
}

And the Distance Node does:
static void valuefn(float *out, float *coord, bNode *node, bNodeStack **in, short thread)
{
float coord1[3], coord2[3];
float x, y, z;

x = coord2[0] - coord1[0];
y = coord2[1] - coord1[1];
z = coord2[2] - coord1[2];

*out = sqrt(x * x + y * y + z * z);
}

### Event Timeline

PS: Using this nodes (+displacement modifier + weight paint) you can build nice terrains (see appended screenshots).

tex_input_vec expects a 4-vector as its first argument; could be what's causing it. Rewriting to use 3-vectors is on the todo list.

Oh, then this bug exists in TEX_translate.c too, because I copied this code from there.

Committed this patch today. Thanks!

Robin Allen (kakbarnf) changed the task status from Unknown Status to Unknown Status.Nov 26 2008, 2:10 PM

Very nice!
Cool, some code of mine ended up in blender. :)

PS. There is also a function for finding distance in BLI_arithb.h : VecLenf(), which is probably better to use to keep things centralised, and to make the code a lot cleaner.

I also wonder whether it would be better to put that distance function as a mode within the math node, rather than making too many different nodes, or even if the mix node 'difference' can do the same thing?

I figured there have to be such an function somewhere but because I don't know blenders source well I did not find it. Someone with commit rights should change this.

I thought the math node only accepts "values", and not vectors?

The difference option of the mix nodes does a completely different thing.

Matt, the math node won't accept vectors, and the mix node clamps its values to colour range [0..1f]. Could generalize this to a 'vector math' node in the future though.

Thanks for the tip about BLI_arithb, I'll update the code to use that. (Some of my code could probably use it too...)