[Bf-committers] Code refactoring suggestions

[Lukas Tönne]

I generally agree that the current state of code can be very confusing
and cumbersome to work with, especially for newcomers. However,
changing it is a lot of work and breaks the design of some areas that
work well now, e.g. serialization in readfile/writefile. So whether or
not that should be attempted needs to be considered carefully in each
case.

One place that seriously lacks code locality is the node system, which
is also extremely spread out over all areas in C:
* DNA data in makesdna
* generic node functions and some specialized stuff in blenkernel
* RNA representation in one huge rna_nodetree.c file (just as bad) and
incomprehensible macros (ugh)
* individual node registration code and execution code (for BI and
texture nodes) in nodes folder
* draw functions in editors/space_node
* specialized read/write code in blenloader as usual
* operators also nowhere near nodes they operate on (this has been
cleaned up a bit lately by splitting into multiple files)

There is clearly a design conflict between having code for the same
purpose (read/write, UI, node evaluation) in different folders vs.
having code related to one type in the same place (modularity).
Blender code structure was (i assume) designed for a fixed set of
types/modes/etc., for which the first approach works very well. With
the increasing number of node types however it becomes a real
obstacle. One nice advantage of python nodes is that you can have
*all* code related to one particular node type in one place, without
having to worry about directory structure and bad-level calls. We'll
have to see how this develops in the future once pynodes branch is
merged.

> a) A Time input node in Material/Shader compositor would enable OSL etc to
> leverage the same for awesome time-varying materials.

I think this is neither necessary nor desirable. Materials/Shaders
don't have an intrinsic concept of "time". What one can already do
easily is use a value input (either Value node or just another node
socket value) and animate it with a linear fcurve. That gives you all
necessary flexibility of mapping frame number to a "time" value,
including stuff like changing pace or even going backward.

> c) A 'teleport' or 'global bus' aspect to the reroute nodes, so that they
> can serve as proxy portals to be quickly instantiated anywhere in the node
> view, without having to explicitly add an ugly visible on-screen link
> between the source socket and every reference to it.

This idea has come up before. Problem is how to indicate such a "long
distance connection" in the UI so it can be identified easily. I'm not
entirely opposed to this idea, but there should be a good UI concept
first (mockups, testing). Technically wouldn't be so difficult, the
node evaluation just has to interpret them as a link.