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)
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 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 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 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 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/d16ab42e/attachment-0001.htm