NME custom blocks

Feature requests
1

Hey all, so I took a stab at adding support for custom blocks to the Node Material Editor. :smiley:

I based it on Custom Frames and tried to change as little as possible, so the new code and UI should hopefully fit in well. :crossed_fingers:

And if there’s some things that need to be added or changed, I’m down to work out a second draft of the patch…

Let me know how it looks so far and if it seems like a good idea?

Here’s a demo to try it out (it’s just the files from my custom local build, served from Github.io)

And here’s a patch (from the same build).

You can download this example custom block for testing and as a template for implementing a custom block in a stand-alone javascript file: squareBlock.js

2

Ok I have several question :slight_smile:

  • How does it work from the Playground or from code directly? The user has to ensure that it loaded the custom block code first right?
  • How does it work when the user is using ES6 (so BABYLON namespace does not exist)

I believe this defies the NME approach of portability and simplicity :frowning:

1 Like
3

It works the same as custom frames I believe: the custom block must be loaded from local file when it is first added and after that it is reloaded from local storage as needed.

The demo calls BABYLON.NodeEditor.Show from code (it’s the same files as https://nme.babylonjs.com/ uses except that the custom build of babylonjs.nodeEditor.js is used).

I’ve tested it locally, using the playground and that is working well also.

The BABYLON namespace is used only in the custom block’s JS file. TBH I hand’t considered that people would want to create their custom block using ES6 (without the BABYLON namespace?)…

EDIT: Hmm I think I see the ES6 concern better now, and IDK either how ES6 could be supported since the custom files are needing the BABYLON namespace…

4

Custom frames are only using known nodes. There is no need for additional code. In your case if I use your node material without loading the custom code it will fail.

Also even if I’m loading your code inside an es6 environment it will fail as the Babylon namespace will not exist and thus your custom code will not compile.

My view of the custom code was more around something that does not requires js at all. More a combination of json info about inputs and outputs and associated glsl code. That way we could save it inside a snippet

But please don’t get me wrong, I find what you did really interesting but I do not think we should add it in the framework because of the limitations I highlighted earlier

3 Likes
5

Aah, okay, I had thought the custom frame’s json file was creating the same sort of dependency/limitation, but it sounds like the material can be saved and shared without the custom frame by just saving the frame’s nodes, so it’s not really the same situation…

And TBH I don’t really use es6 environment so I didn’t even think of the namespace concern.

So I think I will chalk this up to a learning exercise and try to find something else to tinker with LOL.

Thanks for the feedback and explanations :slightly_smiling_face: :beers:

6

Actually your idea for custom code sounds very interesting, maybe I can regroup and try to help implement that one instead? :slightly_smiling_face:

7

Sounds like a good plan :slight_smile:

1 Like
8

Okay, I’ll see what I can come up with and start a new thread once I’ve got the first draft work out. It sounds like the user will be responsible for creating the json file and NodeEditor will be responsible for loading the json file, serializing and unserializing it when the material is saved and loaded - and all of that I’m thinking will be wrapped up in a new class called CustomBlock that extends the Block class to implement the json handling part.

1 Like
9

Here’s the new thread for the second draft proposal/PR for NME custom blocks, based on json files :point_down: :slightly_smiling_face:

1 Like
10

This seems pretty good!

1 Like