Building a mental model of Blender code set

Archive Blender Development
1

I’m trying to build up my mental model of the inner workings of the Blender code set, and looking for some interesting lines of code to put break points on; probably ones that sit quite deep in a call stack; to give some idea of how the code fits together.

Any suggestions of interesting parts to look at most welcome?

Some areas that I think could be revealing (if they exist) -

Is there an “array of objects” that contains all objects in the 3D viewport? Or perhaps a few locations in the code that hold these references?

Any tips on code segments that might inspire some ah-ha moments for me on how the UI render cycle works?

Just as a thought experiment - if I wanted to create a browser based client; at what points in the code would it make sense to think about building an API for that type of client?

Thanks

1 Like
2

This may be the best place to look.
And more specifically, here.

Blender’s code is pretty organized. Here’s what I’ve been able to gather by reading commit logs for a long time: Blenkernel is the “core” of Blender’s code. Blenlib is the code for parsing .blend files, depsgraph is of course the depsgraph code. Most of Blender’s code is pretty well self-explained, really. The draw folder holds EEVEE’s code.

Is there an “array of objects” that contains all objects in the 3D viewport? Or perhaps a few locations in the code that hold these references?

In Python this is bpy.data.objects. Within Blender, there’s something called DNA which holds the original data of the scene, and then there’s RNA which holds the structures that “live” in RAM, providing low-level data access (this is what the Python API interacts with).

That should be enough to get you started, I think… although I could be wrong so feel free to fact-check me.

3

You can check how you click a button in the UI, which is drawn and defined by the files in blender/release/scripts/startup/bl_ui & the operators that are defined in functions like


void WM_OT_splash_about(wmOperatorType *ot)
{
  ot->name = "About Blender";
  ot->idname = "WM_OT_splash_about";
...

For the objects in the scene, see ViewLayer struct and its member object_bases. There are much more direct methods to get specific things, in context.c.

You can check https://developer.blender.org/diffusion/B/branches/master/ to see how someone starts off for a change.

You can spend time on bug tracker, subscribe to high priority tasks and see the commit when they’re fixed.

4

Thanks for all the pointers!

Do you have any pull requests that come to mind that go through some “interesting” changes? Agree those can be a great way to start to get a feel for a code set

5

To get an overview of a large code-base at both the big-picture level, right down to the details, you can try running the application in a debugger.

  • Put a break-point in main and step over the code that runs on startup (you will want to step over / out-of functions, otherwise this will take a long time).

  • Try take the opposite approach of putting a break-point in a part of the code that interests you (an operators execution function is a good place to start). Then you can run the operation to hit the break point. Now try inspecting the call-stack, to see how it was activated.

  • Something else you can try is run any operation that takes a second or so, and break the running Blender process, see where the time is being spent (this isn’t a substitute for bench-marking, it’s just a way of pausing the application to see what it’s doing), and can show you parts of the code you wouldn’t have otherwise thought to look into.

This can help you build a mental model of how functionality is composed at different levels. It’s not a complete solution, but I’ve found it useful when looking into large code-bases I’m not familier with.

5 Likes