A couple of questions

[Sergiy Byelozyorov]

Hello,

I have been researching realXtend project as a good candidate for my work where I try to bring virtual worlds into the Web. I like your approach to introduce even the basic concepts such as avatars via scripts (especially because they are written in JavaScript). This makes your system very flexible and allows to create versatile virtual worlds. Also during my research I have stumbled onto your technology roadmap (dated May 2012). Unfortunately I couldn't find any later progress reports. I would appreciate if you could help me by answering the following questions:

• Is there a documentation for the JavaScript API used to define new objects? Perhaps you can point me to some source file where the API is defined?
• How do you handle security? What if I create an object with a malicious script? Will it be run on other clients without any checks?
• In your roadmap you've identified problems with scalability. Is this still a problem? Do you scale to the planned 100 avatars? Where is the bottleneck: CPU, memory, bandwidth? Is it possible to scale one server over multiple machines? Have you considered/tried using Distributed Scene Graph from Intel?
• What have you done towards Web adoption? Do you have a newer Web client than WebNaali? Were there any changes in the server architecture that make writing the client easier?
• What is the rendering engine that you currently use? Ogre? Ogre 2.0? Or have you moved to something else?

RealXtend looks like a great and promising project and I'm looking forward learning more about it.

Sergiy

[Jonne Nauha]

I'll try to answer from my perspective. I'm sure the other core devs can chime in as well. The answers might have a slight Meshmoon tone as thats what we are working on with Tundra, but we also a team that contributes a lot to the open source realXtend core on a daily basis.

On Mon, Jun 17, 2013 at 9:40 PM, Sergiy Byelozyorov <rry...@gmail.com> wrote:

Hello,

I have been researching realXtend project as a good candidate for my work where I try to bring virtual worlds into the Web. I like your approach to introduce even the basic concepts such as avatars via scripts (especially because they are written in JavaScript). This makes your system very flexible and allows to create versatile virtual worlds. Also during my research I have stumbled onto your technology roadmap (dated May 2012). Unfortunately I couldn't find any later progress reports. I would appreciate if you could help me by answering the following questions:

• Is there a documentation for the JavaScript API used to define new objects? Perhaps you can point me to some source file where the API is defined?

Unfortunately the realXtend project has been without web hosting for a while, the wiki and doxy pages ar long gone :( We at Meshmoon have been keeping the Meshmoon (and there for Tundra) documentation here http://doc.meshmoon.com/doxygen/. Meshmoon is based on realXtend Tundra so ~90% of the class documentation for example is exactly like Tundra is. You can always generate doxygen documentation from the Tundra sources, check this out https://github.com/realXtend/naali#developer-documentation.

Useful pages if you are interested in scripting

• http://doc.meshmoon.com/tutorials.html
  
• http://doc.meshmoon.com/in-depth-framework-and-api-exposure.html
  
• http://doc.meshmoon.com/doxygen/_tundra_script_reference.html
• https://github.com/realXtend/naali/tree/tundra2/bin/scenes (Various example worlds most of them with some kind of example script)
  

• How do you handle security? What if I create an object with a malicious script? Will it be run on other clients without any checks?

The Tundra SDK part does not really provide (force) any kind of model here, it just helps you get there. Currently there are script hooks that let you define on the server side what each user can do (manipulate the scene). There is also no built in authentication, your application needs to provide it basically. So there is really not much out of the box, it's more of an SDK approach and you get to decide who can do what during runtime.

We at Meshmoon have implemented our own authentication system on top of Tundra, it provides enough stuff for this to be done quite trivially. Basically we have two kinds of users (we have more but for simplicity). Those who can directly manipulate the scene and those who can view and use/run the apps in it. The security comes from scene manipulation, if you don't have access you cannot put a malicious script to the server (as it's a component that needs to be added there). Once you have permissions to manipulate the scene you have quite a lot of power in scripting and can do a lot of things with it. Of course Tundra core protects the client as much as it can when you join and execute a script that is put there. Scripts can't remove/read/create random files from hard drive etc.

