[Bf-committers] Code refactoring suggestions

Prashant Sohani prashant.sohani at gmail.com
Tue Feb 5 09:20:42 CET 2013


There is some degree of in-place documentation already present with the
code. For instance, the file source/blender/compositor/COM_compositor.h did
a pretty good job of helping me to get started with the COM execution
system and groups.  There are a handful similar files in other places, such
as describing the screen division, ARegion and types etc.

If we add more such explanations in other places, it could be really useful
for new developers. Of course, whether we put them in-place with the code
or on the wiki needs to be decided.



On 30 January 2013 21:00, Howard Trickey <howard.trickey at gmail.com> wrote:

> The problem Prashant brings up could also be addressed by better guides to
> new developers about where and how to change code to do certain common
> tasks.
>
> Some of us have written FAQ answers along these lines at
> http://wiki.blender.org/index.php/Dev:Doc/FAQ.  Maybe we can all make an
> effort to add to this?  A good example would be the explanation Lukas gave
> about what has to be changed or added to in order to add a new node type.
> Or, what has to be done to make a new BMesh operator.
>
> Ideally, we'd have tutorials but those are a lot of work and risk going out
> of date quickly.
>
>
> On Wed, Jan 30, 2013 at 8:00 AM, Ton Roosendaal <ton at blender.org> wrote:
>
> > Hi,
> >
> > A good guideline for refactors is always to have it handled by people who
> > are totally familiar with the code they're handling, who are aware of its
> > features, and who can present how a new design would implement the same
> or
> > better functionality more efficiently.
> >
> > -Ton-
> >
> > ------------------------------------------------------------------------
> > Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
> > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
> >
> > On 30 Jan, 2013, at 12:49, Prashant Sohani wrote:
> >
> > > Yes, given the estimated effort involved, with no effect on end-user
> > > functionality (of course, apart from the long-term increased potential
> to
> > > draw more fresh developers to bugfix/implement more features than ever
> > > before and so on), this is not likely to be a top priority; it's just
> > > something I thought I'd mention for the sake of in case someone
> sometime
> > in
> > > future would embark upon heavy refactoring.
> > >
> > >
> > >> 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.
> > >>
> > >
> > > Interesting! It didn't even occur to me that the parameters (such as
> > Value)
> > > in the nodes can be animated with keyframes, drivers etc! I guess,
> > because
> > > I had seen the Time node already present in the Scene compositor, I
> > thought
> > > there must be a reason why it is there.
> > > Of course, you're right and this feature is more than redundant in the
> > > circumstances.. Haha, figuratively speaking the 'Time node' is already
> > all
> > > over Blender it seems :D
> > >
> > > c)
> > >
> > >> 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.
> > >>
> > > Some ideas: Since I guess we have recently added support to display the
> > > names of the labelled reroute nodes, the same names could be shown as
> > > labels at each point of instantiation. And then again, the original
> > > socket/node could be highlighted whenever one or more of the
> > corresponding
> > > out-portals is selected. Maybe I'll try to submit crude GUI
> > > mockups/screenshots of what I have in mind.
> > >
> > >
> > >
> > > On 30 January 2013 16:49, Lukas Tönne <lukas.toenne at gmail.com> wrote:
> > >
> > >> 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
> > >> Bf-committers at blender.org
> > >> http://lists.blender.org/mailman/listinfo/bf-committers
> > >>
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list