In my experience it is not just the code takes a "long time" but is the lack of specific useful inline documentation and a need for a really good IDE/debugger workflow. So I started making my own code docs when I figured out coding techniques. The code in general is also not usually modular and has some unusual conventions so it is a hard read the source without a full debug and trace environment to watch it execute.
Then I started working on my IDE/debugger workflow. So mapping out the pointer usage, call backs and variable naming patterns speeds up the "long time to learn" process considerably for me. I also have a strong background as a programmer in proprietary code from scratch, maintenance code and some experience with other FOSS projects. So part of the challenge in my experience is not assuming things known from these other experiences but rather watching Blender code execute so you can see its assumptions and patterns. So cycling very fast through the debugger to see how the window management code blends in with the other code has been very helpful to me in speeding up seeing Blender's assumption picture. You will need to set key breakpoints then rapidly step out of the functions to watch the call list. Once you can recognize and ignore the window management code, then there is less code to understand. Once you recognize the callback code and variable naming and pointer code patterns then you start getting to the algorithmic code. The algorithms will make much more sense more quickly. Reading the header files also helped speed things up for me. They sometimes have the only documentation for that section of code. So that's where personal notes come handy to remember key variable names and defines when in the executing or algorithmic parts of the code. Also folding the code levels in your IDE helps see the big picture of each individual file. Then expand the functions that look relevant. This really cuts down on the noise and helps focus. The relevant DNA files to the area you are working in help with understanding the data. So always glance at those relevant files. They are formatted DNA_[name].types.h "They are your friend" I was told by a dev. Tracing the symbols in the debugger helps out tremendously. Also, as in QT Creator, "Follow symbol under the cursor" will show you where it came from and there may be some insight there. Also the wiki contains some prefix definitions that help sort things out so you can recognize a prefix as belonging to a specific part of the code. Some of the code intertwines very heavily, so it is important to sort that out and learn what code to ignore. Also there is still some unused code that has not been removed that can be confusing. So beware of that dead end. So the pattern here is a good workflow and coding/debugging environment speeds up things considerably more than just reading the code in a simple editor and trying to wrap you mind around it manually. So in my experience a good working environment and tools, memorizing a few key techniques and making some notes mapping and defining things can reduce the "it just takes a long time" down to something manageable with Blender's particular code base. So hopefully you more quickly get to where you can achieve some usable results. After that, when adding to the code, make sure to keep in line with the wiki guidelines. Also check out the dev's personal pages for information on coding. I think Sergey/Nazg-gul and Cabpbell/Ideasman42 both have some useful information on their personal pages. Other devs may also. So to recap: Once you get the technique and workflow down the time is reduced substantially In the debugger watch and learn the code flow in the function call window rapidly several times by stepping out repeatedly Check the header files and DNA_[name]_types.h files Follow the symbols back to where they came from in the code to start seeing that patern Take notes to map things out and as reminders Spend some time identifying window management and call back code so you can learn to ignore it when needed. Keep refining your techniques and things speed up. Good luck! JT ________________________________ From: John Alway <jal...@gmail.com> To: bf-blender developers <bf-committers@blender.org> Sent: Wednesday, July 2, 2014 10:04 AM Subject: Re: [Bf-committers] Learning Blender Code? Thanks to everyone for the excellent feedback. Thanks, Jonathan for the details on nurbs. I definitely don't want to step on any toes. I was just looking for a way to get started and thanks for the green light! Regards, ...John On Wed, Jul 2, 2014 at 11:39 AM, Jonathan deWerd <jjoonat...@gmail.com> wrote: > >> So, I'm wondering how others have learned the code, or is it just a > matter > >> of putting in lots of time? > > It's just a matter of putting in lots of time. Not what you wanted to hear > but I think you suspected it was true already. > > I'm the summer student working on NURBS. Just wanted to drop by and say > that you could work on this bug without stepping on my toes. The NURBS > extrusion operator already exists, ctrl+click just doesn't call it. If you > stick to calling the extrusion operator you will guarantee compatibility > with any changes that I make since I have to make the extrusion operator > work regardless. > > In order to decide which edge to extrude from, you will need to access the > NURBS object (search for "typedef struct Nurb"). Relevant fields are: > > Nurb nb; > nb->pntsu; //Number of control points in u direction > nb->pntsv; //Number of control points in v direction > nb->bp; //A 1D array of BPoints that holds the 2D array of control points. > // Writing coords (u,v), they are packed like > // > (0,0),(1,0),...,(nb->pntsu-1,0),(0,1),(1,1),...(nb->pntsu-1,1),...,(nb->pntsu-1,nb->pntsv-1). > > BPoint p; > p->vec[0]; // x > p->vec[1]; // y > p->vec[2]; // z > p->vec[3]; // w > // NOTE: this BPoint corresponds to the point (x, y, z) in space, *not* > (x/w, y/w, z/w) as per mathematical convention for homogeneous coordinates. > > Hope that helps. Nurb::bp packing order and BPoint's strange > half-homogeneous behavior were discovered by trial+error+debugger. I > haven't written any interactive operators yet so I can't help you there. I > don't think you would be shooting yourself in the foot by working with the > NURBS code. It's old but it seems to use the same operator and undo code as > the rest of blender. It's also relatively monolithic compared to BMesh: it > doesn't change representations in editmode, it doesn't keep its own > separate stack of operators, it doesn't have a domain-specific language to > represent modifications (why does BMesh even have that anyway?), and the > relevant struct definitions fit handily on half of a single screen. > > Cheers, > Jon > > > On Jul 2, 2014, at 11:50 AM, Howard Trickey <howard.tric...@gmail.com> > wrote: > > > Some introductory FAQ material is here: > > http://wiki.blender.org/index.php/Dev:Doc/FAQ#Source_Code_FAQ > > > > As it says there, reading all of the docs on > > http://wiki.blender.org/index.php/Dev:Source/Architecture > > is useful, though hard-going and somewhat out of date. > > > > It's probably best to start on just a small area of the code and not > worry > > about the rest. > > Follow through what happens when you execute some command in an area that > > you are interested in. > > Do what you are trying to do: fix a small problem or make a small feature > > change in that command. > > Probably doing a NURBS task isn't the best idea to start, since there is > a > > summer student right now working on revamping NURBS, and anyway that code > > is fairly old and somewhat removed from the modern part of Blender. > > > > - Howard > > > > > > On Wed, Jul 2, 2014 at 11:07 AM, John Alway <jal...@gmail.com> wrote: > > > >> Hello, > >> > >> I've been working to understand Blender code so that I can try my hand > at > >> fixing some bugs and adding some features as needed. However, I'm > finding > >> the learning curve to be quite steep. C and C++ code per se are no > >> problem for me, but it's hard to determine what the code is doing, > because > >> there are many abstract concepts that have been implemented. > >> > >> I was trying my hand at Issue T39656, just to see what it would take: > >> https://developer.blender.org/T39656 > >> > >> And, to help me along, I've been using the Visual Studio debugger and > I've > >> read many things out of the wiki, including this overview: > >> > >> http://wiki.blender.org/index.php/Dev:Source/Architecture/Overview > >> > >> However, at the end of the day, this is proving to be pretty heavy > going. > >> > >> So, I'm wondering how others have learned the code, or is it just a > matter > >> of putting in lots of time? > >> > >> I do know OpenGL and I have studied many graphical concepts, and I've > done > >> a lot of matrix math for rotating and translating objects, etc. But, > I'm > >> sure there is much to more learn, anyway. There always is! > >> > >> Anyway, I'm just looking for pointers and any kind of help on this. > >> > >> Thanks for any feedback! > >> ...Regards, > >> John > >> _______________________________________________ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
