[Bf-committers] Proposal for unifying nodes
roblovski at gmail.com
Tue Jun 16 22:18:31 CEST 2009
2009/6/16 Brecht Van Lommel <brecht at blender.org>
> OK, my point is that these nodes themselves can only be used for shader
> or texture nodes. So somehow there is a restriction on where you can use
> a Geometry and Lighting node. You could still allow them everywhere and
> just disable them if they make no sense in that context, as long as you
> communicate the restriction to the user, I don't have a problem with
I'm willing to concede this point for now, because at this point it's a UI
OK, I think I understand the idea the concept of a Shader object now.
> Still I prefer to just use materials for that. The fact that you can
> create a shader object in the middle of any node tree, instead of
> having to make a material, that's neat, but it's really such a corner
> use case that I don't think it's worth it.
I disagree, I think this would move shader nodes from being just a "mixer"
to something you could actually create unique effects with. I don't think
that being "worth it" is a phrase I would use here, since that implies that
we're giving something up to gain something.
> I tried to show that the texture coordinates will be transformed in a
> different order in these two setups, which may not be what you expect
> since they are the same order in the node tree. Of course they are
> manipulating different data types, which is why the result is different.
I'm still not entirely sure I'm with you on this one. If you feel it's a
sticking point, could you maybe give an example of something the user could
do, and the result they would expect vs. the result they'd get?
> But that's exactly what I think is confusing, the fact that you have to
> think about these different data types, that sometimes the node tree
> works in a "functional" way and sometimes not. It's unified in that you
> can link up all nodes directly, but it's more complicated because you
> have think about colors, vectors and functions. It's quite powerful, but
> I just prefer it to be simpler even if that limits things a bit.
The user doesn't have to think of textures as functions at all. The user
will most likely think of them as textures. To think of textures as
textures, and texture nodes as working on textures is surely just as natural
as to think of texture nodes as textures (as well as being, for
aforementioned reasons, hugely more useful).
> it's more complicated because you have think about colors, vectors
> and functions.
Colors, vectors and *textures*. Pretty natural IMHO since we're already
about bitmaps in the compositor.
> The only limitation would be that you have to create a texture/material
> to do certain things, instead of being able to have everything in a
> single node tree.
Are you saying that's a limitation of the current system or the proposed
Because it sounds like the current system to me.
> Further, I don't think users will really understand this distinction
> well, and that it will cause more confusion than open possibilities. It
> took me a while to understand, and I'm a developer, though admittedly
> not one that naturally thinks in terms of function programming.
That's not entirely fair, because as a developer it's important that you
not only what you can do, but how it's actually happening under the hood,
how it will be implemented. A user will see nodes that work on textures,
that work on shaders, nodes that work on colors, and so on.
More information about the Bf-committers