can we have this optional ? what if the node has the same name as the category? what is listed first ?
1 Like
hm… categories are also datatypes. why hide them from the search?
Also for beginners: type in spread in the nodebrowser to get to the spread catetgory and then have a look what nodes it offers. How would you imagine a similar search without category display? I’d list the categories always first.
2 Likes
i just don’t like diving into categories, in beta i get a one dimensional list of nodes when i search, same in cables, same in unity VS. seems like common sense. if not, call it personal preference.
as i said, maybe make this optional, like a configurable search ?
2 Likes
My 2 cents:
I also think flat search is better, since I’ve been browsing thru category like once maybe twice, since i use gamma, most struggle is to find an DataType (a class) that should be connected to some pin and this would end a fail most of the time… In vvvv that was handy when you could switch from flat to category.
You are searching for node and not the category, and it’s much better to have all the data like in’s and outs in one line so you don’t have to move your eyes from search bar and look at some different places (like to the side).
Specially hate when you browsing by some unobvious category hidden ten levels under and you have to start over all the time you add a node…
2 Likes
By the way the node’s name is displayed 3 times.
Maybe the tooltip isn’t necessary :
As well as Ok button because the selection happen already with click or enter.
And Cancel because click outside the node browser or ESC key is already doing it.
EDIT :
8 Likes
In latest previews the node browser shows only the connectable nodes after starting a new link. For sure there’s still plenty of room for improvements, but it already feels so much more comfortable that there’s really no good reason to hold back on it much longer.
Current features
- The system looks at all nodes in scope and tests all its pins whether they can be connected or not. Did tests with Stride, Skia and Fuse referenced and performance was suprisingly ok.
- The connectable nodes get ordered by how good the types match (same type, super type, generic type)
and at what pin position a match was found. For example having a SkiaLayeroutput at hand, nodes which take aLayeron any input are all higher ranked than those which take some genericTorobject. - Like the normal view it will hide nodes which are already covered by an adaptive definition in order to compact the list. For example it will only show
!= [Math]when looking for a node connectable tobooland not all variations like!= [Integer32]etc. - It knows about adaptive nodes and will hide those for which no adaptive implementation is available for the given type. For example it will not show a
< [Math]node when having aLayerat hand even though its input is generic. However this feature is also rather costly especially for low level types likeboolso it might not survive. We’ll see how it plays out.
Current (known) limitations
- It doesn’t know about regions and their border control points. For example a normal
ForEachwill not show up when having aSequenceat hand. - It only tests pins which are visible by default. Would need some more work in the subsequent linking action to traverse the optional pins as well.
- There’s no visual separation between exact matches, super type matches and generic matches.
- For primitive types the results are still overwhelming. And also the adaptive node mechanism seems to disturb the ordering. For example with a
floatat hand we don’t see the+node at the very top. Basically the feature that nodes covered by adaptives get hidden plays against the ordering rule here. Needs some thinking and tweaking still. - We should write some sort of minimal distance function for subtype relations and use it for the ordering. Currently that relation is not taken into account and results for sub and super types look a little random.
9 Likes
and proof that it actually works:
2 Likes
I actually, thought about an addition, for “Ctrl + .” hotkey, if you select node and press it gives you all the available nodes in same category…
Or all the available nodes with same name…
Or opens node browser with this node selected…
I would love an additional node browser in a separate window like we had in beta. The amount of nodes in gamma is overwhelming and confusing. It would be super helpful having it open persistently and not loosing the category / search you are into after creating a node. This is especially important when you are not sure which nodes you actually want / need or when working with an imported .NET lib.
4 Likes
would be nice to have a scalable node browser to be able to read more of the rows
2 Likes
Do you mean you would get rid of the four buttons in the nodebrowser?
I personally toggle a lot between low-level/non low level and external/non external while patching, so having those buried in the settings menu would result in a huge speed loss for me.
you might argue “shortcuts” but having a quick visualization for those things at hand in the help browser is imo absolutely needed.
1 Like
I believe we could just :
- Press SPACE to open the node browser
- Type something (with potential use of up and down arrow)
- Press ENTER
not leaving the keyboard would accelerate the process of adding node by just repeating those three steps.
From 10 years ago :
Global default could definitely sits in settings.
Default could be overriden by toggling shortcuts (in the context of an opened node browser) such as :
ALT+I (Internal)
ALT+O (Obsolete)
ALT+A (Advanced)
ALT+X (Experimental)
ALT+S (Standard)
ALT+F (Foreign, External)
then we could still toggle a lot between low-level/non low level and external/non external while patching but also chain adding nodes without leaving the keyboard.
2 Likes
Agreed, after having used Houdini for a while I really liked throwing down some nodes without having to use the mouse in between.
Houdini also tries to connect (if you want to) the input of the new node to the output of the currently selected node … this obviously would need even more work to figure out the most likely connection, I’d already be happy with being able to create some nodes and manually connecting them after.
1 Like
slightly node browser related, all tools (cables, unity VS and unreal blueprints) allow dragging out a cable from a pin and on release the node browser opens. pretty much what my initial post showed.
in gamma, you have to do 3 clicks for the same result. click and doubleclick. in theory, the well known “drag cable out of pin” workflow could also work in gamma. right now, the behaviour is odd, when you try to drag a pin, it does start a selection. although the pin is highlighted when you start.
a tiny change but would speed up patching and render gamma a bit more familiar to ppl coming from unreal blueprints and other tools.
3 Likes
i just tried the preview version and looked for the most simple solution i could think of, looking for suggestions for a float32 output pin. i’m getting *[Int2] etc. Am i doing something wrong here ?
1 Like
@u7angel That’s what I meant in my 4. point above. For primitve types (like float) the ordering is not very good yet. Nodes one would expect higher up show up in the middle somewhere.
ah ok, understood. cables does some scoring (learning from all patchers) for nodes to list popular nodes first. either this or the nodes need to be curated somehow. which you already do (advanced, not advanced)
I wouldn’t mind some telemetry if it leverages the user experience (you can even do it opt-in).
But obviously a way harder task to implement, and involves a serverside service the needs maintenance, for a tool that’s not in-browser already like cables.
Curation sounds more likely from a technical point of view, but also quite unlikely to happen as it’s a lot of work. Maybe this can be crowd-sourced still and also part of the Ctrl+M menu when building libraries.
Edit:
Giving it some more thought, this can’t be curated. I bet there would be quite some wrong results if you need to give a score manually vs. real world usage.
@lecloneur
I find the nodebrowser filter menu quite handy and would not like to switch to the burger menu. this slows me down. It also shows information on mouseover, so no complaints there.
@u7angel
most of the time when patching, I click on a pin, move the line and directly start typing. I think this is as fast as the dragging behaviour you mention.
Colored icons in unity or unreal - yes this makes things look a lot more organized. I like gammas ui design approach but still - not using colors does make things more difficult. And regarding contributions and nugets - it could get really messy when there is no uniform design language for icons.
One complaint that I have is that the nodebrowser does not scroll down when using the arrow keys. When reaching the end of the list it directly jumps to the buttons.
And it could be a little bit faster to open the “configure” menu from ioboxes. Having the menu pop up on a mouseover would already help. And after I tweak the first value it could stay open. To avoid having to keep the curser in all the time.
yeah, fuzzy search obviousely, but that’s already on the agenda.
cheers