There have been at least 2 ideas submitted for dealing with the compositor and sequencer. This is just an entry for my 2 cents. I mentioned this out of frustration in the bf-blender mailing list a while back and then thought, it would be better to actually post it on blenderstorm. So here's ideas (pasted from my email) that I think would allow the compositor and sequencer to be more integrated and useful.

1) Compositor should have sequencer input and sequencer output nodes.

2) We need to be able to have any arbitrary number of sequencer timelines and compositor networks (correct term?) as desired. These should be data blocks contained within the scene.

3) Timelines need to be able to have the output from another timeline as an input.

4) Compositor networks need to be able to have the output from another compositor network as an input. (Yes you could have just one big ass compositor network, but this allows for breaking it up into separate data blocks.)

5) The data of the timelines / networks need to be abstracted similar to how we abstract objects and object data.

6) Get rid of the compositor / sequencer rendering options. Both are on by default. If you don't need any compositing or sequencing done, you don't create any compositor node networks or sequencer timelines. (Besides you can't really enable just one if they are as integrated with each other as this proposal is suggesting)

6b) If your scene has compositing networks and/or sequencer timelines, but you still want to do a render without those, there should be toggle button (similar to the current "compositor" and "sequencer" buttons) to enable a "direct render".

Move the API for the GUI into a separate library developed in it's own tree.

This opens up the possibility that other projects might consider using it, and would stand to gain from the added contributions of developers working on other projects.

Allow developers to tag proposals with one or more tags. Some ideas are:

-Absolutely will not happen
-Makes no sense
-Obsolete and/or Depreciated
-Already in development
-Not possible until development elsewhere is finished
-Easy fix
-Would be a major project
-Not a priority, unless you have money
-Will consider, no promises though


I'm sure there's other good ideas as well. :)

The Halo shader is currently only limited to verticies. It would be nice if there were an option to apply the same shader effect to edges rather then verticies.

There have been several instances where I've used the Halo for effects like neon light, but it's a real pain because you have to split edges up many many times to get the desired effect, and even then you have problems with the physical scale of the object, and different densities of the verticies along the subdivided edges.

Would probably mean disabling some of the options like "star" with this option enabled.

Not sure if this is a bug or a feature...

Many of the compositor nodes modify the image, however they pay no attention to the rendering option "key" or "premultiplied" when dealing with alpha. Generally they process image data using a premultiplied approach.

This can be a real PITA when using blender in combination with 3rd party apps. Especially when you have the "key" option selected for the rendering, and send it to nodes that change things using premultiplied compositing. Then you get this ugly mess that is a mix of both.

Try using a blur node on output rendered with the "key" option set. It totally screws everything up.

-Find some sort of approach that isn't vertex based.

-Support for animated objects (should be able to bake lightmaps over time into a "lightmap sequence")

-Perhaps use it for other requested features such as "emitter objects" or "glow effect"

-Make it less cumbersome to use

With this constraint added to a bone, it would work to pull the the head and tail together.

The purpose behind this is that with some more complex armatures, I end up with an IK solver that sets the location of the bone. But in some situations there is more than one correct solution to the IK, and in this type of situation, where the bone is placed within this correct range of correct IK values, is usually determined based upon how the bone was previously placed. (Sounds a little odd, but I can produce armature setups demonstrating this)

This is not always the desired solution though, and a "tension" constraint, would work to pull the bones into the preferred orientation.

It would be a lot like the stretch constraint, in that the bone would stretch to meet it's target, but would provide tension between the head and tail to try and pull them towards each other.

The tension level could be constant, or proportional to how far it is stretched, sort of like a rubberband. (I guess it would also imply variable influence in this case)

Negative values for the tension would work to push the head and tail apart.

Not really sure which category this fits under...


This proposal is to allow modifying a linked data block. There are several ways to implement this. One is to just assume it's always possible to edit external libdata, or you could require adding an "edit libdata" modifier first. There are probably other ways was well.

The objective though is to allow linking to external libdata, and then storing changes made to the external libdata in the local blend file. If changes are made to the external libdata, blender should try (if possible) to re-apply the changes to the new libdata. If not possible, let the user know what changes can't be applied, and then let the user choose if the changes that can be applied should be applied or not.

Also allow the ability to swap the linked libdata out to a different set of linked libdata (even if from a different file), but still keep the changes applied locally.