[Bf-committers] Proposal for unifying nodes

Robin Allen roblovski at gmail.com
Wed Jun 17 03:58:53 CEST 2009

Hi Joe

2009/6/17 joe <joeedh at gmail.com>:
> I'm not sure why you think this is all possible. . .while having a system to
> convert between any arbitrary kind of data is certainly possible, you'd end
> up with a pretty big mess when you're done.  You'd literally have to find
> meaningful conversions between everything from shader functions, to image
> buffers, to *geometry*, to who knows what else.  In practice, I suspect
> there would be a ton of edge cases, where things would not *quite* work as
> people expect, and we'd be swamped in bug reports. ;)
> Besides, this sort of mix and matching isn't powerful, it's mashing
> different systems and different concepts together, and hoping something
> useful will come out of it.  It mostly relies on people coming up with
> intelligent, useful conversions, which may be more difficult then it seems.
> Especially when you want to drive unrelated concepts, like mixing shading
> nodes with modifier nodes (there may be some cases it could be useful, but
> in general it'd mostly be clunky, buggy, and unstable).

I think you misunderstand the design. You certainly wouldn't have to
find meaningful conversions between *everything*, literally or
otherwise. I'd be interested to know where you got this from,
actually, because it would, as you say, degenerate into madness.

Implicit conversions occur in predictable and well-defined situations.
For example, it's a fact that any operation you can do to a color you
can do to a texture. This warrants an implicit conversion. But using
data of one type to drive parameters of an unrelated type will require
you to specify, using nodes, exactly what you mean.

> And don't forget that some nodes require contextual data, that won't always
> be available.  Modifier nodes, for example, probably would need a scene (at
> the very least), and shader nodes already get a bunch of stuff behind the
> scenes.

This contextual data is exactly what's keeping the tree types
separate; most of the design is about finding better ways to get this
data to nodes.


More information about the Bf-committers mailing list