[Bf-compositor] [enh] How to deal with thumbnail previews
Francesco Paglia
f.paglia.80 at gmail.com
Mon Dec 2 23:13:19 CET 2013
same here with ubuntu 64 :)
2013/12/2 Sean Kennedy <mack_dadd2 at hotmail.com>
> If any creates a 64bit Win build, I'd be happy to test it out!
>
> Sean
>
> ------------------------------
> Date: Mon, 2 Dec 2013 21:33:39 +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,
>
> 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
>
> On 19 lis 2013, at 08:42, Lukas Tönne <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> 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
> www.3dzentrale.com
>
> On 19. November 2013 at 05:46:31, LswaN (subscription57 at live.com<//subscription57 at 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> 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.
>
> sean
>
> ------------------------------
> 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?
>
> 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 listBf-compositor at blender.orghttp://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
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
>
> _______________________________________________
> Bf-compositor mailing listBf-compositor at blender.orghttp://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
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
>
>
> _______________________________________________
> Bf-compositor mailing listBf-compositor at blender.orghttp://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 listBf-compositor at blender.orghttp://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
>
>
--
Francesco Paglia
Vfx and Production Supervisor
mobile +39 347.82.12.473
e-mail f.paglia.80 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-compositor/attachments/20131202/719458b7/attachment-0001.htm
More information about the Bf-compositor
mailing list