To answer to your question directly. Yes it will be ran without any checks, but you need to control who can put that script there. And as said the scripting API is kept in check for monstrous things not to happen. Probably the worst things are 1) crash/halt the client 2) download web assets to the asset disk cache 3) disconnect you from the world or close the client 4) screw with your tundra config files (we have been talking about C++ code being able to lock certain config files so that malicious scripts could not read/write stuff to them).... umm, probably other stuff too but you get the idea. If your world does this, then the user probably wont visit is very many times.

• In your roadmap you've identified problems with scalability. Is this still a problem? Do you scale to the planned 100 avatars? Where is the bottleneck: CPU, memory, bandwidth? Is it possible to scale one server over multiple machines? Have you considered/tried using Distributed Scene Graph from Intel?

I think the last measurements were ran bu Ludocraft and it was something like 64 avatars. This mean 64 _constantly_ moving avatars, which means if you have ~35 non moving avatars you are pretty much at the 100 mark. This was done quite a while ago and I cant remember if we already had the network optimization for movement packets done back end, possibly it was it (Lasse, Jukka?). This was also done with a fairly rough avatar script, the one that can be found from the scripts. I can tell that the avatar script there could have been optimized a lot in many fronts. But probably those optimizations might not even impact the tests that much, as I assume they were running headless clients and the constant movement was done from code (not by real user interacting with the app).

I believe the bottle neck might have been networking and CPU (probably physics and avatar scripts for CPU) at that point for the server, having to send lot of movement to each client. You should dig out the report from this mailing list and read it through. I believe if the target is having lots of avatars, with moderate amount of work you could get to 80-100 avatars. But you'd need to know the systems limitations quite well, like how the script engines work, what are particularly heavy  operations in scripting etc. It might be fun to test how much the tests would show nowadays with the new optimized avatar example and the network optimizations (if they were not already in).

Distributing Tundra to multiple machines has been talked about but there is no concrete plan afaik. You could potentially separate something like physics but then the scene sync/access might get a bit hairy.

• What have you done towards Web adoption? Do you have a newer Web client than WebNaali? Were there any changes in the server architecture that make writing the client easier?

Well, this web thing has been floating around here for a long long time. I think pretty much everyone has given up on the idea of building or sharing parts of the Tundra core for web in mind. I believe some parts could be used with emscript etc. but our Qt and other "complicated" dependencies run so deep that I believe its a pipe dream. Even if you could separate something useful so it would not use Qt, it would break the core into bits and peaces that would not necessarily be very maintainable in the long run and complicate our current way of exposing things with QObjects. I haven't followed the WebNaali thing myself closely, so hard to comment on it. 

We have been working on a websocket + webgl (no plugins) web client for a while now at Meshmoon. It's already deployed and can be tested, just login at http://meshmoon.com/ and go the the "Web Rocket" tab. We had to do multiple things on the server. The main thing is that Tundra networking (currently) does not support websocket connections, so we built a module that does that. It replicates the scene with the same Tundra protocol over websocket binary frames as it would to a native client via UDP. This has the significant benefit of getting native and web clients into the same world mixed together, you wont even know who is from what :) Cross origin requests can be a bit painful problem with assets (not with lab tests but when deploying with a larger scale) as they are certainly not going to be lying where you host the web clients web page, so I implemented a server module for assets also where we can do automatic asset conversions to better suit the web client, handle other "problem" areas with the Tundra asset system etc. Next we built a client from scratch using javascript, html5, webgl and websockets. Needless to say this was/is a lot of work. Implementing the networking, asset system, input system, ui system, scene/entity/component system and all the vital component implementations and many others to get something rendering on screen. We'll you can get something rendering on the screen a lot quicker but I was aiming for a quite feature rich client at that point already.

