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