From BlenderWiki

Jump to: navigation, search

New Developer Info

This page is meant to provide new developers with information about how the Blender development process works, where to find info and how to find a good project to work on.

Communication

Most communication happens on mailing lists, irc chat and the bug and patch trackers. See the Contact and Get Involved pages for more information about these.

No spamming or flaming on the lists or irc channel is allowed. Please stay on topic in the lists, and follow good net etiquette. Also do not send html messages to the mailing lists. Html messages can be contain a variety of security problems and as such tend to be mistrusted by many people.

Sunday IRC Meeting

If you want to start developing in Blender you will have lots of startup questions. You can ask them in the #blendercoders irc channel each day of the week.

For regular developers, every Sunday there is a development meeting in #blendercoders. It takes place at GMT 15:00, see the Sunday Meeting page for more information (including meeting notes of past meetings). The Sunday meeting is where all the developers bring each other up to speed on their various projects and make decisions on releases, merging branches, accepting features, ... .

During the meeting, stay on topic. If you want to seek approval for project ideas, or contact another developer, log in before the meeting, hang around after or message another developer personally during meeting time.

Getting Started

Building Blender

See Building Blender.

Decisions

Blender development is structured similarly to Python's BDFL model (BDFL stands for Benevolent Dictator For Life). The idea is that the project is managed by one man, in this case Ton Roosendaal, who delegates design decisions to a group of module owners, while still maintaining a veto right of what goes into Blender.

Your First Project

Once you have blender compiled you're probably wondering where to start tinkering. If you are a Blender user then there is probably some niggling thing you would like to add or change. If you are new to Blender then you will need to take a look and see what you might work on.

There are no hard and fast rules about where to start, so find an area that interests you and start looking onto it.

Some hints for your first projects:

  • An area of interest (even better, an area of Blender you use)
  • Double check it is not already done.
  • Don't choose a project that spans across many files and areas of Blender, since you may get bogged down trying to understand everything at once.

Here are some areas that can give you a foot in the door:

Small Features

Adding in small features is a good way to start getting your hands dirty, even if you dont make a patch to commit, it can evolve into something more useful, take a new direction, or spark interest in new areas to develop.

Here is a list of 'simple todos' - tasks that core developers think could be reasonably tackled as a first blender project without a major time commitment (ie a task that would take a core developer less than 4 hours to accomplish, but might take quite a bit more time for a new coder who needs to learn the code base). http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Simple_Todos

Bug Fixing

One of the easiest ways to get involved with coding Blender is by fixing bugs. Bug-fixing lets you focus on a small part of the Blender source rather than trying to understand it all at once. The list of current bugs is here. So pick an area of interest and start fixing! When you have got it, make a patch and submit it to the patch tracker as described here .

Python API

If you have used python and need to access data/functionality that is currently not available, then extending the python api can be a good place to start since there is a lot of example code and you can often start by copying functions and modifying them.

Navigating the Code

Have a look at the Files structure and Code Layout diagram.

The editors directory is usually a good place - it is where most of the operators live. Have a look at the header files and structs related to what you are interested in working on. The headers usually have the best overview of what a function does. To find the struct a simple grep or other search for struct Foo.

You can also start with writing python scripts, the API for our python tools - is similar in many ways to our C API. You can often find out where some C code lives by seeing the python tool tips by hovering over a button and seeing what the operator name is. If you add a console window you can see what is output to it when you do an action, then just search the code.

Also putting a break on a function in a debugger and doing a back trace can help you find the path code took to get to your function of interest. Or you can start blender from the commandline with the -d option and every command is printed to the console.

Debugging

Have a look at Debugging for help and hints on doing debugging. If you end up not being able to solve the bug yourself, post a bug to our Bug Tracker, if it is a bug in our code.

If it is a bug in your code, load your test file and the information you have found out about the bug to pasteall.org then ask for help in #blendercoders in irc.freenode.net. If no-one can help you there you can try emailing bf-committers@blender.org.

Development Process

Steps for getting a patch into Blender

  1. Find an area in Blender you want to improve upon. If you need inspiration, check Blenderstorm or the Requests area (barely up to date). You can also scan the forums on blender.org or blenderartists.org.
  2. Find whoever "owns" the code and check if he agrees with your project. See the list of module owners. Generally the best idea is to talk to the owner(s) in #blendercoders, but new developers might want to email the mailing list instead.
  3. Post a design document on this wiki, creating a new page linked from the Projects page.
  4. Do the actual coding :)
  5. Make a patch, see Patches. Making the patch isn't particularly hard, what makes this part annoying is the wait for the patch to be reviewed, which can take weeks if you push for it and months if you don't, and the fact that the module owner may heavily modify your patch.

Release Process

For more information about the release schedule, see Release Cycles and Current Projects to understand the schedule and times when new features can get in and releases are made.