Our Web Rocket documentation can be found here http://doc.meshmoon.com/doxygen/webrocket/. I haven't advertised this as much yet, but I think we are going to do big things with the web client in the future. These API docs are aimed at developers who want to make client side scripts for the web client. Basically you can already do it today, create a free Meshmoon world, put some content into it, we can enable it to the public Web Rocket and you are off to the races implementing your scripts for both the server (normal Tundra scripting) and for the web client using those API docs. I've implemented all the apps running on the web client with the same API, you can already do some really nice things with it. Drop us an email if you are interested in testing it at sup...@meshmoon.com

Also a mandatory note: Any part of the Web Rocket or the server stack is not currently open source. There are of course things we fixed/improved to the core while developing it, but nothing directly related to the logic. It can be used at our website by our users and anyone can get their scene to Web Rocket (by contacting us) granted that its authored cleanly and works well with it.

• What is the rendering engine that you currently use? Ogre? Ogre 2.0? Or have you moved to something else?

We are still sticking with Ogre, currently I believe 1.8.x in all platforms. Ogre 2.0 won't be out for another year at least. Ogre 1.9 final is coming out soon (in RC now), realXtends lead dev Lasse (works a Ludocraft) will be looking into jumping to it when it gets released.

 

RealXtend looks like a great and promising project and I'm looking forward learning more about it.

Sergiy

Let me know if you have anything else. Congrats to anyone that made it to the end ;) Peace out... 

Best regards,
Jonne Nauha
Meshmoon developer at Adminotech Ltd.

www.meshmoon.com 

[Lasse Öörni]

Hi,
the scalability study Jonne mentioned is here:

https://groups.google.com/forum/?fromgroups#!topic/realxtend-dev/Lzzx_hZu38I

In short, the greatest server bottlenecks with a lot of avatars are CPU processing related:

- Signalling the avatars' changed properties (position, velocity etc.) and recording that these need to be replicated to each connected client. Unfortunately, recording the changes for network replication is an O(n^2) operation, because we track the "need to send update" state for each client separately. This could be changed to a simple mechanism "send to everyone when something changes", but that would in turn prevent per-client interest management and bandwidth throttling optimizations.

- Running the avatar physics control script for each physics tick. This measurement was done without C++ code (the EC_PhysicsMotor component) that was developed to reduce this bottleneck, so in this regard improvement should be expected.

No other significant scalability improvements have been done since, this study was already running the latest Tundra network protocol.

Note that the default avatar scene (bin/scenes/Avatar/scene.txml) still runs the old script-based update, load bin/scenes/Avatar/OptimizedAvatar.txml instead for the EC_PhysicsMotor optimization. However, the optimized implementation is not 100% comparable in features, as it disables jumping/flying.

- Lasse

[Sergiy Byelozyorov]

Hi,

Thank you for the informative response. I am glad to see that there have been decent progress, however, for my research project I am looking for the open-source project because I would need to adapt it for our needs. Can you please briefly mention which features that you've mentioned have been implemented in the open-source realXtend project and which ones are only available in the closed-source Meshmoon? In particular, I am interested whether client-side scripting library and the security layer for handling various types of users are open-source.

Thank you for your time,

Sergiy

--
--
http://groups.google.com/group/realxtend-dev
http://wiki.realxtend.org
http://dev.realxtend.org
---
You received this message because you are subscribed to the Google Groups "realXtend-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to realxtend-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jonne Nauha]

Here is a summary of our closed source efforts

• The main client Meshmoon Rocket plugin that handles authentication with out backend, server listings, joining servers, meshmoon storage, build mode etc. etc. etc. This is closed source for obvious reasons, it ties to our Meshmoon services/backend.
  
• Server side logic modules for handling logins, permission management, security etc. via the Tundra core mechanisms. This is closed source for obvious reasons as well, it ties to our Meshmoon services/backend.
• Couple of additional entity components built in house contained in a plugin, this is shared across server and client just like Tundra core does. Many of the components also would not make any sense as open source as they tie to the Meshmoon ecosystem so strongly, they are not generic enough for Tundra core. Anything generic we develop and send back to the Tundra open source repo.
• Web client server parts as explained in the previous email.

