Feature Suggestions & Beta talk

Being on other closed betas I know by the time a public beta is released, the feature set is essentially locked and it's just squashing bugs and working through issues.

Should there be a separate thread for feature requests/suggestions for future versions? Should there be a single thread, or better yet, a sub forum for the beta? Does it even matter if the developers aren't frequenting this forum or interacting with the user base directly?


Some of my initial suggestions, coming from a Nuke/AE background, are mainly UI/UX driven:

- Exposure/Gamma slider in the viewer

- Viewer as a node. Useful for flipping through multiple nodes you want to toggle in the viewer. Flicking the node you want into the viewer you want to display, especially when you want to check different nodes isn't efficient.

- node connections. It feels confusing to know what is plugged into the background and foreground of nodes, especially when you start to move the nodes around. Also, I've deleted node connections by accident when barely clicking on them. I guess it's a feature to remove them in that manner. Spacebar is another ouch for nodes.

- sizing/transforms hidden in merge nodes. I know it's an added bonus to have that ability to do that, but isn't that what the transform nodes are for? It's potentially harder to read the flow of someone elses comp (or old comps) if hidden transforms are being used and you have to track them down.

- TAB key to search/add nodes. Seriously efficient.

- roto/paint nodes with multiple strokes/rotos in layered format.

- UI. Flatten.

- Cameratracker. Oh did I slip that in there?

I know part of that is learning how the software works but it just doesn't feel as intuitive as it should and as soon as the OSX version is released, I can feel the flood gates opening to potential "ex"-Nuke users who are too fed up with Foundry's overpricing. I'm just wondering if there's a method for touching the developers (in a non suggestive manner, of course), and if this forum is where it can happen.

- Exposure/Gamma slider in the viewer

Or more generally, editable UI with widgets for the viewer.

- Viewer as a node. Useful for flipping through multiple nodes you want to toggle in the viewer. Flicking the node you want into the viewer you want to display, especially when you want to check different nodes isn't efficient.

You need to explain this. What's the benefit of NOT being able to view each tool? Because it appears what you are asking for is a reduction in functionality, not an increase.

- node connections. It feels confusing to know what is plugged into the background and foreground of nodes, especially when you start to move the nodes around. Also, I've deleted node connections by accident when barely clicking on them. I guess it's a feature to remove them in that manner. Spacebar is another ouch for nodes.

Again, you need to explain this. There are tooltips for all the connections, and you can connect them by name.

- sizing/transforms hidden in merge nodes. I know it's an added bonus to have that ability to do that, but isn't that what the transform nodes are for? It's potentially harder to read the flow of someone elses comp (or old comps) if hidden transforms are being used and you have to track them down.

It's a usability thing. If you want to place extra transforms, you can. But you don't have to. Readability is a tough one though... What if I didn't like to use BC's, but instead used CC's for everything. What if I used CT's instead? What if I used UserControls? What if I used my own macros? What if I used my own Fuses? There's no way to guarantee that a valid comp will be readable to every other users' standards without a significant reduction in functionality, which would nix forward compatibility which is obviously a non-starter.

- TAB key to search/add nodes. Seriously efficient.

User defined hot keys are already there.

- roto/paint nodes with multiple strokes/rotos in layered format.

There's 2 levels here. The Paint tools ARE the layers, and the strokes themselves are layered unless you use multistrokes, which are an option designed to NOT have layers. The regular strokes are layered though.

- UI. Flatten.

Gonna have to give more detail there. If you're talking about the skinning of the UI controls, that's something that Eyeon had that BMD removed (sort of). I think we should ask for it to be officially returned, yes.

- Viewer as a node. Useful for flipping through multiple nodes you want to toggle in the viewer. Flicking the node you want into the viewer you want to display, especially when you want to check different nodes isn't efficient.

You mean like pressing "1" for the left and "2" for the right view?...

- node connections. It feels confusing to know what is plugged into the background and foreground of nodes, especially when you start to move the nodes around. Also, I've deleted node connections by accident when barely clicking on them. I guess it's a feature to remove them in that manner. Spacebar is another ouch for nodes.

