From BlenderWiki

Jump to: navigation, search

Durian Wishlist

This list is to be used by Durian artists and developers only to collect features for Durian.
Random feature requests by people not involved with the durian project will be removed.

All feature request are marked as having Priority-high.png, Priority-medium.png or Priority-low.png importance to complete the project. Though that is only relative, none of these is unimportant.

If you're interested in working on one of these, you can contact to help you get started. Some of these are more suitable for people experienced with the Blender code, those request are marked with Priority-experienced.png. You're still invited to work on such features, but remember that you need to be able to do 80% of the work yourself.

If topics are too uncertain or requre too much discussion, we may create design-tasks on and link to them.


  • Priority-high.png Histogram node also showing stuff out of 0-1 range.
  • Priority-high.png Motion blur trail support, so it is not always --o-- but also supports ----o.
  • Priority-high.png Tile-based compositing, disk caching to save memory for 4K resolution.
  • Priority-high.png Make all nodes work in percentages relative to the image size, rather than in pixels. For example filter, translate, blur should all work without specifying anything in pixels.
  • Priority-high.png Naming of node groups
  • Priority-medium.png Adjust positions for control points of RGB nodes precisely; e.g. via slider.
  • Priority-medium.png Alpha output for texture nodes
  • Priority-low.png Fully customizable flares.
  • Priority-low.png Distort-able flares; especially at camera borders. See [1] 0:45 lower right corner.
  • Priority-low.png Adjustable Kirsch filter line thickness.
  • Priority-low.png Connectable x and y value for different nodes like blur.


  • Priority-medium.png Possibility to adjust blurring strength of shade terminator.
  • Priority-medium.png "Add" option for regular and volumetric materials, not only halos.
  • Priority-medium.png Cavity shader.
  • Priority-medium.png Shader that reacts to angle of mesh faces to each other.
  • Priority-medium.png Copy standard material to node system via those little "copy material" and "paste material" buttons.
  • Priority-medium.png Change the color of lamps depending on distance, eg. white in close range and orange further away. This could be a implemented as a Distance texture coordinate for lamps (next to Global, View, Object).
  • Priority-low.png Procedural lightning texture.
  • Priority-low.png Procedural polygon texture, like a sphere blend but instead of a sphere a triangle, square, pentagon, hexagon, etc...
  • Priority-low.png HDR color picker.


  • Priority-medium.png Border render doesn't reset whole render result, but only the marked part.
  • True 3D motion blur, and motion blurred shadows.


  • Priority-high.png Priority-experienced.png Alternative to quaternions for bone rotations. Eulers are already there, customizable Euler rotation order, axis-angle support and per axis locking are important as well.
  • Priority-high.png Priority-experienced.png Support of these same things, quaternions and the things mentioned above for Objects.
  • Priority-high.png Priority-experienced.png Proxies will need to be improved, for example to support multiple instances of a character with variations.
  • Priority-medium.png Priority-experienced.png Transform manipulator could have handles corresponding to actually Euler axes used by the bone/object. Right now each axis does not correspond to one f-curve if another axis has been rotated for example (the 3 axes are not necessarily orthogonal then even). It also helps as a visualization of where the gimbal lock is. Example of such a gimbal manipulator.
  • Priority-low.png Animating the camera position and rotation by doing real life recording would be an interesting feature to have. Motion tracking would be needed for this, completely using open source tools of course, and the libmv project is a promising candidate. This would not be natively integrated, but use a script most likely.


  • Priority-high.png Priority-experienced.png Preserve angles > 180° throughout the animation system. This may not be practically feasible to do it completely, mainly what would be good support is preserving this for constraints, and to avoid flips for dual quaternion deformation. Quaternions go up to 360° which would be enough. The idea is simple, implementation is complex, but considered important.
  • Priority-high.png Spline IK. This in fact has very little to do with IK, quite the opposite, it's an FK method. It is a constraint to let n bones align with a curve. In this way it can work like the IK constraint, affecting multiple bones. There should be an option to have the bones stretch to fit, or to keep their length and possibly not reach or go beyond the edge of the curve.
  • Priority-high.png Option for bones to have the bone translation values in armature rather than bone space for posing. This would be useful to present more intuitive values and animation curves to the animator, so that e.g. moving an IK target for a hand up will work with only a Z axis curve. This could be taking further with full local spaces for armature and bone rotations and translations, but for now an option to have translation in armature space seems sufficient.
  • Priority-high.png Fix curve twisting problem by propagating frames.
  • Priority-medium.png Priority-experienced.png Creating own animateable properties per bones, and display them to the animator.
  • Priority-low.png Priority-experienced.png Better support for scripting rigs. E.g. when animator selects a bone, hide or show some things, or when switching IK/FK, doing some operation, etc. Preferably not as a space handler type thing, but integrated and distributed with the rig.

Rigging Python API

