Org:Institute/Open projects/Durian/Features wishlist

Durian Wishlist

Warning 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 , or 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 brecht@blender.org to help you get started. Some of these are more suitable for people experienced with the Blender code, those request are marked with . 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 http://developer.blender.org and link to them.

Compositing

• Histogram node also showing stuff out of 0-1 range.
• Motion blur trail support, so it is not always --o-- but also supports ----o.
• Tile-based compositing, disk caching to save memory for 4K resolution.
• 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.
• Naming of node groups
• Adjust positions for control points of RGB nodes precisely; e.g. via slider.
• Alpha output for texture nodes
• Fully customizable flares.
  • Examples of real flares: http://wiki.blender.org/index.php/User:Broken/FlareResearch
• Distort-able flares; especially at camera borders. See [1] 0:45 lower right corner.
• Adjustable Kirsch filter line thickness.
• Connectable x and y value for different nodes like blur.

Shading

• Possibility to adjust blurring strength of shade terminator.
• "Add" option for regular and volumetric materials, not only halos.
• Cavity shader.
• Shader that reacts to angle of mesh faces to each other.
• Copy standard material to node system via those little "copy material" and "paste material" buttons.
• 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).
• Procedural lightning texture.
• Procedural polygon texture, like a sphere blend but instead of a sphere a triangle, square, pentagon, hexagon, etc...
• HDR color picker.

Rendering

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

Animation

• 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.
  • Euler rotation order svn commit by Joshua.
• Support of these same things, quaternions and the things mentioned above for Objects.
  • Object rotation modes svn commit by Joshua.
• Proxies will need to be improved, for example to support multiple instances of a character with variations.
• 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.
• 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.

Rigging

• 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.
• 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.
  • SVN Commit by Joshua
• 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.
• Fix curve twisting problem by propagating frames.
  • svn commit by Campbell.
• Creating own animateable properties per bones, and display them to the animator.
• 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.

• Manipulate fcurves.

• Add objects/bones.
• Move objects/bones to different layers.
• Parent objects/bones.
• Add IK to bones.
• Add constraints to objects/bones.
• Move constraints in the stack.
• Add modifiers to objects.
• Move modifiers in the stack.
• Add and set up drivers.
• Add actions.
• Add keyframes.
• Read custom properties on bones.
• Read custom properties on objects.
• Group objects.
• Group bones.

Physics

• 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.
• 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.
• 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.
• 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.

Sequencer

• 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.
• 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.
• 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.

Scripting

• 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?).

Modeling

• Bevelweight like in 2.4x
• Extrude individual faces like in 2.4x
• 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.

UI

• 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