Open sourcing of Meshmoon WebRocket core codebase as realXtend WebTundra

[antont]

thanks - as discussed live & on irc, but just mentioning quickly here too in case someone is wondering, it takes a while at least for us to get to look this more but looking forward to doing that then.

we're now busy with packaging & finishing documentation for the WebTundra 1.0 release which is also the (originally planned as final) fi-ware 3.3 release. we already know from talks & docs that the webrocket codebase doesn't work for that out of the box so have no option but to release that with current.

one idea in the talks has been to take the webrocket code later and port the missing things to that from current / 1.0 code so that it works for all needs and has the recent stuff. a list of those here for info, feel free to add more in case I miss something:

things in current WebTundra but not in WebRocket:

• SceneParser for standalone mode (should be trivial to port as the scene-entity biz is the same)
  • uses xml3d currently which is nice short to write & read, the code (originally from Chiru-Webclient) has txml parsing too
• interpolation of placeable transform changes (should be easy to copy-paste - though needs some thinking as WebRocket doesn't have the separation of network & view data at least the same way as current WebTundra)
  • note: the optimized RigidBody sync / movement message handling would be good to do still too, to save bandwidth
• three.js asset usage: animated chars & skels from three json formats. glTF support
• CustomComponent support, the new way to define static normal components that show in EC editor and have own types throughout the system. I think this may actually replace EC_Script usage: instead of the old way of making a EC_Script to point to your code and EC_DynamicComponent, you can just write EC_MyComponent and register your code to handle those in the scene & have the data in the same component. we use this new system in MultiPong and WebTundraCar now.
• Entity hierarchy support, this is also used / tested in MultiPong now
• support for creating entities & syncing client side attribute changes to server
  • for security reasons it often makes sense to just send entity actions from clients to apps on server that then manipulate the scene, if the client has permissions to do so, but in cases where such security is not an issue the symmetric sync biz that we have also in native Tundra is perhaps good anyhow?

it would probably be a good idea to port the MultiPong example game to the proposed new core to verify that it works for flexible app development similarily as current core.

an alternative route would be to go vice versa and port the required things from the WebRocket code to the WebTundra base -- then the things from that list would be there already. or take networking & scene from WebTundra 1.0 and the three-view implementation classes from WebRocket? might be simple to just add AssetAPI there for example if that's they key part that's missing. about UI API i'm not sure how useful it is in browsers which already provide the UI API - if as you said it boils down to just setting the proper z index for 2d widgets perhaps it could be done in a simpler way?

anyhow great that the code is finally out there so anyone can study it etc - I figure we will too once the current release it out.

[antont]

ah forgot a couple of things:

• LudoCraft's new Avatar system and related improvements to Three.js's animation system (those will ideally go to three's upstream so would get to any client that uses three.js)
• unit tests for networking & scene things (including the new entity hierarchy) and animation playback (joosua's skel anim test plays anim and check the resulting transform -- pretty cool), are made using qunit js unit test lib

[antont]

we agreed with Jonne to move the now hardcoded login screen biz to an optional plugin.

same for the camera application system.

[antont]

now merged with the relevant parts from current master too.

we started porting from the SceneParser now so merging this so that the following porting work comes separately from this.