[Bf-committers] Proposal for unifying nodes

[Robin Allen]

2009/6/16 Nathan Vegdahl <cessen at cessen.com>

>   Yeah... this actually confused the hell out of me when I first
> started playing with the texture nodes, actually.  If I had a "cloud
> texture" node, for example, I expected the node to have inputs for its
> texture coordinates.  And frankly, when there weren't inputs for
> texture coordinates, my first reaction was, "Wow... no way to do
> transforms or distortions on the textures..."
>   Granted, this is coming from someone who has written shaders and
> procedurals before, so my perspective is a bit different than the
> "typical" user.
>
>   But in Blender I think of nodes as being data processing
> black-boxes.  They take input data, and produce output data, and
> that's it.  The way texture nodes work right now, it feels like
> sometimes they "reach backwards" to grab data from up-stream nodes,
> which totally breaks my mental model of how Blender nodes work.
>
>   Whatever benefits your system may have, it also seems to me (at
> least so far) that is complicates the mental model the user has to
> maintain of how nodes work.  Nodes as black-box data-processors is
> really simple to understand, and is also still extremely versatile.
>
> --Nathan V


I think perhaps you're confusing textures with the nodes that work on them.
You should think of textures as the actual images, and texture nodes as
black boxes which work on those images. So for example, your "cloud node" is
a black box that takes in several cloud parameters; cloud size, turbulence
etc., and outputs the clouds as a texture (image). It wouldn't make sense
(in this model) for the cloud node to have coordinate inputs.

Now to do transforms -- let's say a rotation -- you feed your cloud texture
(image) into a Rotate node, which rotates the whole texture and outputs
that. That's the mental model which the texture nodes try to encourage.
"Operations on textures".

I hope I explained that okay.

-Rob