Blackmagic Forum

Hello BMD,
today is the day I have to publicly say that your Node Graph panel is garbage.

Please have a look at the user experience in Nuke and do something in that direction to make our life better.

Problems :

1) lines are randomly hard to select precisely
2) when one connection is broken/disconnected in the node tree = color preview is lost
3) when a node is laying somewhere, unconnected to the node tree in any way = color preview is lost
4) we cannot disconnected and drag an input to another one (we have to select a line, delete, then drag from the input to the new input) = time and movement waste, and we cannot see the change occur without losing preview (cf problem 2&3)
5) as the input and output of the node tree are somehow "fixed", opening the OpenFX panel or changing the zoom will dynamically rearrange and mess the node tree, pushing nodes out of view and further than the input/output point = you have to zoom back or scroll or move nodes around back to something usable/viewable
6) "Cleanup node graph" is useless and does more harm than good in many cases

I think calling it "garbage" is a little strong, but these suggestions are all good ones and I'd like to see them implemented, too.

Items 2, 3, 4 and 6 are things I'm frustrated with as well.

The node editing capabilities of Fusion are much better, and while I know that Fusion and Resolve were developed completely separately from each other, I'd like to see nodes in Resolve behave more like nodes in Fusion, especially in regards to being able to disconnect them without losing preview, and being able to drag a new pipe to replace an old one, instead of the delete then re-create workflow we have now.

I admit the word is a bit strong
It's just that I'm losing so much time everyday fighting with it, it's really getting on my nerve...

Antoine Grasset wrote:I admit the word is a bit strong It's just that I'm losing so much time everyday fighting with it, it's really getting on my nerve...

Get used to it, understand the logic of how and why the node tree is structured the way it is, and stop comparing it to other programs. There are positive sides of Resolve's approach.

There are always workarounds. For example, you can use an expanded node window, push everything further to the left, and you'll have more node space to work with. For another idea: you could use a pre-configured node structure with everything labeled, and just bypass the nodes you aren't using at the moment. There are advantages of using a strict node structure for some projects.

I somewhat agree that the node can be improved, I like nuke.

but I'm also fan of a predeterminate node structure, 12-20 nodes based on the project

Antoine, Are you on 12.5.4?
What resolution UI screen?

#4 "we cannot disconnected and drag an input to another one"

select the node output and click to drag a connect to another node input which if it had an input connection it would replace the existing with the new.

For Node re-arrangement you can also click in the background and lasso nodes to move many at once.

Peter Chamberlain wrote:Antoine, Are you on 12.5.4?
What resolution UI screen?

I'm using 12.5.3, dual monitor setup (Gallery+Scope on a 1080*1920 and Tools+Nodes+Preview on a 2560*1440). Will try 12.5.4 in the coming weeks.

Peter Chamberlain wrote:#4 "we cannot disconnected and drag an input to another one"
select the node output and click to drag a connect to another node input which if it had an input connection it would replace the existing with the new.

Thanks for the tip but this create a new output (you still have to delete the previous connection) : I'd prefer to "swap" directly = moving the already existing connection.

Peter Chamberlain wrote:For Node re-arrangement you can also click in the background and lasso nodes to move many at once.

Yes, this new feature was a blessing

Peter Chamberlain wrote:#4 "we cannot disconnected and drag an input to another one"
select the node output and click to drag a connect to another node input which if it had an input connection it would replace the existing with the new.

Thanks for the tip but this create a new output (you still have to delete the previous connection) : I'd prefer to "swap" directly = moving the already existing connection.

Sorry this is still not clear to me.
What new output are you creating?

If you select an existing node output, click and drag the connector it will make a second output link to the node input you drop it on and the previous node input is automatically removed.

Does anyone know if a disconnected node still causes color preview to be lost in the latest version (17) of Resolve? (I'm not able to verify this myself yet until I install Linux.) If so, this would be a very important issue to address, as a user should be able to determine the output of any selected node individually before determining its final position in the node tree. I also wholeheartedly agree with the 6 points of Antoine's OP (again assuming these issues have not already been fixed in Version 17). Thanks!

Adam Janz wrote:Does anyone know if a disconnected node still causes color preview to be lost in the latest version (17) of Resolve? (I'm not able to verify this myself yet until I install Linux.) If so, this would be a very important issue to address, as a user should be able to determine the output of any selected node individually before determining its final position in the node tree. I also wholeheartedly agree with the 6 points of Antoine's OP (again assuming these issues have not already been fixed in Version 17). Thanks!

when you unplug the power connecter from the socket it is dark ; -)

so switch nodes off and on with cmd+D and don't disconnect,
unless you want to move the node to another place in the tree

Mark Foster wrote: when you unplug the power connecter from the socket it is dark ; -)

Thank you Mark for confirming! I hope they can fix that behavior, it would certainly make prototyping looks a lot simpler.

Nothing to fix. Please review the node operation with the highlight mode.

Peter Chamberlain wrote:Nothing to fix. Please review the node operation with the highlight mode.

Thank you Peter for your reply. The issue is actually with not being able to see your existing node graph results when a new, unplugged node is added to the graph. The highlight mode is handy, yes, but it does NOT work when a new unplugged node exists in the graph. There is actually no logical reason why the node graph results would be deliberately hidden from the user when an unplugged or partially plugged node is added. The node graph should ONLY evaluate the results of all FULLY CONNECTED nodes, not random nodes that are bypassed or sitting unconnected by themselves.

This current limitation proved to be a hindrance more than once today while constructing a 36 node graph. Several times I had to pause after adding a new node and try to remember what my current final result looked like before proceeding to connect the new node and add power windows, etc. It is a major shortcoming especially when working with complex graphs. Having the functionality of the node graph only evaluating fully connected nodes would be a tremendous timesaver and greatly appreciated!

R u on 17.2?

Peter Chamberlain wrote:R u on 17.2?

Hi Peter, unfortunately I'm not yet (BMD ended support for Windows 8.1 so I have yet to install Linux in order to use the latest version of Resolve on my workstation). That's why I had asked if anyone could confirm if the described behavior still exists in the latest version. If it doesn't, that would be amazing news! Thanks again for your time.

Simply adding an unconnected node doesn't change the image in the Viewer. I wouldn't expect it to. (You're saying it used to?)

Studio 17.2.1 for Windows.

Jim Simon wrote:Simply adding an unconnected node doesn't change the image in the Viewer. I wouldn't expect it to. (You're saying it used to?)

Studio 17.2.1 for Windows.

Ah, maybe the issue has been fixed then. Thanks Jim! Once I update my system to Linux I will test that out. Am currently stuck using Resolve 12.5.6 since it was the last build officially supporting Windows 8.1. However, many of the limitations I encounter in 12.5.6 (including the problem with power window parameter keyframes all sharing the same channel) appear to affect the latest release also (according to user comments online). That said, if this preview issue was corrected, then that is great news indeed!

Adam Janz wrote:Ah, maybe the issue has been fixed then.

Yes, this was fixed at some point after 12. Might have been 15? Not sure offhand.

Frank Engel wrote:Yes, this was fixed at some point after 12. Might have been 15? Not sure offhand.

Thanks so much, Frank! That is really great to hear.