Was reading crits of one of my filters and the 'organization' of the node tree was mentioned. I agree. I have compiled a short list of small additions/changes that could speed up construction of, and ease the understanding of ones node tree.
FF is a remarkable product, even more so considering it just turned 1. I use a few other node based programs, DFX+ being one. Being Version 4 gives it time to become a little more complete with all the little niceties. I'm not at all complaining, just pointing out some ideas and things I've previously found which worked nicely.
Keep it up guys. This software is fabulous.
If anything below actually is possible? please let me know?
cheers.
---------------
1. User tags. like the mac OS... just color dots to differentiate 'symbolic' or 'conceptual' distinctions.
2. User names. Even if it's on the bottom. 20 blends are really baffling when they are connected all over.
3. Groups. Being able to lock completed node clusters and (even better, like DFX+) collapse the nodes into a 'group node' non-editable but moveable and - here's the thing - SMALL
4. Render tap. A node that can be connected to any BRANCH to quickly test what is being rendered. This works well when you can collapse all nodes to just their names and a small shape. With complex node trees I have found that by clustering things into subroutines, then making them invisible, one can understand and build the program more efficiently. The render tap can be placed between collapsed node groups to monitor the progress of the imagery on it's way to the promised land.
5. A node that makes you less disorganized person.
6. Control, or Cmnd click to drag complete subtrees around.
7. A context menu item downstream of the click which automatically reposition nodes to the grid in hierarchical order. Even better would be the ability to do the entire thing, then custom move areas that don't conform.
8. Cntrl/Cmnd drag connecting input node (with remap on) copies last settings to new connection (max/min). Connecting 10 remapped nodes with custom settings involves a pen, which is never a good sign
11. A universal color coding scheme. Bright colors and easy to see. I find myself hunting for nodes... a lot.
12. I like the quicksort idea on in the node palette, but what about something like folders. I don't use that much because I can never remember what node is in what category. Being able to organize by icon in a grid would be nice, all the icons would be visible at once. I have learned the icons, and would love to not scroll at all. That would speed things up A LOT. Also being able to show only your most used nodes would be nice. (click to select, with a hide/show button) There are nodes I've never used.
13. Input nodes which have a zero point. In the filter the slider goes from -100 to 100, even remapped the end user must contend with 1-200. Which makes quickly comprehending that slider's intended effect is near to impossible.
14. Other input node types would be helpful. Presented as dials or switches. Ability to create rudimentary interface details like dividers and subtitles... that would make a huge difference. Drag and drop ordering would be very nice too.
15. Building nodes with dual displays... desired would be a 'render/palette' screen and a 'node' screen. Spanning dual displays with FF brings the node refresh to it's knees, it was unusable. I am very much used to using two displays. Node trees are much easier to work with when you can see and understand the whole program at once.
16. Connecting multiple nodes. From a source to multiple, select them, then drag to the first, all others are connected the same way.
17. Access to control nodes setting from within the effected filter. (if they are controllers not images)
18. photoshop style drag to set. Click beside numeric input (within node itself while on tree) and drag left and right to quickly move number up and down.
19. (pie in sky) connectable trees. excel type panels where you can pass results from one tree to the next. For complex filters where the entire tree would be very large, I've on many occations wished to pass this result to a newer filter. eg. First filter produces RGB effects, second filter convolution.
20. Replace trunk node without having to reconnect every branch. Time consuming. Maybe CNTRL-drag drop on existing to replace. Helpful when you need to add a node downstream of a branch but including the branch. Grow the limb so to speak.
21. loadable subroutines. Making the same function many times can get a bit tedious. I'm going to try pasting a group from another filter... if it works... well.. just ignore this one.
22. expand selection. In Lightwave I can select a polygon and hit a quick key for it to expand. Selects the next polygon in contact, etc. In FF this would allow me to select a node and expand it to include levels up or down and move, delete or do whatever.
23. Break the seamless barrier! I'm guessing many people like myself (photographer and CG artist) want to create filters specifically geared to static images (static aspect ratio). Rotate, scale and other operations that break seamlessness are required to realize the filter dreams we have. For example I abandoned my attempts to create a true CMYK screen look, like 50's style comics because without rotating the screens... well... that ain't right.
24. input nodes. I would love to be able to import more types of data like additional images or eps curves.
25. programming. Automation. For example, recursive processing, where you want to apply an operation 200 times to a bitmap. Currently one has to stack nodes, one after the other. Being able to add a 'repeat' node where between A and B it repeats all nodes between X number of times before going on. This would allow cumulative and fractal-like operations. This would introduce a rendering bottleneck... however I for one am used to the idea of waiting for renders and would be willing to accept the render pricetag for the power it would unlock. Also, as a user I could set the iterations to very low until I was finished and ready to render.
26. convert to bitmap. many of the limitations are due to seamlessness and the continuity of the alpha channel and other info. Offer the choice to us bitmap junkies. We want the option of powerful non-seamless tools, and a node to define that 'point' in the stream would allow multistage processing, where seamless tools could interact with non-seamless via the 'render' barrier. I actually have a strong need for a seamless texture tool... but ALSO want to be able to create striking photographic images with my own filters. right now FF is bias toward seamless texture generation.
27. Usually 75% of my nodes do NOT require a rendered thumbnail. Double clicking on them could collapse the node to exclude the thumb... thus speeding update and condensing the tree (always a good thing). This feature would come with a checkbox in the prefs, ( ) new nodes contain thumbnail. Personally I'd run with all off... then turn on the ones I determined were important for watching the flow.
28. Universal filter location. I work from three locations depending on external factors. Each of my machines has FF installed (that's ok right?) I like to work on filters from wherever. My space is server oriented. I would love to choose a location and save ALL filters in the same location. so I could back them up easier (with my automated backup) and of course work on the same filter from different locations.
29. I want to pull a color from an image and process the image base on that color. RGB is easy, but results from the HSB or others is less then stellar. I want a tool to sample a color and allow me to build a filter to manipulate 'yellow' from 'blue' am I missing something obvious here? The average color should have an input! so I could use the tool to color balance processed data. the light and dark point should have an input also, for the same reason!
30. folders for user filters. I have so many that short of deleting them some are just in the way.
31. small thing. when i open a large image, I want to use a proxie until render time. I don't know if the node view is subsampled but it would be nice if a FF temp bitmap were used for all operations until output stage. If this is the case, sorry... but the node view seems much slower when a large (3000pix) image is loaded.
32. Adaptive inputs. Situation: switch connected to 5 different curve types. 4 control nodes control pertinent input parameters on each curve, but each curve node has different types of control inputs. Control nodes that could pull parameter name from it's final target (from the user interface) and display them would be helpful for the user. This extends to switch controllers, which should display the target currently connected. (this is where named nodes would help too) Also, changing the image mode (screen, overlay, etc) is IMPOSSIBLE. In the node view one can remap and see this info, but in the user view you get a number; I know now that 10=overlay, but for the average user waiting for a render and guessing if they are getting lighten, or screen, or perhaps overlay?
V2. Please consider a keyframe idea, where a timeline could allow users to output frames with keyframed settings. Some of these filters could produce AMAZING video effects! I just YEARN to use some of my filters on a group of frames. sigh. I may even do so... manually. Even a loader node based on sequentially named frames... load, render and save in folder X all the files in folder Y. Oh... pleeeze?
the artist formerly known as Bongo51
