[Bf-compositor] [enh] How to deal with thumbnail previews
Aditia A. Pratama
aditia.ap at gmail.com
Mon Dec 2 23:56:36 CET 2013
try to compiled it in linux 64 bit and seems have an issue
http://developer.blender.org/D69#comment-1
On Tue, Dec 3, 2013 at 5:13 AM, Francesco Paglia <f.paglia.80 at gmail.com>wrote:
> 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
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
--
<http://kampoongmonster.com>
Aditia A. Pratama / Chief Technical Officer
+62 813 4747 8111/ aditia at kampoongmonster.com
Kampoong Monster Studios
Jl. Geger Kalong Hilir No. 47 Menara RDC Telkom Lt.4 Bandung Digital Valley
40153
http://kampoongmonster.com
<http://twitter.com/aditia_ap> <http://www.linkedin.com/in/aditiapratama>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-compositor/attachments/20131203/ad008f33/attachment-0001.htm
More information about the Bf-compositor
mailing list