[Bf-compositor] [enh] How to deal with thumbnail previews
Jeroen Bakker
j.bakker at atmind.nl
Mon Dec 2 21:33:39 CET 2013
Hi all,
first patch is being reviewed for the thumbnail previews.
http://developer.blender.org/D69
Would be great to get some user feedback!
Jeroen & Monique
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/20131202/1930a54a/attachment-0001.htm
More information about the Bf-compositor
mailing list