Double-clicking on the pipes ordragging them away from the input will disconnect them.
Dragging with your RMB and letting go on the node will give you a popup-menu with the input names.

- TAB key to search/add nodes. Seriously efficient.

CTRL-F on the flow to search nodes.
CTRL-Spacebar to bring up the AddTool Dialog.

- Cameratracker. Oh did I slip that in there?

That indeed would be awesome....

You mean like pressing "1" for the left and "2" for the right view?...


Double-clicking on the pipes ordragging them away from the input will disconnect them.
Dragging with your RMB and letting go on the node will give you a popup-menu with the input names.

CTRL-F on the flow to search nodes.
CTRL-Spacebar to bring up the AddTool Dialog.

1 and 2 are fine for left and right views, but what about 3, 4 or 5 shown either in a single view or split (left and right)? eg. flipping between a loader clip up the chain, a CC node and maybe a lens distortion node down the flow? pipe those in as 1, 2, 3. Just a thought.

I'm guessing I'm just not used to how touchy the pipes are. I can deal.

Good to know.. I'll switch hotkeys.. used to the TAB key, even in Maya for nodes.

With regards to the earlier comment about a customizable Viewer, that would be cool. Just like the toolbar where you can add nodes, have the ability to add controls/widgets in the Viewer sort of like Premiere.

1 and 2 are fine for left and right views, but what about 3, 4 or 5 shown either in a single view or split (left and right)? eg. flipping between a loader clip up the chain, a CC node and maybe a lens distortion node down the flow? pipe those in as 1, 2, 3. Just a thought.

3, 4, and 5 will load it on viewers 3, 4, and 5. Do you have screen real estate for that? For A/B splits, you can map a hotkey, like ctrl+1 to load into the B buffer of viewer 1 and shift+1 to load into the A buffer of viewer 1. Your other option is to use a switch / wireless link tool to be a viewer tool.

1 and 2 are fine for left and right views, but what about 3, 4 or 5 shown either in a single view or split (left and right)? eg. flipping between a loader clip up the chain, a CC node and maybe a lens distortion node down the flow? pipe those in as 1, 2, 3. Just a thought.

3, 4, and 5 will load it on viewers 3, 4, and 5. Do you have screen real estate for that? For A/B splits, you can map a hotkey, like ctrl+1 to load into the B buffer of viewer 1 and shift+1 to load into the A buffer of viewer 1. Your other option is to use a switch / wireless link tool to be a viewer tool.

wouldn't need any more real estate than a single viewer window which is switchable between different nodes you want to view in that viewer. I'm not talking about having a viewer for each (1,2,3,4,5 etc) keys. It could be an option to make a single viewer window swappable. It's pretty fast to view the same Viewer window while tapping between 1, 2, 1, 2, 1, 3, 1, 3, etc.

1 and 2 are fine for left and right views, but what about 3, 4 or 5 shown either in a single view or split (left and right)? eg. flipping between a loader clip up the chain, a CC node and maybe a lens distortion node down the flow? pipe those in as 1, 2, 3. Just a thought.

3, 4, and 5 will load it on viewers 3, 4, and 5. Do you have screen real estate for that? For A/B splits, you can map a hotkey, like ctrl+1 to load into the B buffer of viewer 1 and shift+1 to load into the A buffer of viewer 1. Your other option is to use a switch / wireless link tool to be a viewer tool.

wouldn't need any more real estate than a single viewer window which is switchable between different nodes you want to view in that viewer. I'm not talking about having a viewer for each (1,2,3,4,5 etc) keys. It could be an option to make a single viewer window swappable. It's pretty fast to view the same Viewer window while tapping between 1, 2, 1, 2, 1, 3, 1, 3, etc.

Then I would suggest just having a node for the viewing then. Something like wireless link or switcher or dissolve or custom tool would do what you wanted. Then you could just run through the inputs with a slider or hotkey.

- sizing/transforms hidden in merge nodes. I know it's an added bonus to have that ability to do that, but isn't that what the transform nodes are for? It's potentially harder to read the flow of someone elses comp (or old comps) if hidden transforms are being used and you have to track them down.

