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.
There are various communication channels used.
- BF-Committers Mailing List - for public discussions, where official decisions are made.
- Issue Tracker for bugs, patches and managing design tasks.
- DevTalk Forum - for general developer discussion & questions.
- IRC Chat - for informal conversation.
See the Contact page for more information.
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.
When in doubt and no particular channel seems to match your question, mail the bf-committers mailing list and you will get an answer there or get redirected to the right channel.
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.
Weekly IRC Meeting
For regular developers, every week there is a development meeting in #blendercoders every Monday. The weekly meeting is on an alternating schedule of 10 CET and 18 CET (Central European Time). Note CET will change to CEST (Central European Summer Time) over the summer. The Weekly meeting is where developers bring each other up to speed on their various projects and make decisions on releases, merging branches, accepting features, ... .
During the meeting, please 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.
See Building Blender.
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 person, 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.
The full list of wantedtodo features can be found on the Todo page.
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:
Adding in small features is a good way to start getting your hands dirty, even if you don't make a patch to commit. The feature you worked on can evolve into something more useful, take a new direction, or spark interest in new areas to develop.
Here is a list of quick hacks - tasks that core developers think could be reasonably tackled as a first blender project without a major time commitment (these tasks typically 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).
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 on developer.blender.org. So pick an area of interest and start fixing! When you have got it, make a patch and submit it.
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 command line with the -d option and every command is printed to the console.
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 firstname.lastname@example.org.
Steps for getting a patch into Blender
- Find an area in Blender you want to improve upon.
- If it's a non-trivial feature, check in advance if Blender developers agree with the project and design, to avoid doing work for nothing. Contacting developers is typically done on the developer forums, or on #blendercoders on IRC. To talk to the individual owners of parts of the code, see the list of module owners
- Do the actual coding :)
- Once you have code, see the Contributing Code section on how to make a patch get it submitted, reviewed and included.
We encourage everyone to use the Blender Wiki to document code work and to share proposals. Note that we strictly apply the rule "No code gets in trunk without documentation!". Also never hesitate to include good example .blend files and tests and videos showing the feature.
People who only want to help with technical documentation are welcome too. Just use the general contact information here to get started.