http://www.blenderstorm.org/qapoll/ideas en-us Fri, 21-Nov-2008 00:00:00 UTC Fri, 21-Nov-2008 00:00:00 UTC QAPoll module http://www.blenderstorm.org/qapoll/ideas/item/441/
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".



Attachments:
No attachments. ]]> Fri, 21-Nov-2008 00:00:00 UTC http://www.blenderstorm.org/qapoll/ideas/item/441/ http://www.blenderstorm.org/qapoll/ideas/item/513/
-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. :)


Attachments:
No attachments. ]]> Fri, 21-Nov-2008 00:00:00 UTC http://www.blenderstorm.org/qapoll/ideas/item/513/ http://www.blenderstorm.org/qapoll/ideas/item/443/
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.

Attachments:
No attachments. ]]> Fri, 21-Nov-2008 00:00:00 UTC http://www.blenderstorm.org/qapoll/ideas/item/443/ http://www.blenderstorm.org/qapoll/ideas/item/448/
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.

Attachments:
No attachments. ]]> Fri, 21-Nov-2008 00:00:00 UTC http://www.blenderstorm.org/qapoll/ideas/item/448/ http://www.blenderstorm.org/qapoll/ideas/item/442/
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.

Attachments:
No attachments. ]]> Fri, 21-Nov-2008 00:00:00 UTC http://www.blenderstorm.org/qapoll/ideas/item/442/ http://www.blenderstorm.org/qapoll/ideas/item/487/
-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

Attachments:
No attachments. ]]> Fri, 21-Nov-2008 00:00:00 UTC http://www.blenderstorm.org/qapoll/ideas/item/487/ http://www.blenderstorm.org/qapoll/ideas/item/444/
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.

Attachments:
No attachments. ]]> Fri, 21-Nov-2008 00:00:00 UTC http://www.blenderstorm.org/qapoll/ideas/item/444/ http://www.blenderstorm.org/qapoll/ideas/item/502/

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.



Attachments:
No attachments. ]]> Fri, 21-Nov-2008 00:00:00 UTC http://www.blenderstorm.org/qapoll/ideas/item/502/ http://www.blenderstorm.org/qapoll/ideas/item/639/
Changes that need to be made:

-The sequencer currently allows "Scene" as an input. This is a bad idea. There is no way to set it up so that you have the compositor output from one scene and the render output from another in the same sequencer. Input sources from within Blender would need to be scene->renderPort or scene->renderLayer

-In relation to the previous item, render settings need to be local to each Scene rather than global.

-Sequencer could have input and/or output to a renderPort

-Any number of sequences possible per scene. Be able to name them.

-Compositor could have input and/or output as a renderPort as well.

-Any number of compositors possible per scene. Be able to name them.

-No compositor or sequencer buttons in render settings. This would instead be determined by "Use Nodes" button in node editor and add a "Use Sequencer" button in sequencer. With multiple node graphs or sequences per scene, each would have it's own on/off button. If all node graphs and sequencers are turned off, it renders 3d directly.

-If a sequencer or node editor is turned on, the frames used in them ignore the start and stop times set in the timeline. (Maybe it already does this, I'll have to check...)


The resulting input/output types (for internal data routing) would be:

- 3D Renderer -> renderLayer
- renderLayer OR renderPort -> compositor -> renderPort
- renderLayer OR renderPort -> sequencer -> renderPort


The Data hierarchy would be:

Scene 1
|--- RenderLayers
| |--- 1
| |--- 2
| |--- (...)
|--- RenderPorts
|--- 1
|--- 2
|--- (...)
Scene 2
|--- (...)




Attachments:
No attachments. ]]> Fri, 21-Nov-2008 00:00:00 UTC http://www.blenderstorm.org/qapoll/ideas/item/639/