We have built a product with realXtend Tundra and everything we have done can be done by you too, it's just not trivial especially when you tie it to on-demand cloud hosting of the instances :) There is a lot of moving pieces working together.

The Tundra SDK is the same for you as it is for us, its there for people to make apps and/or do products/research. Any time we see a change to improve the core in any way we do it, you can see our track record from the pull request page for that ;) https://github.com/realXtend/naali/pulls?direction=desc&page=1&sort=created&state=closed and our open source fork we work at https://github.com/Adminotech/tundra

As you might notice this SDK term is thrown a lot at least by me, that's what I feel that Tundra is. If you wanna play around with example scenes or write scripts you can do all that with the default realXtend shipped distros https://code.google.com/p/realxtend-naali/downloads/list. But when you want to build something a bit more complete you have to get your hands dirty coding (with C++ or javascript) and implement some parts on top of it to suit your application needs.

Hope you'll join us in the development efforts :)

Best regards,
Jonne Nauha
Meshmoon developer at Adminotech Ltd.

www.meshmoon.com

[Toni Alatalo]

A couple clarifications:

On Jun 18, 2013, at 11:17 PM, Jonne Nauha <jo...@adminotech.com> wrote:

The Tundra SDK is the same for you as it is for us, its there for people to make apps and/or do products/research.

So this answers the question about 'client side scripting library' -- Tundra is used both for servers and clients, and has largely the same API for C++ and JS, so there is no separate client side scripting library but also client side scripts are made with the normal Tundra API. And that is the same open source thing that's used both in open source realXtend and in Meshmoon.

About browser-based client, WebNaali/Tundra/Rocket: there's also an open source version, largely equivalent to Admino's closed version. Both use Three.js for rendering and the Tundra EC model (like the earlier WebNaali implementation did but with GLGE) so include implementations of ECs such as Mesh and Placeable etc. in JS with the Three API. A main difference is that Chiru's work focused more on client side scene handling whereas Admino has an optimised network protocol, idea was to focus a bit differently to avoid some of the overlapping work in the hope of joining the efforts in a common codebase soon enough. We are in last stages of negotiating about substantial funding for webgl+websocket client dev, if that project really begins we can hopefully get this sorted out.

Anyhow the current open source webgl+websocket client, and there's an open source version of the websocket server counter part too (using the same c++ server lib as Admino uses), by Toni Dahl is at https://github.com/K1ll3rF0x/Chiru-WebClient/ . 

Finally a note about limiting script access: as said, currently the default idea is that any script can do anything in the scene. Tundra is not made / configured now for federated worlds where some common environment could host scripts by different parties so that those scripts would be somehow limited to a single object only. Instead, it is made so that normal game and other application development is easy: for example a full game can be one script as it can create and control any number of objects in any way. It makes dev much easier than the SL/Opensim (and possibly Sirikata) way of requiring a separate script for every object and being able to only send messages between the objects to orchestrate a full-scene application. If you are familiar with Opensim region modules, those -- not LSL scripts -- are API-wise similar to Tundra scripts.

However when I originally started making JS support in Tundra (called Naali then as was client only), it was first experimentally in a similar restricted context as SL and Sirikata scripts: it could access only the object it was attached in (actually only a selected set of components in the object then). It is simple to configure the script context, what objects / APIs are available to them. So if someone requires such a limited script context i think it is still doable, possibly quite easy even depending on how much of the core APIs should be exposed to those scripts vs. how much those APIs would leak access to other parts of the scene and app. For example only having the Frame API, but not Scene and Input etc., would allow a script to move/rotate etc. itself based on time, and it could register to handle mouse clicks on it etc. It could still halt the whole execution, though, I don't remember whether preventing that would be easy with the qtscript engine we are currently using.

Just for information if you or someone requires it -- I remember this has been in the talks around TOY sometimes as it might be useful in a school setting to be able to host scripted objects/apps from several students in a common space without needing to worry that some script, perhaps by accident, messes the whole scene.

~Toni