Dev:Source/Architecture/AntiFeatures

AntiFeatures

This page lists features which have been suggested that we think shouldn't be included in Blender.

Python Modifiers / Compositing / Sequence Effects

Python is not well suited for fast interactive operations on large data sets such as pixels or vertices.

Even in cases where computation can be optimized, Python has a global interpreter lock (GIL), making any operations which use it single threaded.

Using LLVM may be an option (as we already have for OSL), this would be long term project which needs to be carefully integrated into Blender's architecture.

Modifiers that Instance Geometry

Event though we already have the "Array Modifier", in general modifiers are inefficient for instancing geometry.

Blender's duplicator system should be used instead, however this system isn't currently setup to stack operations (as modifiers do).

Longer term we would like to support node trees that can be used to instance objects. This could, for example, instance objects over particle systems, point cloud data, on a surface, along curves .. etc.

Pre Selection Highlighting

Selection of faces/edges/vertices/bones/etc in Blender is not “click and guess” but IMHO one of the best working features of Blender - in which we beat other programs still. In 3d views you just don’t have singular selection possible (small elements, overlapping elements, etc). For that reason Blender has a heuristics that includes the distance to mouse, and cycles based on this distance (including on Z depth). If this doesn’t work well, I would call that a bug to solve - and have developers make it more predictable on single/2nd clicks…

Next to that, one of the key design concepts in Blender is to follow the non-modal “Select -> Operate” paradigm. Selection is the state, operations the user’s toolbox that should be fast accessible. In other programs (like Maya) they use the “Operator -> Select” approach; that means you first set the tool (translate) and then apply that on selections. In such a modal UI a preselect is more understandable to use.

See this link for original comment.

Support for Other Scripting Languages

Supporting multiple languages is not something we're currently interested in.

Embedding a language runtime has a significant maintenance overhead, so there would need to be very compelling reasons (besides developer preference) to add support for other languages or to move away from Python.

Integrating Native Widget Toolkits

Blender should run on different platforms, but we currently prefer to use our own Blender based widgets and tools like the file-selector (which is extended to support library linking and previewing Blend files).

While integrating native widget elements has some advantages, these widget elements are not portable and adding them locks us into an operating system's API.

Note that there is some low level integration (called GHOST) which handles basic window management and event handling, however this is not the same as integrating buttons, file menus, dialog boxes .. etc.

C/C++ Plugin API

At the moment we are not planning to accept binary plugins in Blender (which implies a C/C++ API).

Note: the pros and cons for this are quite involved and not covered in detail here yet.