Hello 
As a user (and lover) of Houdini, I’m as well a lot into nodes.
I’m trying to get my hand on the BabylonJS Nodes Editors (NME & NGE) but I’m missing so much some simple features :
(Sorry the screencast did’nt grab the mouse but on both videos I’m dragging the center st_noise node)
Box selection with left click (leaving the main panning to mouse wheel click):
Move with Parents (SHIFT) and Move with Children (CTRL)
Who is in, for implementing these features ?
++
Tricotou
That’s a ncie feature to have! you can add it as an issue on github. If anyone from the community wants to jump in and implement this, we will be very happy to merge it.
Hello !
After the recent work of @amoebachant with nodes, I (again) feel a huge need of improving the node manipulation… So, about 1 year later, here I am @RaananW :
This edit is about :
This is SO usefull when you are dealing with hundreds of nodes. When you just need a bit of space between two nodes, you can move them either to the right or to the left, without having to go through a complex selection process
Tagging a few Houdini users 
: @MackeyK24 @Jozef_Plata @leota
Here is a PR draft :
cc @PatrickRyan to validate 
That’s a no we cannot change something that is used since the beginning. (furthermore I have no wheel on my macbook :))
But you have my vote for the new addition!
I have to say I was expecting this one 
Cool !
You know me too well lol!
I pushed to the PR a revert on the select part. Keeping only SHIFT & ALT :
I’m even thinking about a new alias command in my .bashrc :
alias deltakoshPasContent='git reset --soft HEAD~1 && git add . && git commit -m "Revert after Deltakosh has reviewed my shit" && git push -f origin tricotou-dev'
Ok I legitimately laughed:)
I have done the PR in draft mode for these reasons :
# npm run build:dev
npm run serve -w @tools/babylon-server
# Node Material Editor
npm run serve -w @tools/node-editor # join http://localhost:1340/
# Node Geometry Editor
npm run serve -w @tools/node-geometry-editor # join http://localhost:1343/
# Node Render Graph Editor
npm run serve -w @tools/node-render-graph-editor # join http://localhost:1344/
What should I use to test on Smart Filter Editor ? I would not find the config in tsconfig.json
For SFE, you can have shared references but no loops since the connections are directional:
SFE is in a different repo: GitHub - BabylonJS/SmartFilters
You’ll find it in the packages/sfe and you can get started with running these in the root:
npm install
npm run start:sfe
Thanks for helping to improve the usability of the nodes!
Wow ! Ok, I had missed that one.
That won’t be easy to test then, since your repo uses directly these devDependencies :
"@babylonjs/core": "^7.35.2",
"@babylonjs/shared-ui-components": "^7.35.2",
Have you ever tried to use @babylonjs from a snapshot, or a local build ?
Pleasure !
npm link can most certainly help here
I gave it a try… I had a lot of issues 
^^
But at the end I could load locally the sfe with the new @babylonjs/shared-ui-components and it works smoothly
I’m setting the PR from draft to ready 
@Tricotou, I will admit, without undo I wouldn’t feel super confident with this interaction not because it doesn’t help for small graphs or limited nodes in a chain, but how it react with larger graphs with a long chain of nodes stretching across the graph. I see this as a power-user interaction and putting a power user interaction under a single modifier key means users will stumble on it and not always in a helpful way. I can see accidentally hitting shift for adding to a selection (I do it all the time because most of the other software I use picked shift to add to a selection) and then moving a large chain of nodes stretching across the graph and organized in frames. I started testing some of these scenarios with a random graph and found that if you ctrl+click two nodes not in the same chain and then use shift to move a chain of nodes, only the selected chain moves. Is this intended? Does it break what the feature was intending? If this is the desired interaction, we need to be very explicit to mention that the feature only works with one node at a time and that node is the one the cursor is currently pointed at.
Hello @PatrickRyan
I would say yes. I don’t see any unintended behavior in your video :
Most of the time it’s to be used in a case where you have no selection I would say. Now if you have CTRL+CLICKED other nodes (of frame) to bring them into the selection, it seems normal that they move with the node you are dragging
So :
The more I think about this, the more it seems like we are missing the middle ground here. This feature is about empowering users to organize their graphs while cutting down on the click tax for users and also combating drag select problems on crowded graphs. I often do this kind of organization after I have iterated for a bit on the logic, and so I often run into drag select issues and needing to ctrl+click a lot. But I also typically work with larger graphs and make liberal use of teleport nodes. This means that there are times that a parent network is quite long and usually has been organized already. It also means that I may want to drag non-connected nodes due to teleports.
It seems like there is still a need to grab a section of nodes that are all connected, but not all the way back to the beginning of the graph that could be tricky to drag select. It seems like the middle ground here would be that rather than shift to select all the way to the first parent and alt to select all the way to the last child that we allow a shift+click to select all nodes connected between the beginning and end. This would allow both directions (parent and child) selection with a single modifier, and also mirrors how many other applications pair shift and ctrl clicking. Shift being selected nodes between clicked items and ctrl being a single selection regardless of what else is selected.
This would also allow a behavior like clicking a node, shift selecting a range of connected nodes, ctrl selecting a different node and then shift selected a different range of connected nodes. This would allow more complex selection grouping without needing to ctrl+click multiple nodes and keeping a mental note of which node needs to be the last clicked to drag parents or children depending on the modifier you press.
Granted, this adds a click tax to require a second click if you want to drag all the way to the start or end, but I think the tradeoff of the added flexibility for targeted selection and the simplification of the mental model with one modifier key working for all sub-selection grouping is worth adding the one additional click tax to move an entire chain.
I realize that this is the model for Houdini, but the number of Houdini users that come to our tools is likely far smaller than the number of Windows and Mac users who come to our tools which uses a similar selection interaction with shift and ctrl (cmd on Mac). If we were to rely on trained behaviors in our user base, I would always default to a system that is familiar to the largest number of users and potential users.
Hello @PatrickRyan , thanks for your detailed answer !
Then, I must be missing something, sorry…
Does the new feature removed something you had previously ?
About your point with Windows being CTRL & SHIFT (CTRL to select one by one, SHIFT to select from A to B), this I totaly get your point
To my mind, the pros if this feature was exactly not having to “unzoom” the node graph when working deep. It’s more like “Let’s grab this and move it to make space”. To me all the point is about not having to unzoom and do a specific selection, before zooming again…