Read / write metadata using the inspector

Hi everybody,

Maybe it’s already possible but i don’t find it.

I think it could be great to have a button in the inspector which shows the metadata of the clicked mesh.
We could add or delete metadata and save them in the mesh using the inspector.

Thanks,

Boris

2 Likes

cc @carolhmj and @RaananW

@bvaisman it might be hard as they are fully untyped and it would only be raw JSON I guess

Yes you’re right, it could be only a big editable text input on an opening window.
I’m a little bit fed up with the console.log on my clicked meshes. :wink:

But maybe it’s not a good idea.

Tell me.

Thanks for you answer.

I don’t see a reason why we can’t display it, but I don’t think adding an editor is so trivial. What will we save? json? string? will the editor validate the JSON you provide?
What if you add a very complex object to the mesh’s metadata?

I don’t know exactly what happens if the JSON string is not valid. I thought that metadatas were only additional informations about meshes with no influence on their display. If it is, I mean that it does not matter if the JSON string is valid or not. Maybe, in a first step, you could add a message to prevent the user that the JSON string won’t be validated automatically.

I am mainly talking about editing a javascript object :slight_smile:

the node’s metadata object can hold anything you want. not only primitives. It can be a different mesh, can be an object holding the entire scene, whatever you want it to be. We should probably be able to display it using some form of a serialization method (my assumption is that it will be a very simple json serialization, avoiding complex objects), but editing it is not an easy task.

Ok, if it is not trivial to edit it, and I really believe you, it could be displayed in a beautiful way, may be with the stringify function with parameters such as stringify(mymetadata,null,4).

I think that would be a good first step.

Sure, want to add an issue on the repository? you can reference this forum conversation to the featur request, and we’ll take it from there :slight_smile:

2 Likes

Done… :wink:

And thanks for your answer.

2 Likes

Pull request:

added logNodeWhenPicking setting, state and function by j-te · Pull Request #13643 · BabylonJS/Babylon.js (github.com)

1 Like

Thanks for the PR! But I am pretty sure this is not the reason this thread was opened. Or is it?

You’re right @RaananW, it is not exactly what I thought but this is a first step, thank you @j-te .

My initial purpose was to show the metadata of the mesh / camera / light IN the inspector and not in the console. And in a second step, it would be great to edit it.

Probably the difficulty is to show JSON values in a treeview explorer which is in the console but not directly in the INSPECTOR.

1 Like

The reason I thought the log was a good idea to add today is it’s an accessible way for debugging any .glb & metadata in the inspector and sandbox. There are also non-devs that use the web tools so it goes further than you may think. The browser dev console is a UI and it’s possible to set/mutate the properties. Maybe I’m too old-school!

Long-term it would be good to have a metadata editor, I imagine this could evolve into something slicker with schemas. I’m happy to have a go but didn’t want to bloat the devDependancies for the beautifying @RaananW what do you think?

The metadata editor:

  • A detached window within inspector (or new browser window) so the user can maximise screen-space
  • A basic text editor with JSON validation & auto beautified formatting
  • Two buttons for the metadata: Reload & Update

In terms of adding a function to the selection observable in inspector, here is another way:

  const root = document.getElementById("debug");
  if (root) {
    scene.debugLayer
      .show({
        globalRoot: root,
        overlay: true,
        embedMode: true
      })
      .then((debugLayer) => {
        const customFunc = (entity: any) => console.log(entity);
        const customObserver = new Observer(customFunc, -1, null);
        scene.debugLayer.onSelectionChangedObservable._observers.push(customObserver)
      });
  }

Then in your dev environment you can go to town on testing the Node entity & metadata in many ways. Have a think about your workflow @bvaisman because in-code validation will be needed at some point, so your app may just have a JSON upload functionality straight to the metadata property. Let us know if you have specific use cases for anyone to help.

So, my very basic brain is telling me - we should first start with showing the JSON data of metadata. THis can be done using JSON.stringify, which also allows (a form of) beautifying.
Now, to simplify the process, and since the inspector was not meant for that, I don’t see a reason to provide a JSON editor in it.
The JSON can be shown in a textarea, and one could simply paste a new JSON and press a save-button that will be validated using JSON.parse, and will be set as the object’s metadata. Simple, effective, does the job.

I agree. But I think that the input textarea should be in a new window to show a large amount of lines.

Let’s make it simple in a first step.

1 Like

To be honest, I don’t see the need for a new window or too much work over it :slight_smile:

Not a lot are using the metadata object, and those that are using it should be able to know the schema of the metadata they have provided, and the size of it. If they want to see it in the inspector - I think it’s great! In a scrollable text area that also allows them to view and edit the text in it. I know it might be a little weird from time to time, but it will serve its purpose :slight_smile:

Let’s start with an expandable area with a text-area in it (that is resizable to the size of the inspector). Don’t forget - the inspector itself is expandable (unless configured differently)

The playground is using monaco-editor so may be good to start here.

Not a lot are using the metadata object

Devs don’t really need to until they do… but there’s definitely a need in modelling workflows for industries such as architectural and construction. My workflows are to utilise 3ds max scripts to build the metadata object and then just parse it on load. To be honest it’s better to keep the metadata external but ensure there’s a GUID for the relationship. The metadata object size should be kept minimal, in my opinion. It’s fine to have pointers in the metadata property, so the editor still works in this respect.

I’ll park this for now unless the force becomes stronger. I agree it’s probably better for focus in other areas.

Is this OK? :slight_smile:

  • the metadata property can be set to null and undefined just by typing the literal string
  • the metadata property can also be set as a string or JSON object
  • there is some basic validation but aim was focused on UX
  • there is a known glitch where quoted values "a string" gets considered as a JSON in validation (not really an issue)
  • simple prettifying but not full beautifier with colour - considered re-using monaco-editor however it looked over bloaty/unnecessary
  • there is a bit of duplicate css however wanted to avoid conflicts and not affect backwards compatibility
  • minimal impact on performance by using an observer
  • could probably improve the picking trigger/observer but OK for first-release

New METADATA tab:
meta-inspector

New METADATA pop-up window:
meta-window

meta-window-error

meta-window-undefined

2 Likes

what if its a complex object like a transformNode or a entire script refrence?

1 Like

If it’s not JSON then should be using devtools or IDE testing. Metadata should not really hold functionality. You can copy/paste the whole script in and out

1 Like