[Bf-committers] Nodes Re: Bf-committers Digest, Vol 45, Issue 5

[GSR]

Hi,
tfric at learnkanji.ca (2008-04-03 at 1254.57 -0300):
> Great Suggestions Yves. Now that you mention it I remember running into
> the second issue you mention myself. Certain vector math functions would
> of course cause problems when converting back and fourth between float
> and RGB  and clamping the range but these problems are minor compared to
> the flexibility it would give a motivated user. I will update my
> proposal accordingly.

The problem of vector math nodes vs RGB colour is just arbitrary
assumptions about pipe data, but I know no clamping, all is float
data. Some nodes are coded to try to guess input, and others work
dumbly. The system has no real info of meaning of the pipes, so to
speak, just the thickness. Four channels? It has to be RGBA.

To some level you can force things already, for example you can do
interesting tricks with VBlur by feeding colours into the speed
socket; but others not so, the system works against you, like
Normalize or MapValue working as single channel instead of over all
channels that are feeded. The manual solution of creating multiple
copies between a separate and combine pair can end in nigthmare, like
with those ops that have no socket for all controls, so you have to
sync multiple nodes manually.

Next generation nodes should settle all this, fully tagging data
(providing retagging and conversion capabilities obviously) or not
caring at all (with some rules about mismatched cases), so users have
no hidden exceptions to care about. Also socket vs button issues
should be addressed (currently too many socketless buttons like
MapValue etc), and from both users' & coders' PoV, full sized buffer
vs single vector (some sockets that only accept one value like
Translate, but you can plug an buffer anyway... and wonder why it does
nothing).

GSR