[Bf-committers] Nodes GSOC project

[Tyler Fric]

Hi GSR, Thanks for the response, that certainly clarifies things.

You mention "next generation nodes." Is someone already working on those
features? I have read over the recent meeting minutes and didn't see any
mention of anyone working on nodes. If not I will add your suggestions
to my GSOC proposal. They sound like a much higher priority than some of
the other features I was considering. The tagging functionality in
particular should be fairly easy to implement and very useful from a
usability stand point. I would prefer to see both tagging and "not
caring" implemented so that a user could intentionally mismatch plugs
but be notified that they are mismatching. This would allow for the
VBlur with RGB speed trick you mentioned. Or is this what you meant by
retagging? 

TF


On Thu, 2008-04-03 at 22:50 +0200, bf-committers-request at blender.org
wrote:
> 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