[Bf-committers] Proposal for unifying nodes

Robin Allen roblovski at gmail.com
Mon Jun 15 15:59:17 CEST 2009

2009/6/15 Brecht Van Lommel <brecht at blender.org>:

> So if you're going to implement the filter functions here, I don't know
> how to do this without doing extra texture evaluations, not to mention
> what happens when chaining such filters. It could work more efficient
> for exceptional cases, but not in general.

That's right, the 'extra' texture evaluations are just a consequence
of the returned texture being more complex than the one you fed in. As
you chain more filters to the texture, the texture will take longer to
evaluate. This is a fact independent of how you implement things. The
fact that this overhead manifests as extra function calls in this
particular design is neither here nor there.

If your texture is f(x,y) and you feed it through a scale node
s(f)(x,y) = f(x/2, y/2) then you are necessarily evaluating two
functions, s and f. You can't get that 'for free', but I don't believe
there could be a faster correct implementation.

Speaking of performance, one advantage of the functional approach is
that every function can be free to evaluate its arguments in parallel.

> If you want to do blurring, the more efficient way to do that is by
> scaling the texture derivatives up, and for sharpen scaling them down
> (or doing an unsharp mask perhaps). Directional filters I guess you
> could also emulate some way, but then you need to specify a vector for
> this direction to make sense, seems a bit too specialist.

That's a great idea. I'd been wondering about how to do blurring, but
couldn't seem to come up with a good algorithm. (The derivatives
aren't actually implemented in the current texture nodes; blender was
giving me weird values for them when I got to that part.)

> Anyway, I'm not sure there are that many cases where you actually
> benefit from have such a function callback available? What kind of nodes
> would you implement with them, if blur and sharpen could already be done
> (in a bit limited from)?

Function callback?

> Somewhat related, I think texture coordinates should perhaps be a
> separate type, which would be a point and two derivative vectors. This
> can be easily converted to a vector and back, but if you want proper
> filtering while manipulating the texture coordinates, the derivatives
> need to be passed along and transformed too.

I was thinking of making a texture a function of TexCallData (similar
to how it is now), which is a struct including coordinates,
derivatives and current frame. You could make a TexCallData out of a
vector by setting the extra info to zero.


More information about the Bf-committers mailing list