metadata always returns null

[Dad72]

Hi,

Everything is said in the title. If I do scene.metadata, this returns null. If I made sphere.metadata, same thing, it returns null.

Unless it is not done to return the node but to add. In this case oops, I had not understood this property.

http://www.babylonjs-playground.com/#75C29#0

[GameMonetize]

metadata is a field that you can use for your own purpose. null by default but you can use it to save user data

[Dad72]

Ok, I see. I thought about that, but I was not sure.

Thanks DK

[Wingnut]

Hi guys.  I did some playing.

I created this .babylon file in atom editor.  https://github.com/Wingnutt/misc/blob/master/puppychow2.babylon

Just 2 mesh... pasted-in text... fight fight fight until it json validated.    (I'm not too good with my braces and brackets).

And I forgot to null-out the materials, but no big deal.

Notice that the first mesh... the Plane... has "metadata":"hello_fishlips!"

Now into the PG...  http://www.babylonjs-playground.com/#2C8LVE#12

And there it is... hello_fishlips!  (see console)

I really only needed one mesh... to "haul-in" the "hello_fishlips" data, and the mesh could be invisible.  In fact, i could probably use a light, or camera... or even less.

Dad72, you need to make that .babylon file just as tiny as possible, and yet still have it deliver "hello_fishlips" data... into the scene. 

Once you have it really small (text editor trial'n'error), now make your server generate the same small file. 

When server is successfully generating tiny .babylon file and metadata is still importing into scene properly... then tell server to JSON-serialize a JS object, and put THAT string into metadata.

The objective is to retrieve JS object from server... into scene... using serialize-at-server, de-serialize (parse) -at-scene. 

A tiny .babylon file... is being used as a wheelbarrow...  or as FedEx. 

If you get THAT far... then try serializing some HUGE object at the server... and see if the metadata wheelbarrow has a strong tire and good load springs.  Can you bring-in a 1 meg string?  5 meg?  10 meg?  Wow! 

If you continue tests... could you report your discoveries, please?  I would be interested in knowing how much string length... we can "haul into a scene"... with the metadata wheelbarrow.  thx.

[Dad72]

59 minutes ago, Wingnut said:

If you continue tests... could you report your discoveries, please?  I would be interested in knowing how much string length... we can "haul into a scene"... with the metadata wheelbarrow.  thx.

I do not think there's any particular limit if we send a string Json.

But I'm still not sure what the metadata property is useful for. What does it do in the end?

 

[Wingnut]

In your case, it would contain a Collection object... holding editorEvent objects, or at least "entries".  Each editorEvent object contains one "action" by a user.

Which node changed, which property changed, what time was the change, which user-editor changed it, etc.

The server would be continuously publishing a fresh eventCollection.babylon to a folder.  It always contains ALL of the semi-recent editorEvents from all scene collaborators.

In a way, that server-generated, continuously-fresh eventCollection file... is a radio broadcasting tower.  It is always broadcasting a fresh list (collection) of "What has everyone been doing in their editors, recently".

When one of your users/editors retrieves a fresh eventCollection, it parses the metadata string into being a Collection object packed with "recent editor actions from everyone"... and then it checks WHICH of these events it has already "serviced", and which it hasn't.  (it updates itself)

Does editor/user #3 have a mesh scaling to do on a red box (a scaling that was done by editor/user #1)? (an un-serviced event from another editor).   Then do it.  All editors/users are trying to "stay fresh" per the eventCollection.babylon file.  Possibly every 15 seconds, all "subscribed" editors... go get the freshest eventCollection.babylon file... and check it for new editorEvents (from others).  

AND, everytime a user does a change to a scene... it must be immediately broadcast from editor to server, and then server makes a new eventCollection.babylon file (adding that editorEvent to the DB that the server is maintaining).  After server adds editorEvent to its DB object, it serializes that DB object, and writes a new eventCollection.babylon file... with THAT serialization string in the metadata.  In less than 15 secs, all subscribed editors will pull a fresh copy of that file... grab the metadata, JSON parse it into a perfect clone of the server's editorEvent DB... and start looking for new events (un-serviced events).  The editor will "check the mail", so-to-speak.   

Are there any instructions for changes in the shared scene?  If so, do them... and then flag that event as "serviced".  You don't want any editor to do a change twice, right?  Avoid accidental "double servicing" of an arriving editorEvent.

With me?  

All editors'/users' scenes are automatically retrieving eventCollection.babylon OFTEN... and checking "What has changed?".  "What's new?" 

At some point, you will have to delete old events from the DB, so it doesn't get too big.  Events over 1 minute old... get deleted... because the server assumes that all "listeners" have  gotten the fresh mail bag by then.  For collaborations of 20 editors/users all working on same scene... maybe 2 minutes.  EditorEvents older than 2 minutes... are removed from the "What's New?" list.... forever gone.  (or at least stored in the servers "allSessionEvents" big database).  By storing all session events, you can "replay" the session in an editor, too.  The scene could re-draw itself... simply by "playing back" all the recorded editorEvents from all the users during that session.  FUN!  An odd type of SAVE, eh?

This allows "late arrivers" to the collaboration... to get "caught up", too.  The server can send them a "special collection" (a third .babylon file... maybe called "catchUp.babylon"?)... which contains ALL editorEvents from ALL users since the start of the collaboration session.  It contains all "deltas" (changes) to the main scene file... that all the collaborators have done, so far.

Neat, huh?  The ultimate "Who has done what?" central log.

I wonder what data an EditorEvent object will need to contain.  Essentially, every action that can be done in an editor... which everyone needs to have "broadcasted".... must have its own type of event.  For example, there will be scaling events, and positioning events, and rotation events, and material events, and and and... LOTS of different kinds of events.  They all go into the server's "master event bucket"... and are used to generate the next latest "what's new?" eventCollection.  (and to help generate big fat catchUp.babylon files for late arrivers to the session... with the help of the master collection of allSessionEvents maintained at server).

Weird, huh?  Client-side packet pull.    In a way, it is also "Editor TV" because one person can operate one editor... and hundreds can watch those changes happen in THEIR editors.... almost "live".  Quite a nice learning tool.

[Wingnut]

Oh, if you are asking what .metadata's purpose really is... I don't think it has a purpose.  We can use it for anything.  You would be using it as a suitcase/wheelbarrow.    Lee Press-On Object-holder.  A fanny-pack attached to a .babylon file.

[Dad72]

And in the case of adding new object to the scene? Is what a string Json can add the object to the scene. Modifying properties is quite simple to do, but adding primitive objects or meshing complex, I am interrogative about it. 

For the system of event I thought to create a file per user connected and each file would have a timestamp to recover the files below the current timestamp, then delete them when they are updated.

I prefer to create several small files (small package) and one per user for the same event. But I wonder about the creation of objects on the scenes. Will I have to perform functions like: SceneLoader.ImportMesh ? Or is that a string json can add the object to the scene?

 

[Wingnut]

Yeah, good questions... good thinking.  I would use a createMesh-type editorEvent.  When an editor/user "sees" a new createMesh-type editorEvent arrive, it "harvests" a bunch of data about meshtype, mesh size, subdivs, name, lots of data that was inserted into the editorEvent at the point of creation.  This createMesh editorEvent contains everything needed... for another client (a remote client) to assemble a string like "BABYLON.MeshBuilder.CreateSomething("\" + createMeshEditorEvent.name +"\", etc etc.

The editorEvent "processor" built into each editor... can "assemble" (derive) JS strings (from inbound createMesh editorEvents) that can be locally evalled.  When they are evalled, they create the mesh, same as if the local user executed that BJS command.

BUT... none of the editors will have saved TheBigScene.babylon.  At the end of a session, somebody must serialize/save their entire scene to the server... or else future sessions won't start with "the latest big scene".

It won't be easy.  Two important parts in each editor:  editorEventCreator() and editorEventReader_Interpreter_Servicer().  In essence, you are adding EditorProgrammingLanguage to the editors.  Let's call it EPL. 

Each EPL "command" starts as an editorEvent.  And your new EPL interpretter... knows what to do with incoming createMesh-type EditorEvent's.  (let's call them CMEE's).  It knows how to convert an arriving CMEE... into a strip of JS, and then be locally eval'd (to create the mesh in the local scene).

Again, this action has NOT saved the change to the "big shared scene".  Perhaps... after every 200 editorEvents, one of the editors saves the full scene back to the server (possibly behind the scenes, unknown to the collaborators.)  Or perhaps the "big scene" is only saved when the LAST collaborator remaining in the session... closes their editor, and thus ends the session.

You are starting to ask very difficult questions.  I am just guessing and predicting, but... you will want to give your editors as much power as possible.  To do that, createMesh will need to be one of your editorEvent service-types.  At each editor... you might create an "EditorEvent EventType Marshaller".  It "sorts" editorEvents like a post office worker might sort letters.  CreateMesh-type packets [editorEvents] will be sent to the CreateMesh Service Handler.  PropertyChange packets will be sent to the PropertyChangeServiceHandler.  Each serviceType has its own serviceHandler.

But, if you are going to allow complex mesh modelling in your editors... that is much more difficult.  Or if you are going to allow a user to import a mesh... then that user's editor must build a LoadMesh-type editorEvent... and send it to everybody.  (Upon arriving at an editor, that packet-type would be marshalled to the LoadMeshServiceHandler.) 

This is one way to do it.  I once created a similar system, except it used little XML packets, with MANY packet "service types".  The server rarely logged, built, or listened-to these XML packets.  The server simply re-broadcast ALL inbound packets.... to all listening clients.  (all users in "the room").  At each client, inbound XML packets were sorted to their correct serviceHandlers, and their contained data used to make the changes/actions. 

My client was a browser-based CSS-ready chat client, so I had "send chat line" service, "play sound" service, showPicture service, embedVideo service, and "embed vrml" service, etc.  (it was multi-media chat).  Any single user.. could put-on a multi-media show for all other listeners.  (storytelling).  They MUST use media already published on the web... to tell the story.  Multi-media DJ.  In fact, there was a automatic "Can everyone play this mimetype?" checker packet.  It would find users in room who were not prepared to play certain media types, and it would report WHICH users couldn't "play" the media... before the DJ fired the "media cannon".  This helped people help each other... get mimetypes assigned to media players... so EVERY listener in the room... could enjoy the media type.  (esp true for video types).  It was a "Who can play .mp4 and who can't... in this room?"-service.    Failed-media-play prevention system.

But it is the same as yours.  You will have many event-types (service types) and serviceHandlers to handle all of them. My packet-marshaller was where I converted the XML in the packet (parsed it)... to a forMyPurpose object.  Main thing, it put <serviceType> this info </serviceType> into forMyPurposeObject.type.  As soon as the marshaller (mail sorting person) determined what serviceType, it sent that forMyPurpose middleware object... to the correct serviceHandler for THAT serviceType.  By keeping your serviceHandlers specific for a certain serviceType (a binding between TYPE and HANDLER)... then it is real easy to add new serviceTypes and serviceHandlers to the client... in the future.  They are "modular".

Lets pretend... that you will allow text chat among all collaborators.  Now, you add the ChatService as one of the legal eventTypes that an editor can send and receive.  You really have only 3 steps to do... to add chatService.  1. Teach each editor to build a OUTBOUND chatServicePacket with some text and maybe some inline CSS within it.  2.  Install a chatServiceHandler in each editor... that knows how to read/handle INBOUND chatServicePackets.  3.  Tell each editor's marshaller/packetSorter... that the chatService is now a "legal" packet type... because the chatServiceHandler is available to receive packets.  ChatService has been "registered" as a legal packet type.  It is "open for business".  heh

Let's pretend you want to add a "texture preview" service... where a popup window opens and everyone's editor loads a picture into it.  "What do you guys think of THIS texture?"

Same procedure.  You would "register" the texturePreviewService as a legal serviceType for the marshaller (bind this serviceType to a serviceHandler).  Install a serviceHandler that knows what to do-with an inbound texturePreviewService packet... and then you have registered a new service for all your editors.  A texturePreviewService packet (editorEvent)... probably has very little data in it.  Mostly, timestamp, a URL, and perhaps WHO SENT THIS.  One user is "requesting" that all other editors... open SOME URL in a pop-up window. 

A considerate person would do permissions, too.  "Jimmy would like you to view a texture in a popup window.  Ok?  Y/N?"

This keeps users from spamming each other with pornography in the editor's popup window. 

In my now-abandoned multi-media chat client (called Xoozilla), you could send "playAudioRequest" packets to each other, too.  For fun, the server could send playAudio service packets to all users.  If 5 minutes had passed, and no users had sent chatService packets (the room was quiet)... then the server would start looping crickets chirping... in all clients.  hehe. 

Xoozilla was created for multi-media story-telling, as well as multi-media chat.  The playAudio service would append an <embed> or <object> HTML element onto each chatter's DOM-based chat screen... with a URL installed.  When that <embed> was appended onto the user's DOM tree, their own browser would go find the web-published audio file, and start playing it.  SO, the playAudio serviceHandler (available on each client)... created an <embed> element, installed the URL, and then appended it to <chatwindow>.

Sorry for being so long-winded... but... I wanted to give you the few ideas I have.  You will likely have BETTER ideas than mine.  When I wrote my chat client... I was like a baby with a chainsaw.  Just making a mess and experimenting, but the proof of concept was successful. 

You need packet creators (for outbound packets)... and a serviceMarshaller and serviceHandlers (for inbound packets).  My clients used webby telnet clients... to connect to a telnet server... which essentially just distributed all service packets to everyone who was "in the chat room".  In effect, "broadcasting"... with a MOO server (MUD/MUSH server).  (For text adventure games, but I sent/received a different kind of text thru the server... xml packets - little XmlDocument-types.). 

EPL.  Editor Programming Language.  A Dad72 Production.    In the case of XML...  Dad72 Markup Language v1.0.    When you invent a markup language (make-up your own tag names and document rules)... you store those tag definitions and document rules... in a thing called a DTD (document type declaration) and XML validators can use those DTD's... to make sure your XML packets are "valid".  More about that later, as needed. 

Phew... so much talking by Wingnut, huh?  Sorry.  Be well.

[Dad72]

Woaw, indeed, it does a lot of reading. Ok, I'm see what I'm gonna do.
On the other hand my collaboration system will not be on remote editors of one another, they will all on the same domain http (not local) connect with a session system in PHP.

Thank you for all the information you gave me.