 and welcome to the first annual open sim community conference 2013 glad to see all you out there in attendance if you would at the end of the speech we will take questions if you will I am those questions to me I will facilitate that and give that to our guest speaker he is a research scientist with Intel Labs with over 40 years of software development experience he has most recently been focusing on enhancing the scalability of virtual world experience and is also the developer of our bullet sim physics engine please welcome Robert Adams good morning all this is Robert Adams and if you can't hear me speak up and we'll have the technical people fix it up so I'm here today to talk about distributed scene graph and this is a project that we've been working on at Intel and we will today what I will talk about is how distributed scene graph solves the scalability problem I'll say a little bit about how DSG works and then I'll talk about how you could use DSG in your grid that is DSG is not in different technology is not separate from open sim but actually it's an open simulator plug-in that you can add to your grid for scaling and then I'll of course get pointers to resources so you can incorporate it in your grid and use it so of course what we want in our virtual worlds is more bigger we have we enjoy our small groups of people but there are usages for large numbers of people so you want thousands of interacting users if you have large projects or large events like this you want lots of scripted objects that interact like there was a project to do artificial life forms and you want hundreds and hundreds of plant hundreds and hundreds and thousands of plants you might want to do large data visualization in the world and or it for many different things and you might want to do large-scale simulations like maybe a whole solar system and sometimes you really do want a crowd not just for events this slide is a experiment that we did with 500 plus avatars walking around a city for doing crisis control how to manage teams you know teams of families how you'd find each other and this is you know you just need hundreds of users to properly model a city or some event so in looking at this of all the problems with virtual worlds Intel thought it was interesting that scalability was an interesting vector to approach both in the interaction how to get many people to interact in the granularity from very small to very large events and also in the fidelity how to make interaction better how to make the physics you know I can you play a virtual game of ping-pong if you really had better fidelity of physical interaction and response so these are all dimensions of scalability and the main one that we talked about in or worked on the DSG is the interaction that is adding more avatars so here is a this slide is kind of a picture of the existing architecture of open simulator so you have your grid services shown at the top and then there's a some simulator with some regions in it and the regions have physics and script apnea on it and then there's a whole subsystem dealing with talking to all the users and there are several bottlenecks in this implementation of course the CPU that is used for the simulator like physics can get overloaded or you can have too many scripts and just the general interaction of things within the virtual world can overload the CPU the connection between the simulator and the users is also a great bottleneck because it scales exponentially as the number of users increase and if you think about it if there is a hundred people in a region and one person moves the simulator receives that one move but then has to send it out 99 times so if you add another person that 101 that hundred and first person moves I have to send it out 100 times and so as you add people the actual amount of bandwidth needed grows exponentially and that puts a phenomenal load on a single simulator and so these are the various the monolithic simulator that architecture that we use an open simulator it has many choke points and the conventional solutions to these choke points are to either spatially partition the virtual world which is which is how open simulator and second life did it by creating regions so you don't have to simulate the whole universe on one computer you can just simulate one region and another common way of doing it is sharding which is making duplicates of the same place and then somehow allowing people to interact with that place independently and both of these have some pros and cons the approach that that DSG took was to break apart the simulator that is what if we took physics and the script and the clients and we separated them out into separate instances we spatially break the world into what we call quarks for lack of a better term and these quarks can be any size that it can be eight by eight or sixteen by sixteen and you have multiple instances of a quark which so a quark can be up to a region size and we've done a lot of work with just region size quarks but you allocate the actors to quarks that is physics doesn't have to be the whole region physics can only can be some of the quarks in a region and so you could like have two physics engines in one region then DSG has a infrastructure which synchronizes the properties between the quarks so I'm kind of just diving into this I'll give some examples up here and in a second so and what DSG does is build on the existing open simulator structure so DSG separates the virtual world simulation components so they can be mixed and matched as needed so rather than getting one region that has one physics engine and one script you could have one region with multiple physics engines or multiple script engines as needed so some of the terms we use in the distributed scene graph implementation is we call the scene graph the world that is all the objects in the world make up the common graphics term of a scene graph the spatial partition of it we call a cork an actor is someone that is a is a piece of code or or person that changes properties of things in the world so like a user pushes the forward button so the user is an actor that's moving the avatar forward or gravity is affecting a object so the physics engine moves the object down so the physics engine is an actor and so these actors the actors don't just have to be these script engine physics engines client managers they can do other things like someone proposed a an explosion actor and what that actor does what is when an explosion happens somewhere it applies outward force to all the objects around and it just acts on things in the world we do have done universe or solar system simulations with doing n body simulations so one of the actors was a thing that moved that interacted objects but based on gravity and then we have a synchronization system that synchronizes the the contents of the various instances of the corks that have their actors so here here's kind of an example so say that this is an area you can see this region or this region or this virtual world area that has thing people on it or activities happening on it so there's some areas with moderate activity there's some kind of party locations and there's some areas where not much is happening and so this is the usual thing one gets of uneven simulation requirements here's one way of breaking that up with DSG one actor I didn't mention was an actor we call the persistence actor whose job is to keep the contents of the world saved so if there's any problems the persistence actor can restore them or keep them so you reboot it you can get everything off the disk we have two script engines one doing most of the area and what and another one handling just the busy area that has lots of people in it there are two physics engines one for the larger area where not much is happening and one for concentrated on the area where there's lots of activities the client manager the connection to the users we have put a lot a bunch of the corks and giving them to one client manager so and then the individual party regions each have their own client manager and that way any latency or any bandwidth between those corks is reduced and also we have three different servers now going out to the users which spreads out the bandwidth so here in this example we have taken the area analyze the uneven usage and then allocated actors to maximize well minimize the hardware used but maximize the utility of the of the simulation and DSG behind the scenes is synchronizing the contents of all the so what if the physics engine move something over here that movement gets persisted and that movement shows up in the script engines and the client managers so DSG is madly synchronizing all this stuff between the instances here is one particular usage this app I believe Douglas Maxwell is speaking tomorrow as a keynote on some of the training that they're doing with large numbers of people in a in a world so like you have like a village and you want to have village people and you want to have soldiers interacting in there and so you need many many people and one set up we did with that is using some dedicated sister servers for the persistence engine the physics and the scripting so those all happen dedicated servers but then there's connections out to a client manager that's in Europe a pair of client managers that are in Virginia and a pair of client managers on California these were allocated to are on EC2 so they are you can create more if you wanted to in the connections but one of the cool things about this particular configuration is the bandwidth to the users the high bandwidth is moved out to where the users are and we can get hundreds of users here on the outside with only five connections to the in the central servers and so the bandwidth load on the central servers is greatly reduced and the bandwidth requirements to get to the actual users so that they see all the movements and that sort of stuff happen out in the in the network closer to the user so this is one configuration of DSG here's another use of the DSG there's this is a a Galton box you may have seen these at at your your local science museum or whatever you drop the balls in the top and the balls bounce around on the slats and they go down the structure and form of polymetric distribution at the bottom and this one is a very tall one with hundreds and hundreds of balls falling through it they're kind of fun to watch the balls fall down but what we did was we allocated multiple quarks underneath so this picture the diagram on the upper right is a top view you can see the slats across it and the quarks are added with more in the center because that's where most the load will be and fewer on the outside and so we were able to allocate eight physics engines across this this Galton board to allow the simulation of all the all the hundreds of balls that are falling down it and little graph it shows the ideal and the computed distributions which are pretty close now there are a bunch of things that we did to make effectively border crossings that is the movement between two quarks two adjacent quarks smoother the we have so there's there's a whole bunch of details behind this there's things called passive quarks which are kind of pre-staging quarks to get active objects next to the quarks so the transition is easier to make make the crossings happen smoothly so the balls simulate properly as they go down the the Galton board so there's there's a lot of stuff you can do with the smaller quarks and the quark infrastructure that allows for smooths or smoother transitions of things but the point of the slide is that this is another use of needed many physics engine needed better allocation of physics and then we were able to apply that multiple actors to this situation so how does one add DSG to your grid now DSG the sources are publicly available and they merge and compile with the current open simulator master so you just take the open simulator distribution you add DSG to it and compile and DSG is there then then this small matter of configuration as with everything in open simulator and DSG works with either the robust or the simian grid services so you can use either one so what you do is you compile DSG into your simulators you identify the regions for scaling and why you might want to scale you assign the grid map locations for the multiple instances and this is a technical detail because of the way we integrated with open simulator is each of the instances gets its own grid location so you can find them and then you do the well also all the actors all the the peripheral ones other than the non-persistent one all use null storage so there's no database setting up on any of the actor instances that they get all their information from the persistence agent who is a persistent actor who is the only one who has an actual database so this kind of one central server and one central database and that's all fed to all the other regions and then you just configure and run as easy as that and like like like the audience said it's a small matter of configuration so the DSG sources are available under the same bsd license as open simulator they're at this github location and it builds as part of open simulator by dropping it into the add-on modules directory so we put it into add-on modules because that's an easy way of integrating with the pre-build XML and and everything else there is documentation on the wiki and bug reporting the issues there on github and the the plans for DSG is over the next few weeks we are beefing up the documentation to include how-to's and cookbooks that sort of stuff to make configuration and running DSG easier and better so distributing graph is an alternate architecture it's a drop-in for open simulator and so this is this is also a pitch for how modular open simulator is adding region modules or drop-in functionality I mean even changing its underlying architecture is the modular architecture allows you to do that and that's what we built on and so you can do a distribution of your simulation you can do augmentation of the simulation by adding more actors with the DSG architecture and we are we have a DSG demo region running for the Army Research Lab social event that'll be at 230 at PDT you just hypergrid to atropia dot military metaverse dot org colon 80 colon art atropia and you will magically end up in some DSG region if you once you go there you'll notice you'll be in atopia atropia dash cm 1 2 3 or 4 that is you'll end up in one of the client managers but even though you're in a different client manager you will see and interact with everybody else that's in that same atropia region and so come and visit us at 230 today PDT and that's my presentation are there any questions Robert we have one how dynamic is the allocation mechanism for actors at the moment that the configuration of actors is static it happens at boot time although the structure is built to allow dynamic allocation that is the actors can come and go and so what is missing from now from dynamic allocation is the smarts to decide what to change and then to do it to to enact the change but because of the way the actors are separate we you can do things like say the script engine crashes and just you know stops working for a bunch of quirks you can just start the script engine again and it connects into the infrastructure and starts scripting some more so we've one of the nice features of the separated actors is the ability to start and stop the individual actors and we've used that you know if you ever find bugs and script engines physics engine you can just restart them and and they continue on and and that is that's kind of the first part of the dynamic configuration so the ability is there but it's not implemented yet all right we have any other questions okay well if if not please come and visit us in atropia and we can talk about it more there and also you I'm Robert Adams on a less grid I'm here I'm in the developers channels I am Robert Adams at intel.com feel free to talk to me or anyone on the Intel team to about using of DSG we can help configuration and helping you get it going Robert we have one more okay the the tour schedule the web says Sunday and you said that there will be the the breakout today sometime let me look at my schedule so at 2.30 today there's the Air Force Research Lab Discovery virtual open house at 2.30 today so maybe there's a problem on one of the web pages but the the multicolored schedule page says it's 2.30 today and we we will be there today okay atropia is open all weekend for tour and on the website for 2.30 Sunday special event as well okay okay and that sounds like the end of speech for today I want to remind the audience that they can look at the conference schedule back at http colon slash conference dot open simulator dot org slash 2013 slash and that will bring up a lot of information for you about the conference thank you Robert that was very interesting very interesting presentation right thank you