[Bf-compositor] [enh] How to deal with thumbnail previews
Jeroen Bakker
j.bakker at atmind.nl
Tue Nov 19 19:29:02 CET 2013
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
> http://lists.blender.org/mailman/listinfo/bf-compositor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-compositor/attachments/20131119/68b118e4/attachment-0001.htm
More information about the Bf-compositor
mailing list