NME - Inline Node Inputs

I have a request for the NME which I think would help to make the experience of tweaking input values a bit nicer. The current system works fine, but long term I think this enhancement would really help with the usability, especially if lots of user inputs are created and people are sharing “super nodes”.

The idea is just to have the inputs the work the same way that they do in other node editors, such as Blender. Rather than collecting the inputs in the sidebar, they would appear on the node itself. Obviously there are lots of different kinds of inputs so a different UI would be required for each type. I have done a mockup of some of the common ones to demonstrate what I mean. See below.

This inline editing would also be applied to the process of naming nodes and frames.

The other idea would be to group all these inputs together when collapsing a frame into a super node. This would make it very convenient to tweak values without having to open the frame and find the particular node.

I understand this might require a fair amount of work to achieve and is non essential, but I thought it was worth requesting anyway, just in case it is doable.

For editing titles, perhaps it might be as simple as making the element contentEditable and listening for the change. Perhaps there are react libraries to facilitate this sort of inline editing. I see there is a quite popular react library for color picking which could be used to create inline controls for color: React Color

Anyway, just a thought.

2 Likes

personlly I think the inline Color component will mess the screen up when you have a number of nodes. because it takes a bit large area.

1 Like

Oh, I should have made it clearer that I was proposing that the control would be contained within a drawer that opens and closes. After editing the color the controls would collapse and the node would look the same as color nodes do now. Like in the frame mockup on the far right, it would just be a box with color, but clicking on it would open the drawer to give access to the controls.

Do you like the idea of inline controls in general though? Such as the sliders and collecting them together when frames are collapsed?

yeah, it makes life easier, but a lot of work to do you know
up to BBL team.

1 Like

but you are all members of the BBL team ^_^.

If you think you can make that happen I bet we would support you.

2 Likes

I wouldn’t mind trying to help with this, but I don’t know React. I could start learning the basics, prototype these controls in vanilla javascript, then maybe with a bit of support I could translate it to the React version? I will wait to see if there is any more feedback on the general idea of course, maybe most people would actually prefer to leave all the inputs in the sidebar. It’s not bad to have all the inputs in the sidebar, I just think having them inline will make it easier when dealing with large, complicated node materials.

It certainly will help when people are sharing their “super nodes” because rather than scrolling a long list of inputs in the sidebar or expanding out massive frames, they can keep the frames collapsed and still be able to tweak the values.

I feel like peoples have degrees in this NME stuff and I can barely count to ten much less know my abc’s ;p

1 Like

Hmmm, maybe I should write a tutorial for you then how to contribute to the NME and what’s going on there cause it is kinda intimidating.

I have nothing to do this week but work on assets, find contracts and do some updates to the Sprite manager, so nothing super pressing.

Might be worth a video. I kinda don’t feel like im qualified to teach anyone anything these days (I keep on saying the wrong things for some reason latly) but I might be able to get you out of the darkness.

If my wife decides to go out of pre labor into active labor though I’ma be a ghost so it all depends on that.

1 Like

I definitely like the inline edition!! Excellent idea (I will be glad to merge any PR on that wink wink )

For this one I feel like it is against the goal of collapsed frames (To reduce UI complexity)

Byt the way the diagram itself is NOT React based. It is pure JS + html + css

1 Like

Let me push a little harder on my end ;p

1 Like

Any help you could offer on how to contribute to the NME would be HUGELY appreciated. I am going to try and add these inline controls. Just had a first look through the code… :cold_sweat:…this is definitley more complicated than the sort of things I usually build myself. I don’t even use typescript. Going to spend the next few days learning typescript, taking notes on the code, prototyping some of the controls in the same style that you guys use and just generally getting my bearings.

@Deltakosh I’m glad you like the idea of inline controls, I will get to work on this and try to submit a PR. It may take me some time…I am not experienced with working on projects as complicated as this one. I am fairly new to web development.

With regards to grouping the inputs together in collapsed frames, I understand that you want to prevent UI complexity, so perhaps these “frame inputs” could be hidden by default, but accessible via a new icon in the “footer” of each frame. Like so:

This would in my opinion provide the best of both worlds; a default view of the graph where frames are being used to hide some of the complexity of the graph, while also providing quick access to all the available inline controls within a frame.

If this doesn’t seem like a good idea, I will work on the inline controls only and forget about these frames.

Huge! Thanks for that!

Well in this case we are really close to expand the frame right? I do not want to add too much complexity

1 Like

Yes it is quite close to collapsing the frame, but of course the difference is; the controls would still be accessible. I can see you are not keen on the idea though, so I will not try to add this to the frames. I will focus only on inline inputs on the nodes themselves.

Let’s say it will be a step one :slight_smile: I’m never totally closed to anything :slight_smile:

2 Likes

I downloaded BJS, opened it up in VSCode. Decided to run the build step and have a look around in the project…

I got a build error even though I didn’t change anything. :rofl:

" npm ERR! babylonjs@0.0.0 build: gulp --max-old-space-size=8192 --tsLintFix "

I have never dealt with a project as big as this before…or used typescript…or react…or webapack…I know you said that the nodes are built using just HTML, CSS and JS, but…this is some pretty fancy JS haha. It’s definintely going to take me a lot of time to figure out how to add these inline node inputs without breaking stuff…See you guys in like 10 years! :laughing:

I am going to just try and focus on understanding everything in the graphNode.ts file and trace everything back that I need to learn from there. Is that a good place to start?

1 Like

Did you have a look at Start Contributing to Babylon.js - Babylon.js Documentation ???

Basically it should be simple normally run npm install from the tools/gulp folder and then run npm start to test your changes locally.

Once all goood, make a PR and the automated build will take care of the rest.

1 Like

Thank you. Sorry, I didn’t see that page. I was just looking at the readme. I will give it another try after reading these docs

2 Likes

I was in the same boat as you two years ago. These guys have no problem holding your hand through some of the process as long as you are willing to make the walk.

I can’t even count the number of times I’ve asked a “dumb question” and was given patience from people way more then I felt like was deserved. This is a community that strives for everyone to find their groove and if you are stuggling then be sure to speak up and we as a group will help you through it.

2 Likes

Thanks very much for the encouragement! That is good to hear, because I am certainly going to be back soon, asking a lot of these “dumb” questions :laughing:

1 Like