Transform controls in the Merge node do make sense when you combine images of different size.

One of the great features of Fusion is that the coordinates are defined not in pixels, but relatively to the image width and height of the main input.

So, if you want to define the position of a smaller image over a larger image, it's very convenient to use the transforms in the Merge, because in that case the transformation is happening in the coordinate space of the background.

the another one which is kind-of basic and ..... me off is image types and connections. Can we have RGBA images connected to all the nodes as a mask?
sometimes (i.e Fast Noise) RGBA must be "converted to mask" via Bitmap Mask Node, in order to use.

Also, can we have filters, effects, blurs etc working on all/selectable channels - right now You have to manually copy selected channels (i.e. vectors / normals / z-depth / whatnot) to rgb, apply an effect, and copy back..

the another one which is kind-of basic and ..... me off is image types and connections. Can we have RGBA images connected to all the nodes as a mask?
sometimes (i.e Fast Noise) RGBA must be "converted to mask" via Bitmap Mask Node, in order to use.

Like this?

Code: Select all

{
   Tools = ordered() {
      FastNoise1 = FastNoise {
         CtrlWZoom = false,
         Inputs = {
            Gradient = Input {
            },
         },
         UserControls = ordered() {
            NoiseBrightnessMap = {
               LINKID_DataType = "Image",
               LINKS_Name = "Noise Brightness Map",
               LINK_Main = 2,
            },
            NoiseDetailMap = {
               LINKID_DataType = "Image",
               LINKS_Name = "Noise Detail Map",
               LINK_Main = 3,
            },
         },
      },
   },
}

Also, can we have filters, effects, blurs etc working on all/selectable channels - right now You have to manually copy selected channels (i.e. vectors / normals / z-depth / whatnot) to rgb, apply an effect, and copy back..

That's going to break a lot of comps, and make things a lot slower. Also, it won't make sense most of the time. What is a blurred normals channel? Should it be renormalized too? Would a soft glow be applied to the UV channels? Does sharpening a vector channel reverse some vectors? How do you adjust gamma on z-depth?

- sizing/transforms hidden in merge nodes. I know it's an added bonus to have that ability to do that, but isn't that what the transform nodes are for? It's potentially harder to read the flow of someone elses comp (or old comps) if hidden transforms are being used and you have to track them down.

Transform controls in the Merge node do make sense when you combine images of different size.

One of the great features of Fusion is that the coordinates are defined not in pixels, but relatively to the image width and height of the main input.

So, if you want to define the position of a smaller image over a larger image, it's very convenient to use the transforms in the Merge, because in that case the transformation is happening in the coordinate space of the background.

But the transform tools before the merge do the same thing. If the merge tool had the transform inputs hidden, like this...

Code: Select all

{
   Tools = ordered() {
      Merge1 = Merge {
         Inputs = {
         },
         UserControls = ordered() {
            Center = { INPID_PreviewControl = "", IC_ControlPage = 0, INPID_InputControl = "", },
            Size = { INPID_PreviewControl = "", IC_ControlPage = 0, INPID_InputControl = "", },
            Angle = { INPID_PreviewControl = "", IC_ControlPage = 0, INPID_InputControl = "", },
            ReferenceSize = { INPID_PreviewControl = "", IC_ControlPage = 0, INPID_InputControl = "", },
            UseFrameFormatSettings = { INPID_PreviewControl = "", IC_ControlPage = 0, INPID_InputControl = "", },
            InvertTransform = { INPID_PreviewControl = "", IC_ControlPage = 0, INPID_InputControl = "", },
            FlattenTransform = { INPID_PreviewControl = "", IC_ControlPage = 0, INPID_InputControl = "", },
            Width = { INPID_PreviewControl = "", IC_ControlPage = 0, INPID_InputControl = "", },
            Height = { INPID_PreviewControl = "", IC_ControlPage = 0, INPID_InputControl = "", },
         },
      },
   },
}

... you could still place images that have different resolutions and pixel sizes.

The real issue with the wish is that it would break things.

@Chad

