The “Frame” node has been in trunk for a few months now, but it is still in a somewhat unfinished state. So i’ve made a few additions that will make this node a lot more useful for organizing node layout. Thanks to Sebastian König for feedback and testing!
The general idea is that the Frame node can complement the already present Group nodes. Node groups are in fact separate data blocks, linked into a node tree by the node group (so the term “group” is a bit misleading: the internal nodes are completely separate from the surrounding nodes). The frame nodes on the other hand are really just a way of grouping nodes inside the same tree, without the need for additional interfaces.
Oh, and btw: We should change the name of this thing! “Frame” usually has a different meaning in Blender, but i still don’t have a convincing alternative … Time to get creative! :)
NOTE: I will upload the patch to the codereview tool soon, for now here is a simple pasteall.org link if you want to try it out:
http://www.pasteall.org/31531/diff
NOTE 2: The patch is now submitted to the code review tool:
http://codereview.appspot.com/6200062/
Potential changes before trunk merge will be uploaded there as well.
NOTE 3: COMMITTED TO TRUNK!
Frame Node Bounding Boxes
Frame nodes now behave as Bounding Boxes around the attached nodes. When moving a child node of a frame, the size will update automatically to make sure it is big enough for all children.
Shrinking bounding box
Frame nodes have an optional Shrink setting (accessible in the sidebar), which ensures that the bounding box is of minimal size. If disabled the frame will not change size when children are moved closer together.
Shrinking disabled
Improved Node Resizing
Resizing nodes now has immediate visual feedback in the form of changing mouse cursors. When hovering the mouse over the border of a node, the cursor changes to indicate the possible directions in which a node border can be dragged.
Previously node borders could only be grabbed at the lower right corner. This was in fact restricted to resizing the node width, so having the resize widget in the corner is misleading (indicating a possible resize of height too). Any change of height is in fact purely automatic (for regular nodes), caused by resizing the preview with constant aspect ratio. Node borders can now be grabbed at both the left and right size instead for horizontal resizing.
New resize behavior
Manual resizing of frame nodes only works if the Shrink option is disabled. Otherwise the frame size is determined fully automatic by the placement of child nodes. Unlike regular nodes, frame nodes can then also be resized in the vertical direction from both top and bottom border.
Manually resizing a frame
New Operators for Managing Frame Nodes
The frame node basically implements a parent/child relationship similar to that found in objects: The frame acts as the parent node for all attached children (including other frames). When moving the parent, the children move with it (transform hierarchy).
For changing this hierarchy a number operators and tools have been implemented:
Similar to object parenting, nodes can be attached and released from frames with directly operators:
- CTRL+p attaches a node to the active frame. The last selected (=active) node has to be a frame node.
- ALT+p releases a node from it’s current parent.
Attach to frame by dragging onto it
In addition, nodes can also be attached and released more conveniently using mouse dragging:
- Moving any number of nodes onto a frame (i.e. mouse cursor is over the frame when confirming) attaches them to the frame.
- ALT+f releases a node from it’s parent (like ALT+p) and immediately starts the modal transform operator
Note: We tried implementing a grabbing variant for this (grab+modifier key), but there is just no unused working combination left in the keymap …
Similar to Node Groups there are also ways to create new frames around a selection of nodes:
- ALT+j creates a new frame around the selected nodes (like ALT+g for creating a group)
- “ungrouping” can be done by simply deleting a frame node. All immediate child nodes are then released.
Theme Colors for Node Selection
Previously the active node and selected nodes were indicated using the “Text Highlight” theme color for both. Now this has been replaced by dedicated theme colors for the active node and for selection respectively, to allow better visual distinction of the selection state.
Funky theme colors (just for show)
Custom Node Colors
Nodes can now have an optional custom color displayed on their “body” part (that is, the node background except the header bar and the outline). This is meant to be used primarily in combination with frame nodes, as a way to visually separate different sections of a node tree.
The colors have a preset system, like the one already in place for tracks in the clip editor. Colors can be stored as presets and can be applied to all selected nodes using the Copy Color button next to the preset menu.
Custom color for frames, Screenshot by Sebastian König
I tried to “Add Frame” and wanted to change color. I can change color in properties, but inserted frame is transparent since was added. I can see just black/orange stroke of frame
(tested on 2.64RC1 r50696 OS X 64)
I am wondering why color coding the body of a node was chosen? When looking at many collapsed nodes, as an overview, it is hard to discover each nodes type.
Surely coloring the header would be more usefull? Here is an example at a user thread at BA forums
http://blenderartists.org/forum/showthread.php?265870-Compositor-like-Nuke&p=2202282&viewfull=1#post2202282
coloring header +1
I suppose it was reworked to permit for construction history which is sorely needed..
BTW, Do you know who thought up the idea to use a memory stack for Undo in blender in previous versions..
ME
Ask Ton..
I was anal..
Another Idea… The Frame shrinkwrap around the nodes is nto comfortable for those who like to have some space around things.. It’s a preference concern.. Some artists like stuff tidy some like to feel they have more space to work in, you might find artists setting up a couple of dummy nodes just to keep the frame bigger.. It should either be something that can be toggled or a button pressed causes everything to shrink to the set of nodes..
MAJOR MAJOR MAJOR MAJOR MAJOR MAJOR MAJOR MAJOR
TIME SAVER TIME SAVER TIME SAVER TIME SAVER
IDEA IDEA IDEA IDEA IDEA IDEA IDEA IDEA
BELOW BELOW BELOW BELOW BELOW BELOW BELOW
Ghost nodes not in use, so that you don’t mess with nodes that are not affecting the render.. I spent 20 minutes one day tweaking a node to realize that it was not connected to the output..
Node editor specific:
Need a “View All” feature for groups and the general editor..
Say you are in a group node, everything is compressed, it’s not intuitive to change the size of the frame, it would be better to hit a key and the frame expands to the size of the view, and if necessary zoom out so the nodes within are easy to look at.. Then permit the user to focus on the individual nodes…
“”Double click on menu bar of node causes it to scale full view.. “” ???
Node group collections, Shader libraries?? Say a list node with each item in list being a shader group..
Shader community? A Node from where exists a collection of pre-made nodes from other users, placed there by others.. Reach in, pick out the shader, try it out.. I figure since the shader nodes are so self comntained, it would be easy to maintain a online database of custom designed shaders and offer that to others..
For the sake of simplicity, it would be better to adopt naming conventions that have already been used and drawing some relationship to that.. It can be confusing if you are talking about two different parts of blender, but if it becomes confusing users can always just chart it out what they are talking about, it’s better to encourage the “intuiveness” and the ability to discover without access to a manual.. The Mistake that developers of Alias Power Animator made was to develop the system from the tutorial department, then you end up with hundreds of object tools that all do the same things but with different names and no unification of thought.. That got fixed with Maya? Same difference,
you don’t want users to be looking for a feature from a GUI poster like old Poweranimator users had to..
Another things who is screwing up the graph editor, it seems like you can’t use it like you could.. Take for instance using it to control curves for the VSE.. Blender’s linking system is unique to it and the thing that makes it better than anything (selective instancing).. You remove that, it’s no longer blender..
I mean when the group node is open, you can’t tweak inputs until the node is closed..
I like the node editor.. But when changing values on the inputs to a group node the internal shader is not tested and output doesn’t until the node is closed..
It would be nice to have drag an drop ability.. I’ve run into other bugs but what escapes me now..
I think it would be nice to be able to test the result of the output of ports in the node editor directly and to analyze exactly what is coming out, like a debugging console.. It would make the writing of things like shaders much easier.. Otherwise I’m left guessing..
nameing…
how about gates?
Hi Lukas,
Just curious why you don’t include alpha with the custom color?
The default frame color has alpha 0 (with the Blender24X theme, at least), so by default the custom colors don’t show up. Would be nice to have this independent of the theme.
Cheers,
Chris
An related feature idea:
I think it would be good to have an option for commenting group and this new frame nodes, ie. writing comments (aimed for yourself or other users of your .blends) on what the particular group / frame internals are supposed to do.
Node trees can be arbitrarily complex and confusing, especially when you come back to a project after X months, and then have to stare a few minutes at the node trees to figure out what were you trying to do there.
Having an text area inside group & frame containers where to write comments (or even special text or “tooltip” node that you could put anywhere you want) would be nice & useful.
I think it would be useful and cleaner if we did away with Viewer and Comp nodes.
Just have a box available to check on each node to send the result at that point to either
Viewer and/or Comp output. A visual indicator like a frame color or flag will indicate
where the output is coming from.
the file output node can’t change the output settings, it was very useful for saving videos and image sequences at the same time for example.
also when you change the output settings, the nodes doesn’t take in account those changues so you have to replace all the nodes for every time.
I few month ago I used an add on to enable to ability to set nodal points to redirect the noodles in the compositor. Does anyone know about this add on and where to find it? I think this would be a welcome addition to trunk
Label Resizing is cool.
But is it possible to give label color a different color than default node background color in theme settings ?
Maybe it could be called “bin”.
In editing software (Avid, Final Cut) you call folders where you collect footage “bins”, so why not name a node collecting nodes bin?
I also like “box”, though, or simpy “collect node”.
Very cool and useful! ;)
Suggestion:
– Fences (like for sheep and is the name of an addin that does that with desktop icons)
Nice work! :)
How about Flex?
Frame is surely OK for the name, but NOT OK for i18n work, due to the diference between the functions. I’m afraid so. Probably would better be something like “Dock”? Whatever, just FYI.
frame is ok for the name, Maybe Backdrop like Nuke calls it
I kind of like the name “Box”: it’s simple, abstract, yet intuitive and not a general term for other Blender features (the default mesh thingy is called “Cube”).
If everybody is fine with “Frame” though i wouldn’t mind keeping it that way either :)
I have just been discussing this with Francesco Siddi, and we both agree that “frame” is actually not a bad name. It is a totally different context than the timeline and it actually does frame the other nodes. Apart from that you do not really interact with the animation frames, like, you do not move them or do stuff, you can only go back and forth. So having a “frame node” in the node editor is not all that bad. And it is better than “tray, container, etc.”
I think we can just keep it.
@Sebastian, I agree with you, actually “frame” is quite a nice description for such function, indeed.
However, I would highly suggest that it really needs to be treated separately for UI translation purpose. Obviously, it is one of the polysemous words. Actually, after my completion work on zh_CN.po translation, I’ve collected 50+ polysemous words, some of them really are in very high priority to be solved, not only for the Chinese UI translation, I’ve heard so many blenderers calling for the improvement on such issues.
I have been updating thins like this here http://goo.gl/VzppJ , with priority rates, and really expect someone could well break them down as much as possible.
Let’s call it sexy.
How about Semantic nodes? You use them to add semantics to a group of nodes.
The second thing — this might be tricky to pull off, but I think it could be rewarding.
If you move the node slowly, it will resize the Frame node
If tou “rip” it fast, then you get it out (and for a short while, if you go back towards the frame, it will “undo” the action.
If it “feels” right, then it could be a nice alternative, but as I said it might get tricky.
I think they should be called MAGIC.
Serious, what about “Bundles”?
Why? Because in use, you would say
A] a frame of nodes, or
B] a bundle of nodes. <–grammatically more accurate.
Also consider the definition of bundle: "a group of things fastened together for convenient handling" which is what we are going for.
I am getting a bit picky, just thinking out loud. The "frame" is the object doing the containing, but when you put stuff in it, it is now more than JUST the frame. If you put multiple pictures in a frame, you now call it a collage right?
My $.02. Take lightly. :D
PS Cheers for all the work on the nodes you are doing!!!
+1 for renaming frames as “trays,” imho that seems like a very intuitive name both for the functionality and visual appearance of the “frames.”
FYI its called backdrop in Nuke
A few other terms I’ve seen:
– Container
– Cabinet
– Collection
– Set
– Wrapper
– Box
I don’t think groups should be renamed. That would break terminology consistency with geometry groups.
How about “tray”?
A naming suggestion:
It sounds like these should be called “groups” and the current groups should be renamed to something like “abstraction” (to borrow from pureData), “processor”, or “blackbox”
The idea being that frames (as they’re currently called) are useful as a visual organization tool and the current groups are useful as a logical organization tool. You will probably want to edit things inside a frame frequently, but a group is something that’s built once and used/reused like a standard built-in node.
I can’t say how much confusion would result from a renaming like that, though.
In order to prevent spam, comments are closed 7 days after the post is published. Feel free to continue the conversation on the forums.