These things are exposed via operators but not easy to use yet due to operator/context limitations.

  • Priority-high.pngManipulate fcurves.
  • Priority-high.pngAdd objects/bones.
  • Priority-high.pngMove objects/bones to different layers.
  • Priority-high.pngParent objects/bones.
  • Priority-high.pngAdd IK to bones.
  • Priority-high.pngAdd constraints to objects/bones.
  • Priority-high.pngMove constraints in the stack.
  • Priority-high.pngAdd modifiers to objects.
  • Priority-high.pngMove modifiers in the stack.
  • Priority-high.pngAdd and set up drivers.
  • Priority-high.pngAdd actions.
  • Priority-high.pngAdd keyframes.
  • Priority-high.pngRead custom properties on bones.
  • Priority-high.pngRead custom properties on objects.
  • Priority-high.pngGroup objects.
  • Priority-high.pngGroup bones.


  • Priority-high.png Natively integrated Bullet rigid body physics system. This should work at the level of other physics systems, directly showing results in the viewports, using fields and collision, visual editing of constraints, etc.
  • Priority-high.png Improved hair simulation. Currently supported through softbodies, but hair simulations requires strict length preservation, hair volume preservation, and can perhaps be simulated more efficiently since individual hairs can be assumed to be only 1-dimensional.
  • Priority-high.png Priority-experienced.png Point caches working better with linked libraries, supporting linked objects to both get a new point cache for the scene, or to reuse an existing cache.
  • Apply force fields to edited Hair.
  • Priority-high.png Better collision detection for cloth. Right now it fails even in common cases (clothing on character). Something like [2] and [3] (maybe there are newer and better papers, but these describe the kind of robustness desired). Test cases can be provided for whomever wants to work on this.


  • Priority-high.png Snapping! Snapping should be possible when transforming strips, or transforming the in and out points of strips. Snapping should also work vertically: i.e. when moving a strip on another track it should be able to snap to the in or out point of the strip below it.
  • Overlapping strips after transform should not be displaced to another track. Instead it should *overwrite* the frames being overlapped. In effect it would be manipulating the adjacent clip's in (or out) point to accommodate the incoming strip. If a strip is dropped in the middle of a strip, a portion of the strip would be overwritten and it would effectively be split in two segments.
  • Priority-low.png Support a kind view of different clips and images to be imported quickly, rather than going through file browsing each time. One way to implement this would not be a new space, but adding drag & drop from the file/library browser to the sequencer.
  • Priority-low.png Display thumbnail images of clips and sound waves on strips.
  • Implement basic 3-point edit system (definition: [4]). This would allow the user to set edit points on a piece of media before inserting it in the timeline-- and would therefore need to be integrated with the new view mentioned above.
  • Add ripple edit and slip edit functionality (definitions: [5] and [6])
  • Support additional selection tools to avoid tedious box-selection (i.e. a tool or hotkey to select strips to the right on *all* tracks, not just active track)
  • Transform control should not be an effect, but instead properties of any given 'video' strip. Transform x,y, scale x,y, and rotation should be accessible and animatable via the 'n' key.
  • Add jog keys to play forward and backward at different speeds. (Commonly mapped to JKL keys).
  • Make the empty space between clips selectable. Deleting empty space is a ripple delete edit.
  • K or Shift-K should cut all tracks at the playhead if nothing is selected. Only if a particular clip is selected should the tool be limited.
  • Add a way to navigate through the edit by jumping the playhead to edit points. For example: PAGE UP and PAGE DOWN to jump to the next and previous cuts.
  • Add linking tools to link the audio to the video. Clicking one will select both clips.
  • Add audio crossfade transition.
  • EXTEND should work by rolling the edit point to whichever side of the playhead the mouse is on. Extend to the left should be equivalent to grabbing the in handle and moving it-- extend to the right should work like grabbing the out handle and moving it out.


  • Properties that don't work in the current mode should become read-only, and raise the appropriate exceptions when you try to modify them. Right now trying to modify them just silently fails: they revert their value when you leave the current mode. For example, modifying bones[n].armature_head while in armature edit mode. The value just reverts when you leave edit mode.
  • A convenience "roll" property for bones: bones[n].roll
  • Knowing what armature a bone belongs to: bones[n].armature
  • Weird/confusing names --> suggestions for better names:
    • bones[n].armature_head --> bones[n].head
    • bones[n].armature_tail --> bones[n].tail
    • bones[n].armature_matrix --> bones[n].matrix
  • bones[n].active is really bad. The active bone in an armature should be listed under the armature (i.e. objects["Armature"].active_bone), not a flag on each bone.
  • An api function to find an object's children.
  • A way to know what the current scene is, even if you don't have access to a context (although maybe this isn't the design for how Blender works? Is it planned to allow multiple scenes opened in different contexts?).


  • Priority-medium.png Bevelweight like in 2.4x
  • Priority-medium.png Extrude individual faces like in 2.4x
  • Priority-low.png Removing edge loop should move the loop towards the closest edge
  • Proportional Editing in Object Mode
  • When adding/moving particles with dupli objects assigned to them, it would be useful if their shape was taken into account for collision detection so objects can be placed quickly without having to adjust the position each particle the avoid the object intersecting.
  • Alternatively or additionally, the transform system could compute do such collisions when moving objects to allow quickly placing them non-intersecting into the scene.


  • Node link connecting could be more efficient. Some ideas:
    • Clickable region around node link input/output can be bigger, like e.g. vertex selection, choosing the closest link input/output.
    • Moving mouse over node and pressing 1,2,3 could be used to start and end creating a link for the nth input/output without having to be exactly over it.
    • Ending a link could be done by moving the mouse over a node, which would then automatically connect it to the first free input, after which mouse wheel scroll would allow to select a different one.
  • pin image added back