From BlenderWiki

GSoC 2016: Layer Manager Proposal

Synopsis

This is a proposal for an improved layer management system that adds industry standard features for organizing scene content in Blender. This includes the ability to use as many layers as needed, as well as naming, grouping and ordering them.

A layer manager as proposed here is a standard feature in many other applications. Blender has a layer system too, but it's far behind more common solutions, mostly out of historical reasons. While the old layer system in Blender has served us well for many years, it's time to upgrade it to a more practical solution.

Benefits

A decent layer manager can be an incredible useful tool when it comes to handling a scene with lots of assets. The main benefits would be:

• Nameable layers
• More practical amount of layers
• Groupable layers
• More intuitive layer management
• Toggling visibilitiy of entire layer groups
• Sortable layers
• Filtering layers/groups

Deliverables

• A greatly improved layer management system.
• An API that easily allows adding new features or doing more involved changes in future.
• User level documentation.
• Complete code documentation coverage (doxygen?).

Project Details

Interface

The interface part of this proposal is heavily based on a proposal by Paweł Łyczkowski and the feedback he got (see T38384).

The actual layer manager would be located in two places:

• In The Render Layers context of the properties editor.
• In a menu placed in the 3D View header, for quick access.

More info will be added here as soon as decisions have been made.

Code

How to support more layers

Special attention is needed to find a way to check the visibility of a layer if we want to support an unlimited amount of them (or at least many more). There are many ways to realize them (linked lists, arrays, hash tables, ...), but a really performant solution is crucial, since a lot of visibility checks are done one every redraw in Blender. Even slight performance differences in the layer visibility checks can have a huge impact. Bit fields allow greatly optimized operations and thus are really fast (our current layer system uses bit fields too). The issue with them is that they are of a fixed size. It would be possible to create a more dynamic bit field though, by storing an array of bit fields which would only allocate as much memory as needed.
Example to make it more clear what is meant with that: Using ints for the bit fields, we had 32 bits (meaning up to 32 layers) by default. If the user adds a 33rd layer, we allocate 2 ints instead of one, which results in 64 available bits (and up to 64 layers).
Alternatively, we could use a bit field of a long double which would give us 126 bits (up to 126 layers). The downside of this implementation would be that it would be doing a bitwise operation with 126 bits, even if there are only a couple of layers. This *might* have a measurable performance impact.

To find the best solution, some benchmarking with huge scenes should be done.

Note that to avoid issues from abuse or errors in scripts, we should still add a maximum layer number though (e.g. 256).

Layer API

In the current code base we just do hardcoded layer-visibility checks all over. It would be much better to have this handled behind an API though, so that it's easy to change how we do the visibility check. This API would be the central code for the new layer manager.

Project Schedule

Note that the GSoC coding period overlaps with the exams period at my university (July). This means that I'll be a bit distracted during that time and might not be able to work full steam on the project. To compensate, I'll likely start the work a bit before the official coding period starts and use August to eventually catch up (I'll have holidays then).

This is a rough schedule for planning (ignoring the time I'd need for exam preparation, it's hard to predict when this would happen exactly):

1. - 2. Week	Move all low level scene and object layer data accesses into an initial API; make local view storage independent from layer bit fields. Functionality shouldn't be affected. (Checked code, there's a lot to be done here. Making sure everything works might take more than 2 weeks even)
3. Week	Add support for naming, adding and removing layers (involves adding a simple GUI for testing and further developing layer management API).
4. Week	Hook up the new system with compositor, Cycles, Freestyle, ...
5. Week	Work on a more drafted GUI so that final look and feel becomes visible.
6. Week	Implement quick-access popup, invoked from menu in 3D view header (some work needs to be done to support a popup that makes it usable with the layer management UI).
7. Week	Add support for reordering and grouping layers.
8. Week	Add layer management Python API
9. Week	Write an in-depth source code documentation
Remaining time	Fixes, polish, cleanup - make everything ready for master. And last but not least: User level docs! :)

The schedule should be flexible enough to allow some shifting due to unexpected issues I might (will!) face.

Bio

I am doing my Bachelor of Science in Media Informatics at the University of Applied Sciences in Zweibrücken, Germany. My main interests are programming, music and sports.
Early 2014, I started getting involved as a Blender developer, focusing in the user interface. For half a year I worked for the Blender Foundation doing two days per week general development support. I'm also member of the core UI team and co-owner of the UI code module.

My most notable projects were Custom Manipulators (in progress still) and Node Auto-offset.