1.) mask issues
Yes Chad, exactly like that FN example, custom made by You like what - 3-5 years ago? it only shows how ancient the concept is;)

maybe that would help with auto-connections as well.

now, manually going thru all the required tools, saving as default, copying/pasting to another workstations...
and repeat in annual loop


2) other channels
indeed filtering "all" channels would break the compatibility, but only if it was the default setting. what i would love is a possibility, could be another Tab (external channels) where You could tick and view the result.
Usage? this is indeed not physically nor mathematically correct but would sometimes be of use with painting, masking, merging, data reformating...
yes - the most important is the SOMETIMES- exactly how often we would use that?

personally i prefer Zdefocus tool and Spline warp and some more features prior to those requests, however with Fusion being re-written perhaps it is just the time to implement those things?

Sure, the fact that this workaround works shows that it should probably be standard.

Because of the fixed channel layout in Fusion images, a section in "common controls" could do that, I suppose. A ton of checkboxes or something? And yeah, the default ones would vary by tool. So Grd would have all of them checked, but BC would only have R, G, B and A checked?

Transform controls in the Merge node do make sense when you combine images of different size.

One of the great features of Fusion is that the coordinates are defined not in pixels, but relatively to the image width and height of the main input.

So, if you want to define the position of a smaller image over a larger image, it's very convenient to use the transforms in the Merge, because in that case the transformation is happening in the coordinate space of the background.

But the transform tools before the merge do the same thing. If the merge tool had the transform inputs hidden, like this...

OK, let me explain this on an example.

Imagine that you merge two images of different sizes.

The background image is 1000 pixels wide and foreground image is 600 pixels wide.

If you add a Transform node to the Foreground image before the Merge and set its Center = 0.6; 0.5, the foreground image will shift by 60 pixels to the right from the center.

If instead of adding a Transform, you set the Merge's Center = 0.6; 0.5, the foreground image will shift by 100 pixels to the right from the center.

The later is often preferable when you need precize positioning of a smaller element over a larger background.

Code: Select all

{
   Tools = ordered() {
      PipeRouter1 = PipeRouter {
         Inputs = {
            Input = Input {
               SourceOp = "Background1",
               Source = "Output",
            },
         },
         ViewInfo = PipeRouterInfo { Pos = { 2252.21, 1435.03, }, },
      },
      Transform1 = Transform {
         CtrlWZoom = false,
         Inputs = {
            Center = Input { Value = { 0.6, 0.5, }, },
            Input = Input {
               SourceOp = "Background1",
               Source = "Output",
            },
         },
         ViewInfo = OperatorInfo { Pos = { 2145.68, 1443.16, }, },
      },
      Background1 = Background {
         Inputs = {
            GlobalIn = Input { Value = 1, },
            GlobalOut = Input { Value = 130, },
            Width = Input { Value = 600, },
            Height = Input { Value = 600, },
            ["Gamut.SLogVersion"] = Input { Value = FuID { "SLog2", }, },
            TopLeftRed = Input { Value = 0.5, },
            Gradient = Input {
               Value = Gradient {
                  Colors = {
                     [0] = { 0, 0, 0, 1, },
                     [1] = { 1, 1, 1, 1, },
                  },
               },
            },
         },
         ViewInfo = OperatorInfo { Pos = { 2145.68, 1336.9, }, },
      },
      Merge1 = Merge {
         Inputs = {
            Background = Input {
               SourceOp = "Background2",
               Source = "Output",
            },
            Foreground = Input {
               SourceOp = "Transform1",
               Source = "Output",
            },
            PerformDepthMerge = Input { Value = 0, },
            Comments = Input { Value = "Positioning of the foreground image is applied in a Transform\r\nit works in the coordinate space of the background image", },
         },
         ViewInfo = OperatorInfo { Pos = { 2145.68, 1489.81, }, },
      },
      Merge2 = Merge {
         Inputs = {
            Background = Input {
               SourceOp = "PipeRouter2",
               Source = "Output",
            },
            Foreground = Input {
               SourceOp = "PipeRouter1",
               Source = "Output",
            },
            Center = Input { Value = { 0.6, 0.5, }, },
            PerformDepthMerge = Input { Value = 0, },
            Comments = Input { Value = "Positioning of the foreground image is applied in the Merge\r\nit works in the coordinate space of the foreground image", },
         },
         ViewInfo = OperatorInfo { Pos = { 2252.21, 1540.8, }, },
      },
      PipeRouter2 = PipeRouter {
         Inputs = {
            Input = Input {
               SourceOp = "Background2",
               Source = "Output",
            },
         },
         ViewInfo = PipeRouterInfo { Pos = { 2132.03, 1540.8, }, },
      },
      Background2 = Background {
         Inputs = {
            GlobalIn = Input { Value = 1, },
            GlobalOut = Input { Value = 130, },
            Width = Input { Value = 1000, },
            Height = Input { Value = 1000, },
            ["Gamut.SLogVersion"] = Input { Value = FuID { "SLog2", }, },
            Gradient = Input {
               Value = Gradient {
                  Colors = {
                     [0] = { 0, 0, 0, 1, },
                     [1] = { 1, 1, 1, 1, },
                  },
               },
            },
         },
         ViewInfo = OperatorInfo { Pos = { 2005.98, 1489.81, }, },
      },
   },
}

