- Feedback
-
Ideas
0
Completed
Handling larger node trees
I feel that the real bottleneck of SF at this point is the UI: creating and managing even moderate sized node trees is slow and frustrating. (I consider the long loading times as a clean cut bug so I wont address that.)
I have two main issues:
- Zoom is extremely important. In a full screen 1920x1200 you can reasonably place 9 nodes horizontally and 8 vertically (both sidepanels are as small as possible). Of course most networks are not evenly distributed, usually more wide than tall so in practice you are able to see about 20-25 nodes at best, a smaller and smaller percentage as your shader grows. A side effect of this is that if you need to link two nodes more a than 6-8 nodes distance from each other then you have to move one of them temporally. Without a clear overview it takes longer to find something, refactor or understand a shader.
No idea how much work it would take to implement a UDK style zoom but you might be able to make a quick fix with the new "node tree screenshot" feature: on mouse wheel down you make a screenshot and display it fit to the window, like a world map. Clicking would take you to the clicked area.
- Option to disable node previews. Editing an extensive network gets really slow when updating the thumbnails takes 4-6 seconds, especially since this delay occurs after each keystroke when changing a numeric value for example. Ideally thumbnails could be removed on a per node basis. The shader's author can judge if a node needs a thumbnail or not: for example if a whole branch is processing world coordinates then their thumbnails will not carry any meaningful information so they are just a waste of resources and precious screen estate. Many common nodes could be half the size if they don't sport a preview.
As a first pass on this you could add a button which simply disables thumbnail updates.
It might look like I'm nitpicking as these problems don't technically prevent anyone from creating shaders. However a bottleneck on the user side (patience, understanding) is still a bottleneck.
I have two main issues:
- Zoom is extremely important. In a full screen 1920x1200 you can reasonably place 9 nodes horizontally and 8 vertically (both sidepanels are as small as possible). Of course most networks are not evenly distributed, usually more wide than tall so in practice you are able to see about 20-25 nodes at best, a smaller and smaller percentage as your shader grows. A side effect of this is that if you need to link two nodes more a than 6-8 nodes distance from each other then you have to move one of them temporally. Without a clear overview it takes longer to find something, refactor or understand a shader.
No idea how much work it would take to implement a UDK style zoom but you might be able to make a quick fix with the new "node tree screenshot" feature: on mouse wheel down you make a screenshot and display it fit to the window, like a world map. Clicking would take you to the clicked area.
- Option to disable node previews. Editing an extensive network gets really slow when updating the thumbnails takes 4-6 seconds, especially since this delay occurs after each keystroke when changing a numeric value for example. Ideally thumbnails could be removed on a per node basis. The shader's author can judge if a node needs a thumbnail or not: for example if a whole branch is processing world coordinates then their thumbnails will not carry any meaningful information so they are just a waste of resources and precious screen estate. Many common nodes could be half the size if they don't sport a preview.
As a first pass on this you could add a button which simply disables thumbnail updates.
It might look like I'm nitpicking as these problems don't technically prevent anyone from creating shaders. However a bottleneck on the user side (patience, understanding) is still a bottleneck.
Answer
0
Answer
Completed
Freya Holmér (Developer) 11 years ago
There's now a checkbox in 0.23 for disabling node-preview updating, zoom is already open in another topic!
It is definitely messy to deal with large node trees at the moment
I would prefer to have one request per topic, so, I'll ignore the zooming in this topic.
Zoom has already been requested, as you know, and is one of the top-prio things I'll look into. (That said, I have looked into it several times and had issues getting it to work. It's a big time sink)
I have thought about two ways of disabling node previews. One way would be to collapse them to smaller icons instead of visible textures, and another would be a checkbox to simply not recalculate them, like you said. For now I'll go for the latter.
It is, however, sweeping the problem under the rug. What I should look for is a way to calculate them faster :)
I would prefer to have one request per topic, so, I'll ignore the zooming in this topic.
Zoom has already been requested, as you know, and is one of the top-prio things I'll look into. (That said, I have looked into it several times and had issues getting it to work. It's a big time sink)
I have thought about two ways of disabling node previews. One way would be to collapse them to smaller icons instead of visible textures, and another would be a checkbox to simply not recalculate them, like you said. For now I'll go for the latter.
It is, however, sweeping the problem under the rug. What I should look for is a way to calculate them faster :)
Answer
Completed
There's now a checkbox in 0.23 for disabling node-preview updating, zoom is already open in another topic!
I think the problem is not calculation speed but knowing what needs calculating. Unfortunately you, the developer, can not know what the end user considers important or what calculation lag is still acceptable UX wise.
A solution to the first unknown is to make it easy for the users to express what they deem important, UI polish. For the second part I could imagine a progressive update method: you always spend a fixed, interaction friendly amount of time in each time unit to update as many previews as possible. Outdated-ness is indicated instantly but refresh is spread out, done over time on the whole tree.
(v0.23: Cool! :)
A solution to the first unknown is to make it easy for the users to express what they deem important, UI polish. For the second part I could imagine a progressive update method: you always spend a fixed, interaction friendly amount of time in each time unit to update as many previews as possible. Outdated-ness is indicated instantly but refresh is spread out, done over time on the whole tree.
(v0.23: Cool! :)
I've considered async node refreshing as well, though it would require some restructuring at the moment. That said, it's still a problem in calculation speed, it can be done faster. The node previews are currently done on a CPU level, while it could/should be done on the GPU
This is actually one of my biggest bottlenecks right now. It can take up to 20 seconds just to connect a node to another node with previews on. Not to mention, due to the CPU side rendering of node previews, they are often wrong or don't work at all.
I've resorted to working with no previews, and no automatic update to make it bearable, which basically strips tons of important feedback from the UI.
I've resorted to working with no previews, and no automatic update to make it bearable, which basically strips tons of important feedback from the UI.
I'll look into GPU node rendering at some point. Perhaps soon, since one of the biggest updates yet just released, I can spend time in a new big feature.
I think this is one of the more worthwhile ones at the moment.
I think this is one of the more worthwhile ones at the moment.
Customer support service by UserEcho
