You’re absolutely right. Functionality is the core, and with limited development resources, UI can be gradually improved and optimized.
Quite frankly, this seems like fixing a problem that doesn’t exist. What’s important is the image, I really don’t care what the icons look like as long as i know what they do.
1 Like
Yep never ever going to have everyone agree on color and to waste resources on implementing this would be a giant waste of dev time no disrespect to the idea however there’s bigger fish to fry
2 Likes
The only problem with the big fish is whether they are vector or bitmap fish…
Also, big fish are usually mammals
2 Likes
Jokes aside I give zero #$&$# about this feature request. Would be a waste of resources and the list of other things needed are long and on going
7 Likes
Everyone’s focus is definitely not exactly the same, which is normal. I have used at least hundreds of professional software systems, and functionality and performance are definitely the core. However, at the same time, I also pay more attention to UI. I respect everyone’s point of view, but I am extremely looking forward to vectorizing the Flame nodes and nodes schematic，As for color, it’s not the key.
The nodes are images mainly because of two reasons:
- It makes the display of the schematic faster / more performant.
- Like Sinan mentioned, we think that most people do not zoom in much in a Schematic.
That being said, the drawback of using images is that it makes it harder (close to impossible) to let people colour code nodes.
2 Likes
I’m not sure I understand your comment Greg-Paul. All the colours for used for all the colour coding can be customize to your liking. What are you referring to?
I put in a feature request a few years ago for more scaleable node images (particularly the output image) as I liked to zoom in on key stages of the Batch nodes to act as quasi-viewports so that I could follow (and demonstrate to students) the flow in the flowgraph. They (can) operate as context cues (like context viewports) to see things cascade. I liked that idea as they, “literally” (scare quotes as I am not a fan of that muxh abus word, “”literally) put the picture into the flow, and ao animate one’s view. You can quickly, with the pen, “switch” them on and turn them off, and are then key “live” elements of flowgraph flying by. The quicker mac graphics/ processors get (I find the M4Ultra quick enough) themore valuable, imo, this becomes. Like a developing story in the “flickbook” you get to check in on developing detail in a way that four viewports cannot mimic. That’s my small view on the icon-flowgraph story or plot.
Cheers
Tony
1 Like
Thank you very much, Frederic Warren, for explaining the reason why nodes are images.
In terms of speed and performance, in the past, vector graphics may have significantly hindered performance due to insufficient computer hardware.
However, with the increasing hardware, Nvidia has achieved more than 20000 CUDA and 96GB of video memory for professional graphics cards, and Apple Silicon’s chips are also becoming more powerful. Unified memory has reached 512GB, and the computing power of CPUs, GPUs, RAM, SSDs, and even DPU cards is becoming more and more powerful.
I think it is possible to gradually replace bitmap images with vector graphics algorithms because vector graphics can avoid obvious mosaic and jagged edges. It is not easy to implement them immediately, but can be gradually implemented. Of course, I also know that many relatively old hardware systems should be considered.
The node graph of Foundry Nuke does not have the same magnification factor as the Flame node graph, but when enlarged, Nuke’s node graph does not have too obvious mosaics and jagged edges.
Nuke Nodes
Flame Nodes
In addition, the Footage input node thumbnails for Nuke and Flame are both highly compressed small resolution thumbnails that are noticeably mosaic when slightly enlarged. Therefore, I am considering introducing a high-definition thumbnail mechanism and（or） allowing users to choose between setting high-definition or highly compressed thumbnails。
At present, if the Flame timeline is in frame display mode, each frame is actually relatively blurry and not a high-definition image. I think the reason may also be that it is highly compressed, and I would prefer to see high-definition thumbnail frames.
As for coloring the nodes in the node toolbox, it may be much easier to implement when the nodes are displayed in vector graphics. But currently I don’t have a strong need for this, I can quickly find the nodes I need through search.
By the way, I haven’t seen any news from Stephane Labrie for a while, and I would like to express my concern here.
Stéphane is on a well-deserved vacation. He will be back next week.
That’s great, welcome!