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. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