Another aspect of the transform controls exposed in the Merge is that it's a free addition to the fact that the Merge tool in Fusion concatenates transforms. What's so special about it? In Nuke, the Merge doesn't support concatenated transforms!

Crazy huh? The transforms in Nuke are flattened whenever you merge something inbetween for both background and foreground.

Two reciprocal transforms don't reduce the quality because of concatenation
Scroll down to see the node arrangement

NukeConcatenation.jpg (69.73 KiB) Viewed 5861 times

A Merge node breaks the concatenation
Scroll down to see the node arrangement

NukeConcatenationBroken.jpg (82.89 KiB) Viewed 5861 times

This means that if you stabilize the background plate first to merge some elements on top and then destabilize it back, you'll get filtering.

Or if your setup in Nuke contains multiple elements, you can't arrange transformation of separate elements independently first, then merge them together and transform as a whole, without quality loss. Instead, you need to build flat structure where each element has its own Transforms to preserve the quality.

If you add a Transform node to the Foreground image before the Merge and set its Center = 0.6; 0.5, the foreground image will shift by 60 pixels to the right from the center.

If instead of adding a Transform, you set the Merge's Center = 0.6; 0.5, the foreground image will shift by 100 pixels to the right from the center.

Excellent examples, and I'm not arguing with you at all, I think it's a dumb request, yada, yada, yada...

But for users just learning Fusion, inside the Xf and Mrg tools there is a "Reference size" at the bottom which lets you convert [0, width] coordinates to [0, whatever] coordinates by setting an new scaling. So if you set it to 600, then you will see 0.6 change to 360. If you change it to 1000, you will see 0.6 change to 600. This gives you a way to place elements with pixel-count precision even when you need that transform in a different image width scale.

"I think it's a dumb request, yada, yada, yada..."


umm thanks I guess. Great community!

More thanks to Gregory for the more thoughtful explanation. I do know in nuke they recommend an order to certain nodes due to concatenation but had forgotten about it.

umm thanks I guess. Great community!

Well your request was to remove a feature that does no harm, is beneficial, and would break forward compatibility. I'm not implying that you personally are dumb, just that the request was.

yeah.

Nuke's convolve node would be a welcome addition to Fusion. (fast defocus using any iris shape)

It used to be available in Awake for Fusion 5 from Frantic Films, but Thinkbox seem to have discontinued the set.
Deconvolve was also a pretty cool thing.

But the MapFilter from Krokodove should also do the trick.

By the way, I really wish there was a possibility to define an arbitrary bokeh shape in VariBlur. This is kind of critical for me. I suspect, it's not so easy to implement in VariBlur itself as it is, but maybe, there could be an additional extra tool which would apply a filter with user-defined shape and radius dependent on an auxiliary channel.

Frantic Films also had a MotionDepthBlur tool, which obviously allowed to apply both depth and motion blur together in one node. That was really cool, and unique. I wish it could be resurrected.