New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open sourcing of Meshmoon WebRocket core codebase as realXtend WebTundra #57

Merged
merged 4 commits into from Apr 7, 2014

Conversation

Projects
None yet
2 participants
@jonnenauha
Member

jonnenauha commented Apr 3, 2014

No description provided.

@antont

This comment has been minimized.

Show comment
Hide comment
@antont

antont Apr 3, 2014

Member

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.

Member

antont commented Apr 3, 2014

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

This comment has been minimized.

Show comment
Hide comment
@antont

antont Apr 3, 2014

Member

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
Member

antont commented Apr 3, 2014

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

This comment has been minimized.

Show comment
Hide comment
@antont

antont Apr 7, 2014

Member

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

same for the camera application system.

Member

antont commented Apr 7, 2014

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

same for the camera application system.

jonnenauha added some commits Apr 7, 2014

Merge pull request #1 from playsign/dev2porting
Merging current WebTundra code to port important things into the new SDK. This preserves history vs. just copying the files as new to the empty/orphan branch.
@antont

This comment has been minimized.

Show comment
Hide comment
@antont

antont Apr 7, 2014

Member

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.

Member

antont commented Apr 7, 2014

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.

@antont antont closed this Apr 7, 2014

Implement ThreeJsonAsset for loading meshes from three .json files. T…
…his required making AssetFactories tell

AssetTransfers what data type should be used for the network request (so the data is in the right format when deserializing hits
the fan).

@antont antont reopened this Apr 7, 2014

antont added a commit that referenced this pull request Apr 7, 2014

Merge pull request #57 from Adminotech/webrocket
Open sourcing of Meshmoon WebRocket core codebase as realXtend WebTundra

@antont antont merged commit 05c8f38 into realXtend:dev2 Apr 7, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment