[Bf-compositor] [enh] How to deal with thumbnail previews
Jeroen Bakker
j.bakker at atmind.nl
Thu Nov 21 18:57:42 CET 2013
Hi!
Did you know that you can already set the header colors of the node
categories. Not all categories are there, but the option is already
available. Also are the colors not distinctive. Perhaps we should make
sure that all node categories can be configured:
In [User Preferences => Themes => Node editor] we can find the next options
- In/Out node
- Operator node
- Matte node
- Converter node
- Distort node
So we are just missing:
<compositor categories>
- Color node
- Filter node
- Vector node
<non compositor categories>
- Texture node
- Shader node
- Script node
- Pattern node
And we need to check if we want to have separate themes for input and
output nodes
Regards.
On 11/19/2013 07:43 PM, Sean Kennedy wrote:
> I LOVE these ideas!
>
> Default colors for nodes is great. It would be most useful to color
> code them by the categories listed in the add menu (Input, Output,
> Color, etc...). For example, all Input node types would be green,
> outputs could be red, color nodes could be blue, etc.
>
> birds eye view is useful, but it would also be handy to be able to
> turn it off. Personally, I would only find it useful for very large
> complex node trees. Otherwise I'd want it off. Also, if performance
> and speed takes a hit while it updates, it's not worth having, in my
> opinion.
>
> Comment node! Yes please! :) Something collapsable, so it can be small
> and only opened and read when the user requests. But the collapsed
> version should still show the name of the node, or the first word or
> two of the comment.
>
> Great list of minor upgrades!
>
> ------------------------------------------------------------------------
> Date: Tue, 19 Nov 2013 19:29:02 +0100
> From: j.bakker at atmind.nl
> To: bf-compositor at blender.org
> Subject: Re: [Bf-compositor] [enh] How to deal with thumbnail previews
>
> Hi All,
>
> Showing thumbnails for input nodes (image, texture, movie renderlayer)
> is ok, they are almost free of cost.
>
> As one usage of thumbnails is for navigation support, we should also
> take other options into account like:
> - default colors for nodes. (a cheaper way for visual clues). The
> framenode and node colors are already possible, but take time to
> setup. So why not add some default color templates.
> - add a bird eye view
> - adding possibilities to write a note/comment (comment node, or
> directly on the grid)
>
> There are some special cases like:
> - Levels node does not output a preview, in the old compositor it
> showed a histogram, but currently it ain't displaying anything.
> - Compositor output preview is quite a heavy preview. During mango it
> was disconnected when working, and sometimes forgot to connect back
> when sending to the render farm.
>
> @Lukas: We will pick this up!
>
> Cheers,
> Jeroen & Monique
>
>
>
>
> On 11/19/2013 10:01 AM, Bartek Skorupa (priv) wrote:
>
> In case of thumbnails I'd suggest a bit different approach:
> Let's maybe treat possibility of having thumbnails as an
> additional feature.
> Instead of saying "Hide Previews", let's say "Show Previews" and
> have it off by default.
>
> I wouldn't go for having different behaviors depending on node
> type. It's not that difficult to hit H when you really want the
> thumbnail on.
>
> Bartek Skorupa
>
> www.bartekskorupa.com <http://www.bartekskorupa.com>
>
> On 19 lis 2013, at 08:42, Lukas Tönne <lukas.toenne at gmail.com
> <mailto:lukas.toenne at gmail.com>> wrote:
>
> 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 difficult:
>
> 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");
>
> node_composit_init_common(ntree, node);
>
> 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");
>
> node_composit_init_common(ntree, node);
> /* 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 */
> cmp_node_image_verify_outputs(ntree, node);
> }
>
>
>
> On Tue, Nov 19, 2013 at 8:16 AM, Sebastian König
> <sebastiankoenig at posteo.de <mailto:sebastiankoenig at posteo.de>>
> wrote:
>
> Hey!
>
> 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
>
>
> --
> Sebastian König
> Schenkendorfstrasse 45
> 04275 Leipzig
> Germany
> sebastiankoenig at posteo.de <mailto:sebastiankoenig at posteo.de>
> www.3dzentrale.com <http://www.3dzentrale.com/>
>
> On 19. November 2013 at 05:46:31, LswaN
> (subscription57 at live.com
> <mailto://subscription57@live.com>) wrote:
>
> 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 node.
> 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
> <mailto: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
> <mailto: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.
>
> sean
>
> ------------------------------------------------------------------------
> Date: Mon, 18 Nov 2013 22:20:08 +0100
> From: m.dewanchand at atmind.nl
> <mailto:m.dewanchand at atmind.nl>
> To: bf-compositor at blender.org
> <mailto: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?
>
> Rgds,
> J & M
>
> Sebastian König schreef op 11/8/13 1:25 PM:
>
> Hey all!
>
> I have started to fill in the wiki page.
> http://wiki.blender.org/index.php/Dev:Ref/Proposals/Compositor
> I'm not super experienced with Wiki
> editing, so feel free to edit and
> elaborate.
> I am also open to suggestions how to
> improve the order/appearance/structure.
>
> Probably there should also be some
> kind of indication what's being worked
> on, what's the status etc.
>
> More to come.
>
> Cheers!
>
> Sebastian
>
>
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org <mailto:Bf-compositor at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> <mailto:Bf-compositor at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> <mailto:Bf-compositor at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> <mailto:Bf-compositor at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org <mailto:Bf-compositor at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> <mailto:Bf-compositor at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org <mailto:Bf-compositor at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org <mailto:Bf-compositor at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org <mailto:Bf-compositor at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
>
> _______________________________________________ Bf-compositor mailing
> list Bf-compositor at blender.org
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> http://lists.blender.org/mailman/listinfo/bf-compositor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-compositor/attachments/20131121/3a3bb7ba/attachment-0001.htm
More information about the Bf-compositor
mailing list