[Bf-committers] Proposal for unifying nodes

[Robin Allen]

Hi Matt

2009/6/17 Matt Ebb <matt at mke3.net>

> I think you misunderstand - I think what Brecht is saying here is that the
> idea of putting a shader object inside for example a modifier node stack
> doesn't make any sense and is not a practical use case. In this context, it
> makes sense for the shader node to be attached to a material (as in, a
> material is a container of shading nodes).
>

Ah, okay. Yes, he probably did mean that. This is an issue that's been
raised,
but my answer is that if tree types are unified, then there won't really be
any
such thing as a modifier node tree, there will just be a node tree. If the
node
tree outputs a modifier, you can use it as one. Why should the user have to
decide what the tree will be used for before he starts building it?

In any case, I disagree that putting a shader object in the same tree as
modifier
nodes makes no sense. You could get some interesting effects driving shader
parameters from the mesh data.

I think if you have a fixed pipeline then it's fair enough to dictate what
users
will and won't want to do, but the node system has the potential to be so
much
more powerful than that.

Take Python, for example. Who in their right mind would want to import
curses
and opengl in the same program? No-one, right? So it should be an error?

Anyway, I've been trying to understand this proposal, but i still don't see
> how it's an improvement. Here are a few objections I have:
>
> I think you're too quick to equate shading and textures to image buffers
> (as
> in the compositor) - concrete things that can be manipulated. They're not


They *are*, though. Look at the current texture nodes -- they manipulate
textures.

they're functions that take inputs and return outputs. They can be 2D or 3D,
> they can be procedural (like the point density texture in the sim_physics
> branch), and they respond to different input.


They're functions in the mathematical sense, yes (which certainly doesn't
preclude them from being acted upon) but to us, to users, they're images.
If you can't rotate a texture, if you can't blur a texture, users will be
asking
why.

One major difference between images in the compositor and shading/textures
> is what Nathan mentioned - in the compositor, there is implicit information
> available, the pixel that's being processed. That's always going to be
> there, and it's always constant.


I'm pretty sure the compositor processes image buffers, not single pixels.
I'm
not sure what you mean by "current pixel" in the context of compositing.


> In the context of textures, this doesn't
> exist - the texture coordinates (and derivatives) are inputs to the
> texture,
> along with all the other texture's inputs (i.e. noise size, or point
> density
> lookup radius). Making this specific coordinate input backwards and
> implicit
> somehow, but not the other inputs, is very confusing and arbitrary, and
> breaks the mental model of the flow of information through the tree.


No, this is where you're making a logical error. Noise size et al. are
inputs
to the texture *generator*, not the texture. Coordinates are inputs to the
texture. You can sample a texture *at* a coordinate. You can *create* a
texture *with* a noise size.

I think maybe you're thinking of texture nodes as if they were implemented
according to Nathan's design, where a texture node "is" a texture, and you
feed the coordinate to the node. This isn't how texture nodes work, and that
design has its own problems which I've explained in my reply to Nathan.

In fact, this is how the original texture nodes were implemented, but I
recoded them because I realised I'd been conflating textures with texture
generators.

One of the whole points of a node system is that it clearly visualises the
> chain of inputs and outputs. You have data, feed that into a node to do
> something with it, and get an output, which you can then feed into
> something
> else.


Exactly! In this case the data is textures.


> In your proposal, rather than information constantly flowing from
> inputs to outputs, you have information flowing both backwards (texture
> coordinates) and forwards (everything else). This is very confusing and
> it's
> probably why it's taken so long for me to grasp this proposed concept. It's
> also inconsistent in that it seems to only work this way for 'textures',
> whatever they are. All other nodes would have a clear flow of inputs and
> outputs, but there you've got a disparity between how different nodes
> process information, but one that's not even communicated at all, which I
> consider worse.


No, this is wrong. All you have to do is think of the textures themselves as
the data which is flowing. Take this example:

http://img5.imageshack.us/img5/7158/spinn.png

Textures flow through rotate nodes and come out rotated. Textures flow
through mix nodes and mix together. Textures flow through the Spin group
and come out with the effect applied. Nothing is flowing backwards.

Now imagine the setup required to do this using, as you suggest, coordinate
inputs. I don't think it's even possible, and if it is it certainly won't be
anywhere near as easy to follow.


> The other thing that concerns me too is that by taking away direct access
> to
> texture coordinates, it'd drastically removing functionality, rather than
> adding more. Your examples of rotation/translation/scale are already
> trivial
> with texture coordinates, and in your proposal it seems you'd have to rely
> on specific nodes designed for manipulating this hidden implicit data.
> Currently I can do all kinds of funky things by manipulating the
> coordinates
> directly - they're just inputs. For example this:
>
> http://mke3.net/blender/etc/texco_warp.png


Nice. Could you warp a compositor buffer like that?


> Anyway, I still don't understand why this is even something that's
> necessary
> to be done.
>

I don't understand why having separate tree types is something that's
necessary
to be done. Okay, it already *has* been done, but that's not a good reason.

If the goal is of unifying node systems, cleaning up the
> back-end code, making it easier to add different node types, I don't see
> how
> the current data-driven model (perhaps with some modifications) precludes
> that.


It precludes that because of its reliance on hidden contextual data, and the
different ways each tree type is evaluated. Shader nodes are per-pixel.
Compositor
nodes are per-frame. Put a compositor node in a texture tree and it'll ask
"what frame are we on? Where's the framebuffer?" Contextual data is passed
implicitly to each node through its data pointer, and the data pointer is
set when
the tree starts evaluation, depending on what tree type it is.

Several users have wanted to know why they can't use texture nodes in the
shader
tree. Texture nodes are mappings, they're useful in just about any context.

Users should be able to create trees with any inputs and outputs they wish.
There
is no reason why they shouldn't be able to.

-Rob