[Bf-compositor] [enh] How to deal with thumbnail previews
lukas.toenne at gmail.com
Tue Nov 19 08:42:18 CET 2013
I promised to look into this, but i don't mind if somebody else will pick
it up :)
Currently there is the "Hide Previews" button in compositor nodes, but this
is not working atm due to the new node categories system and it's also not
really solid enough (it switches off previews in the node_add_node
function, but this is only called for a handful of C operators now). I
think this should be removed.
Then there is the question at which point the preview flag should be
un-set. It could be done as part of the node categories system, which
supports initialization of nodes with a settings dictionary (in python).
But there are a number of nodes that can be added with non-python operators
which would lack this behavior then (viewers, file output, default nodes in
new trees). Also since the feature is common to all the compo nodes i would
suggest deeper integration.
It can be done as a common init function for compo nodes (initfunc in
bNodeType). It's a bit of monkey work to add superclass calls, but not too
static void node_composit_init_common(bNodeTree *UNUSED(ntree), bNode *node)
/* disable all compositor node previews by default */
node->flag &= ~NODE_PREVIEW;
Subclasses with init() should call the superclass method (a bit awkward in
C, will become nicer if we move nodes to python):
static void node_composit_init_boxmask(bNodeTree *ntree, bNode *node)
NodeBoxMask *data = MEM_callocN(sizeof(NodeBoxMask), "NodeBoxMask");
data->x = 0.5;
data->y = 0.5;
data->width = 0.2;
data->height = 0.1;
data->rotation = 0.0;
node->storage = data;
Input nodes can then set the flag explicitly:
static void node_composit_init_image(bNodeTree *ntree, bNode *node)
ImageUser *iuser = MEM_callocN(sizeof(ImageUser), "node image user");
/* enable previews for input nodes */
node->flag |= NODE_PREVIEW;
node->storage = iuser;
iuser->frames = 1;
iuser->sfra = 1;
iuser->fie_ima = 2;
iuser->ok = 1;
/* setup initial outputs */
On Tue, Nov 19, 2013 at 8:16 AM, Sebastian König
<sebastiankoenig at posteo.de>wrote:
> Yes, I think it would be fine to make thumbnails just be hidden by default.
> However, it’s also true they do provide some very helpful feedback when it
> comes to input nodes.
> Even though it would make the default „hidden preview“ a bit inconsistent,
> i do believe this would be the most desirable behavior:
> - Input nodes are always created with their previews enabled.
> - Every other node has the preview disabled, except for the viewer node.
> - Since the composite output makes the whole node-tree calculate all the
> time when it has thumbnail expanded I think it should also be collapsed by
> default. (also in startup.blend)
> So, speaking as a non developer I think you only would have to exclude the
> input nodes from the button that controls the default behavior for new
> nodes, though in reality I suppose there’d have to be some if/else stuff. :)
> Sebastian König
> Schenkendorfstrasse 45
> 04275 Leipzig
> sebastiankoenig at posteo.de
> On 19. November 2013 at 05:46:31, LswaN (subscription57 at live.com<//subscription57 at live.com>)
> I'd like to add my 2 cents here. Regarding the thumbnails, I think hidden
> by default is a bit better than removing them altogether. I agree with
> David that thumbs can be helpful when you just need a quick at-a-glance
> view of what is going on in a set of nodes.
> Also, Blender did auto-link new nodes to your selected node at one time,
> but iirc the feature was removed because people often found its choices for
> linking confusing/unpredictable. For example, if you added a mix node, you
> might end up with the auto-link connected to the wrong input of the mix
> Personally, I liked the feature (even though it wasn't perfect), so I
> wouldn't mind seeing it make a comeback.
> On 11/18/2013 8:57 PM, Aditia A. Pratama wrote:
> I agree with sean. Thumbs take to much space for me...but yeah for only
> for non-footage nodes. I also propose to hide node by default option in
> user pref, so when calling node it will in hidden mode which is very easy
> to navigate and attach.
> There's also one usability request by me, but need your opinion guys. How
> about auto link nodes. Let say I've selected image node and then I called
> blur node, it will auto linked by last selected node, so instead drag your
> node around it will be more faster that way IMO.
> For viewer node, i think it's better to have canvas like vse.
> On Nov 19, 2013 5:37 AM, "David McSween" <3pointedit at gmail.com> wrote:
>> Yes I agree that thumbs can become clutter and are often inaccurate but
>> they provide handy visual ques or sign posts for your process. Perhaps
>> default to closed/hidden would be better. They can be replaced with viewer
>> nodes but you can't send multiple viewer nodes to the uv image window. It
>> would be really helpful to allocate unique names to viewer nodes, so that
>> you can call them independently on their own uv image windows. This would
>> allow the user to compare details of node outputs.
>> On 19 Nov 2013 07:30, "Sean Kennedy" <mack_dadd2 at hotmail.com> wrote:
>>> I'm all for removing thumbnails, at least on non-footage nodes. It
>>> could be useful on image nodes, movie clips, etc, because if you have a lot
>>> of footage being used, it could help keep it visually organized. But even
>>> on those, making it default to not show the thumbnail is ideal.
>>> Date: Mon, 18 Nov 2013 22:20:08 +0100
>>> From: m.dewanchand at atmind.nl
>>> To: bf-compositor at blender.org
>>> Subject: Re: [Bf-compositor] Wiki Page
>>> Hi Sebastian,
>>> Nice! Just missing some priorities....
>>> Regarding status updates; when starting a project the developer can
>>> create a page for it, containing details about the project / solution /
>>> progress, and link it to the main page.
>>> So should we start removing thumbnail previews? If yes, do you also want
>>> to remove the preview from the input- and output nodes?
>>> J & M
>>> Sebastian König schreef op 11/8/13 1:25 PM:
>>> Hey all!
>>> I have started to fill in the wiki page.
>>> I'm not super experienced with Wiki editing, so feel free to edit and
>>> I am also open to suggestions how to improve the
>>> Probably there should also be some kind of indication what’s being
>>> worked on, what’s the status etc.
>>> More to come.
>>> Bf-compositor mailing listBf-compositor at blender.orghttp://lists.blender.org/mailman/listinfo/bf-compositor
>>> _______________________________________________ Bf-compositor mailing
>>> list Bf-compositor at blender.org
>>> Bf-compositor mailing list
>>> Bf-compositor at blender.org
>> Bf-compositor mailing list
>> Bf-compositor at blender.org
> Bf-compositor mailing listBf-compositor at blender.orghttp://lists.blender.org/mailman/listinfo/bf-compositor
> Bf-compositor mailing list
> Bf-compositor at blender.org
> Bf-compositor mailing list
> Bf-compositor at blender.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-compositor