diff options
| author | David Walter Seikel | 2016-01-01 21:57:24 +1000 |
|---|---|---|
| committer | David Walter Seikel | 2016-01-01 21:57:24 +1000 |
| commit | bc44e6b3339976fc08d86eecc79f972fb90aecab (patch) | |
| tree | 8c4dc473840ba773a7a2ee393b2045cc758dc024 /docs/SledjHamr.html | |
| parent | Added a test HTML page for bringing the design docs into the source repo. (diff) | |
| download | SledjHamr-bc44e6b3339976fc08d86eecc79f972fb90aecab.zip SledjHamr-bc44e6b3339976fc08d86eecc79f972fb90aecab.tar.gz SledjHamr-bc44e6b3339976fc08d86eecc79f972fb90aecab.tar.bz2 SledjHamr-bc44e6b3339976fc08d86eecc79f972fb90aecab.tar.xz | |
Import the design docs from Drupal / MediaWiki.
Diffstat (limited to 'docs/SledjHamr.html')
| -rw-r--r-- | docs/SledjHamr.html | 134 |
1 files changed, 134 insertions, 0 deletions
diff --git a/docs/SledjHamr.html b/docs/SledjHamr.html new file mode 100644 index 0000000..9aade32 --- /dev/null +++ b/docs/SledjHamr.html | |||
| @@ -0,0 +1,134 @@ | |||
| 1 | <html> | ||
| 2 | <head> | ||
| 3 | </head> | ||
| 4 | <body bgcolor="black" text="white" alink="red" link="blue" vlink="purple"> | ||
| 5 | <h1> New virtual world architecture (by onefang, some ideas nutted out with Alice and others) </h1> | ||
| 6 | <p>(This may look like a half polished design document, but it's really just a brain dump. I just write well. Starting to turn it into a half polished design document though.)</p> | ||
| 7 | <p>This might sometimes be referred to as SledjHamr, SldjHmr, NGIW,or the term that currently has favour - Open Magic Garden (OMG).</p> | ||
| 8 | <p>I'm a firm believer that we should use the existing SL based viewer code, and the existing OpenSim server code, as crutches. They are both crap really, but they have the benefit of actually working. The alternative is to throw it all out and start from scratch. A virtual world system is REALLY BIG, something a small team will take years to write, even if we did it full time. So that would be many years before we even have enough of a brand new system to have ruth standing still on an empty plane. By leveraging existing systems, we already have something people can use, we just make it better when we can. OpenSim at least is modular, so we can replace things one module at a time. For both server and viewer, we can chip away at existing code at our leisure, slowly turning insane code into sane code. Meta-impy is the fork I made of the Imprudence viewer, so that is the viewer I'm changing.</p> | ||
| 9 | <p>BTW, my definition of "sane" code is - performance critical stuff should be in C, with perhaps some hand written assembler. A lot of the virtual world stuff is performance critical. Things should be written as small, and as flexible, as possible, so that many small things can work together in unintended ways to do cool stuff. The Enlightenment Foundation Libraries (which I have done some development for) are a good example. matrix-RAD was my 10 year experiment in pursuing some of these ideas, though it was in Java.</p> | ||
| 10 | <p>See <a href="NGIW.html">NGIW</a> for more ideas from Alice. Interestingly enough, some of my ideas are basically the conclusion of one of the OpenSim developers Masters degree dissertation <a href="http://justincc.org/blog/2010/10/25/my-masters-dissertation-on-internet-scale-virtual-environment-architectures/">http://justincc.org/blog/2010/10/25/my-masters-dissertation-on-internet-scale-virtual-environment-architectures/</a> . Note, I read that after I came up with these ideas.</p> | ||
| 11 | <p> </p> | ||
| 12 | <h2> boxen </h2> | ||
| 13 | <p>We can have servers that just store and forward the sim data. Clients edit that data, if they are allowed to. Special servers (engines) can do the physics and server side script running, they act as clients to the sim data server. No reason why this can't all be on the same computer, or separate ones.</p> | ||
| 14 | <p>Might even have client side scripting that just acts like a script engine (using the same engine code). Not sure how well client side physics would work, but Kitto seems to think it's possible, and I trust his wisdom on physics. At the very least, the client could be responsible for it's own avatar physics, with just some quick sanity checks by the server physics engine.</p> | ||
| 15 | <p>In fact, we could even fully distribute the workload of physics (or scripting). Imagine a system vaguely like DNS. Each object has one unique authoritative simulator, and any number of non-authoritative ones. One non-authoritative physics engine is my client simulating your object. An authoritative one would be you simulating your object. I could usually simulate most objects myself in the client. An obvious exception could be your avatar. Then periodically I check the authoritative server for results for some of the objects I'm simulating. When I find an authoritative server is frequently giving different results from non-authoritative servers, I have found a cheater, and should stop playing with them. (Or maybe I found a bug, or an avatar, or maybe an object with some kind of secret (scripted?) behaviour that hasn't been communicated to me and my client. Obviously would need to handle this detail in a real system.) Combat oriented folks could literally do this, "You have been ejected from the region for cheating". Social oriented people might just refuse updates from a 'cheating' server, and elect other servers to become authoritative wrt some objects. Adding protocols to (re)elect the authoritative simulator for an object could result in systems with no central server smarter than jabber or a webDAV type store. The system might well have bandwidths an order of magnitude less that are currently consumed.</p> | ||
| 16 | <p>Note, this leaves the way for physics and script engines to just be generic stand alone servers, not specifically attached to any one sim. Swapping about to service any given sim data server at any given moment. Possibly splitting up the load on a busy sim if needed. Clever load management should be used.</p> | ||
| 17 | <p>Would be preferable to have any one sim data server being serviced by the same physics or script engine/s over time, as then they only have to exchange changes to the sim data when needed, instead of constantly reloading the entire sim state. Script engines in particular need to transfer script state around if they are swapping scripts.</p> | ||
| 18 | <p>So in the end, command channels between the servers, engines, and clients swap all changes around, all talking to the sim data server, which stores persistent sim state, and passes changes onto every one else.</p> | ||
| 19 | <p> </p> | ||
| 20 | <h2> protocols </h2> | ||
| 21 | <p>One could argue that it's the LL created protocol that is the real reason why things are so crap. OpenSim had to reverse engineer these protocols, and then implement them as well as they could so that existing viewers worked. In general the existing protocols are UDP based. This I feel is the reason for the general unreliability of the entire system, UDP just is not reliable, it's not meant to be reliable. LL have tried to build reliability around UDP, but they are really just playing catchup with TCP, which has been reliable by design since the early 1970's. <a href="http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/">http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/</a></p> | ||
| 22 | <p>For transferring of assets at least, I think a fully HTTP based system is a much better idea. HTTP is a well understood and simple protocol created in the early 1990's, it's very mature, with many technologies to solve general problems that plague SL style virtual worlds. For example, web caches just work, with no need to clear them at the first sign of trouble, like we have to do with LL inspired asset caches.</p> | ||
| 23 | <p>The general idea is for a sim server to have a file that describes the sim. This file will have a .omg extension, and will be referred to as index.omg in this document. Like an index.html file, there can be several files at the same level with other names and the same extension. usually for other sims. This index.omg file will include URLs to the various objects in the sim, their position, and rotation. Perhaps their size as well. Mesh support is being added, and they will have URLs stored in world somehow, as well as a URLs to the index.omg files.</p> | ||
| 24 | <p>At least during an interim period, when we have to deal with standard OpenSim and SL servers, we will need a way to stash URLs into places the standard servers will keep for us, and not disrupt things too much. Initially I was using transparent hover text on prims to hold the mesh URLs. This is not a long term solution. What we can do instead is use land and prim media URLs. By URL encoding a URL to a sims index.omg file, or a mesh file, then tacking it on the end of a land or prim media URL after a # character, I think that would do the trick. In theory, the parts after # of a URL are not sent to the server, since the server sends back the entire page, leaving it up to the browser to sort out what to do with the # part.</p> | ||
| 25 | <p>When this has matured enough that we have our own server side code that deals with index.omg files (generally by keeping them up to date when people change things in the client), then we can just have index.omg URLs in world, and add the displaced media URL to the index.omg file. The land media URL points to the servers index.omg, and the server (having already established that it's not an OMG aware client) can then redirect the client to the proper media URL. If the client is OMG aware, it just pulls the displaced media URL out of the index.omg file. Note that this would only really be needed if the two combined URLs end up being too long (255 bytes seems to be the limit). Actual mesh objects that are not part of an index.omg file could perhaps be dealt with in a similar way, but the mesh files would have to be on the OMG aware sim server, so it knows they are being requested by non OMG aware clients to do the suitable redirect magic.</p> | ||
| 26 | <p> </p> | ||
| 27 | <h2> the world </h2> | ||
| 28 | <p> </p> | ||
| 29 | <h3> in world asset server </h3> | ||
| 30 | <p>Unpack an OAR into a web server. An OAR file is supposed to be a complete copy of everything in the sim, including meta data like access lists. In reality, they do seem to miss prim description and prim sit position data at least. We can always add what is missing. Existing OpenSim versions can create these OAR files from the console. My experience with meta 7 is that A) OAR file creation can be automated. B) OAR file creation is not a noticeable load on a busy server. I say these things since I had written a simple script to make OAR file backups of every meta 7 sim four times a day. No one noticed any extra lag.</p> | ||
| 31 | <p>The contents of an OAR file are basically a bunch of XML files to describe the objects in the sim, and the actual assets used to make up those objects. The example OAR files I looked at followed the 80/20 rule fairly well, the assets being 80% of the data, the descriptions being 20%. There are also a few tiny XML files containing the other sim meta data, and one file containing raw terrain data. The assets are just ordinary files, jpeg200, ogg, bvh, lsl, etc. Though the notecard files have some extra header info at the beginning for some odd reason. One thing that is absent is a central description of what goes where. Each objects XML description includes it's position info though.</p> | ||
| 32 | <p>When a user arrives at a sim, they could start by downloading those object description XML files, and the terrain file. Those XML files could compress well 20:1 if all done at once as a tarball. The terrain file is more 2:1 if compressed. This is gz compression, which is supported by typical web servers and web browsers on the fly. Once the user has downloaded the description XML files, they can start to rez things within their draw distance, requesting the textures from the assets part of the unpacked OAR file as needed. Rezzing terrain would be - download the terrain raw data (giving the terrain shape), download the sims settings XML file (giving the texture UUIDs and parameters for the terrain textures), dowload the four terrain textures, then generate the terrain randomly as usual. Note that on first arrival, generally only texture assets would be downloaded. Things like sounds and animations would only need to be downloaded when the sims scripts say they are needed. Notecards and scripts embedded in objects would only need to be downloaded when an authorised user opens them for editing.</p> | ||
| 33 | <p>The alternative that I mentioned above, would be to start with some central description of the sim. Basically the equivalent of a web page, index.omg maybe. This would be a text (or binary) file that only includes the list of object names, their X,Y,Z location, and rotation. Perhaps some small amount of meta data to, like the terrain meta data mentioned above. Then the user would only have to download the object description XML (or binary command list) files for those objects within their draw distance. This is a good idea I think. It maps well to the web that everyone is familiar with, and allows a lot of flexibility. For example, this file and all other data could be generated on the fly by PHP code. Typical CMS systems could be used to manage this content just like all the other web content they manage. This means we just supply protocol and data structures, plus a simple implementation, then step out of the way and let people implement their own variations using tools they are long familiar with. An IETF RFC could be in the works.</p> | ||
| 34 | <p>All of this leaves out the LL inspired DRM system. Our objective to smash the garden walls means that such a system is of no value, there is no central server to control that. On the other hand, we replace it with the mature and well understood web site content protection systems already in existence. In particular, the only real way on the web to protect IP is to keep it on the server, once the client has it, they can copy things no matter what you do. This already applies to all web content. The only thing you can protect from copying is the web back end code, coz you never transmit that to clients. The same level of protection is thus now given to LSL code. Unless it's being edited, it's never sent across the 'net, only executed by servers. When unpacking the OARs, we can leave out the LSL files.</p> | ||
| 35 | <p>To get there from here, we can start simple. Server side really is just a matter of creating OARs and unpacking them into a web server. The web server can be very simple (I've written a suitable one in one page of Java many years ago). At this stage just dealing with static data, with a last modified header support, would be a great start for experimentation. Client code can be modified to check the web server first, then fall back to the usual methods. Simple things we can do to start with, adding the more interesting stuff later. To start with, OpenSim would still be dealing with this stuff, the first step is to run side by side, so we have a small first step, and can use OpenSim as a crutch. The next step might be to generate this central description index.omg file from the existing data in the OAR, then the client can check for that file first. Meshes are new to the old systems, and I already am working on code for those, they will likely be the first things served via an index.omg file.</p> | ||
| 36 | <p>Someone did wonder if this would be a major change to the client. My mesh experiments say it would not be. My mesh system uses an existing modular library that knows many different mesh file formats, and can download these files given an ordinary URL (it even understands file:// URLs). I wrote a tiny bit of shim code that basically calls this library with a URL that came from the sim server, then feeds the resulting vertex data into the right spots of the client rendering pipeline. The library itself was easy to understand, the really hard part was figuring out the horrid LL rendering pipeline so I knew where to stick my one or two line shims. It was always my plan to simply create modules for this library that understood SL style prims. These prims could be fed via URLs to the sort of sim server I'm describing here, or fed from the usual client sources.</p> | ||
| 37 | <p>I should also mention that since we are starting from ordinary OAR files, these do include UUIDs for assets, encoded into the file name. So, for instance, a texture URL of http://grid.example.org/sims/Welcome/assets/00484839-3e9d-4fdb-8512-bd381f7d0737_texture.jp2 could map directly to an unpacked OAR, could be generated from a known UUID, or could have the UUID extracted from it. Not too hard to work in either direction between new and legacy code.</p> | ||
| 38 | <p>In the end, the simulator software can access the in world assets via the same web server. On the other hand, if the assets are stored in a database and managed by a CMS system, the simulator could access it directly. That database could even be the same as the existing OpenSim one, with the web server accessing that. Lots of possibilities here.</p> | ||
| 39 | <p>Alice just reminded me of something I forgot to write down. Amongst the other meta data in index.omg would be URL like links to other sims. They could specify basic type links, like "to the west", or more complex links "300 meters up, 20 meters to the north". No need for them to always be bidirectional, sometimes you can't get there from here. These links are for the sims you can see and get to from this sim. Sim size should also be in the meta data. Perhaps the basic terrain could include an alpha layer if you don't want a rectangular sim? Certainly extending the terrain with a single high rez texture that just paints the terrain should be part of the plan.</p> | ||
| 40 | <p> </p> | ||
| 41 | <h3> inventory asset server </h3> | ||
| 42 | <p>Unpack on IAR into a web server, could even be a web server built into the client, or just the users hard drive. Very similar to the ideas for in world asset server, only in this case, the user that owns the inventory is the only one that gets access to it. They can choose where to store their inventory, or even have multiple inventories in several places. Pretty much like email, the user can choose to store it on their local hard drive, on some web server somewhere (that may or may not also serve their home sim or other sims), store it in googles or amazons cloud, etc.</p> | ||
| 43 | <p>An IAR is very similar to an OAR, only without all that extra land meta data and terrain raw data. It does organise the description XML files into a folder tree, just like it appears in the client. Extra asset types are stored, notably non prim clothing and non prim body parts.</p> | ||
| 44 | <p>Giving an inventory item to someone then just becomes a file transfer, using any available file transfer method. Though the XML and assets should be packaged up, perhaps into a small IAR. Which could include entire folder trees, but without any of the limits imposed by the SL system.</p> | ||
| 45 | <p>When a user is in a sim, their inventory should be presented to the sim as a web server. The user gets to choose what is presented in this way though, they can keep things private until they need to transfer some thing somewhere.</p> | ||
| 46 | <p>Nothing in this design stops people from directly editing stuff in their various inventories as if it was rezzed in world or worn. Except for legacy inventories, and somehow displaying the object so they can see what they are doing.</p> | ||
| 47 | <p> </p> | ||
| 48 | <h3> rezzing objects and avatars, editing things </h3> | ||
| 49 | <p>This is where the in world assets systems and inventory assets systems come together. There are a number of interactions that need to be taken care of. As a general principle, the sim server's web server should also be acting as a caching proxy for the users web server that is built into the client.</p> | ||
| 50 | <p> </p> | ||
| 51 | <h4> User to user inventory transfer. </h4> | ||
| 52 | <p>Alice picks some thing from one of her widely scattered inventories, and hands it to Dave. They could use any method available to them to do this as a file transfer. However, the client should include a built in method.</p> | ||
| 53 | <p>The object (or objects, including a possible folder tree) would be packed up into an IAR file at Alice's end. This file would be put into her clients web server, probably with some authorisation in the web server. The sim server would be informed of this, and that it is for Dave. If Dave is not in the sim, or not online, then something else might happen (we'll figure those out later lol). If he is in the sim, then he gets a notification, his client offers him a choice of his currently active inventories, he picks one, and tells the sim server to go get it. The sim server downloads the IAR file from Alice's client web server, acting as an authenticating proxy, and transfers it to Dave's client. Dave's client then pushes the file to his chosen inventories web server. Some short circuiting of these steps may be possible. For example, some end to end encrypted tunnel (like OTR) may already exist between Alice and Dave, and the file can be transferred through that tunnel. Or if Dave wants it on his hard drive inventory, then his client just downloads it through the sim proxy straight to his hard drive.</p> | ||
| 54 | <p> </p> | ||
| 55 | <h4> User inventory rezzing to sim. </h4> | ||
| 56 | <p>Rizzy rezzes something in world from her inventory. The object will consist of the XML description file (or binary command language file), plus whatever assets make up the object, and whatever assets are in the contents, included nested objects. This all gets packaged up in Rizzy's client into an IAR file, then dropped into her clients public web sever. The sim server is informed, and downloads the file from Rizzy's client web server, storing it in it's own web server for all others in the sim to access as normal. The index.omg file will need to be updated, and avatars in the sim will need to be told to download the new object (sans contents). OK, so the sim server will need to unpack and repack the object, keeping the full version around.</p> | ||
| 57 | <p> </p> | ||
| 58 | <h4> User taking something from (including take copy) sim into inventory. </h4> | ||
| 59 | <p>The reverse of the above. Rizzy asks the sim if she can take an object. If she can, the full IAR file version is downloaded from the sims web server to Rizzy's client. She gets to decide which of her inventories it is sent to from there, or just puts it on her hard drive. If it's not "take copy", then once it is confirmed that the object is safely stored at Rizzy's end, the sim can delete it's copy.</p> | ||
| 60 | <p> </p> | ||
| 61 | <h4> User wearing something from inventory. </h4> | ||
| 62 | <p>This is really just a specialisation of a user rezzing something from inventory. The worn object, or worn non prim item, is stored in the users inventory, and has to be distributed to others in the sim so they can see it. It should follow the exact same code path as above.</p> | ||
| 63 | <p> </p> | ||
| 64 | <h4> User wearing something from sim. </h4> | ||
| 65 | <p>In this case, either the object goes into the users inventory first, or it doesn't. Experiments will be useful. In either case, it can be covered by stuff mentioned else where in this design.</p> | ||
| 66 | <p> </p> | ||
| 67 | <h4> The users avatar. </h4> | ||
| 68 | <p>I have been told that avatars are the most resource intensive thing in a sim by OpenSim developers. This is why you can have thousands of prims, almost as many scripts, but less than 50 avatars in a sim. A typical bunch of half a dozen avatars at a small party might have more prims and scripts than the rest of the sim. On top of that, they are all MOVING! Or at least standing still while the animations make them dance.</p> | ||
| 69 | <p>On the other hand, they could be dealt with as just another type of in sim object. All movement is driven by animations, most of which have to be downloaded by the client from the server, then used by the client to animate the avatars. As far as the server is concerned though, those animations are just like textures - binary blobs in a file, their contents meaningless to the server. The same applies to the avatar mesh - it's just a small blob of parameters sent to the client to drive the morphing of the standard avatar mesh.</p> | ||
| 70 | <p>The first tricky thing is attachments. But again, these are just ordinary opaque objects sent to the client by the server. They have some extra info - the attachment point and the avatar they are attached to (though that last one can be surmised from the objects owner). The position and rotation of the object is relative to the attachment point, but it's still just a position and rotation. It's up to the client to sort all that out, and have the attachment follow the animation.</p> | ||
| 71 | <p>The second tricky part is baked skins. At some point, the three textures that make up the actual skin, have to be composited with what ever textures are used for clothing, tattoos, cum stains, etc., to make up an overall texture to be painted over the avatar mesh. LL decided that this compositing should be done in the client, which then sends the result to the sim, so the sim can spread it to others watching. This would usually be done when an avatar TPs to a sim, or logs on. In both cases, the client is at that time getting buffeted with a storm of network data and calculations, and is busy rezzing the entire sim (or at least that part within draw distance). Is it any wonder that slow computers often screw this up. On the other hand, at this time the sim is also a bit busier than usual, figuring out what to send to the newly arrived client, and sending it all.</p> | ||
| 72 | <p>Note - in this design, we have moved the burden of figuring out which objects are visible to any particular user from the server to the client, in the form of the index.omg file. Perhaps we can swap the burden of compositing clothing layers and skins to the server? In this design, the server is requesting skin and clothing data from the client, though it's possible that the client has told the server "hey, you can use this inventory over there on some third parties server". Yes, we are juggling the work loads between server and client, plus adding others into the mix. Experimentation and options will be needed. Perhaps letting the client and server work out who should be doing what, based on relative free resources at the time?</p> | ||
| 73 | <p>In the existing old design, the server tells the client "you are wearing these things", the client grabs "these things" from the server, composites them together, then sends the result to the server. In this new design, the client might be in control of what is being worn, might already have "these things" on the local hard drive, might even have a cached copy of the composite, then sends it to the server. Or the client has to grab "these things" from a few scattered inventory servers, including possibly the sim server itself, does the compositing, sends it to the server. A possible third choice is the server has to grab "these things" from all over the web, composites them, then sends the result to all watching avatars (including the original avatar). Keep in mind that index.omg might include the positions of avatars, though they are constantly changing, so that might not be such a good idea. Still need to have the server tell the clients where the other avatars are. Taking into account draw distance.</p> | ||
| 74 | <p>When the user is TPing from sim to sim, might be best if they have their baked skin cached, and just send it to the new sim on arrival. Changing clothes or rebaking would obviously have to recalculate everything all over again. In all cases, it IS the sim itself that sends this final baked texture to the other avatars, so this would be easy to mess with for PG fallback sims where everyone is an attachment free ruth. Such a sim simply never downloads anything from inventory servers. Except for the sim owner, so they can build stuff.</p> | ||
| 75 | <p>The last tricky thing is physics, but that's covered later.</p> | ||
| 76 | <p> </p> | ||
| 77 | <h4> User changing something in sim, or creating a new object. </h4> | ||
| 78 | <p>I have not spoken yet about how to keep everyone informed about changes. In general, the bulk of the heavy lifting (big asset files) in this design has been left to standard HTTP protocols, letting mature technologies like caching proxies make life easier and quicker. This may not be suitable for real time editing and other similar things. One thing that sets this style of virtual world apart from others is in world editing of objects is real time visible to everyone. When I move an object from A to B, every one sees it move as I move it. This is one big source of immersion, and a good thing. Obviously there has to be some sort of command channel for this data to flow through quickly. I say this command channel has to be as reliable as possible, with very low latency. The data that moves through this channel should be limited to meta data, any change of assets should simply be mentioned in this channel, then the usual HTTP stuff used to shift the asset files around. So the commands in this command channel would be things like - "move object A to X,Y,Z"; "change the texture of prim A, on side B, to texture X"; "create a prim at X,Y,Z, of this type"; "change parameter X of prim A, to M".</p> | ||
| 79 | <p>The exact form of this command channel I'll leave to debate, flame wars, and experimentation. I would highly recommend these things about it - Move away from XML to something less bloated, preferable a binary command language. The shorter each command is, the less latency. This command language should be common throughout the system where ever in world changes have to be communicated. The command language should be generic, and extensible. The command language should be parseble by a rather naive parse, again to keep complexity, and thus latency, down. I think my 10 years of experiments in a similar sort of command language for GUIs might come in handy here. The channel would benefit from some sort of broadcast mechanism, if possible and it stays within the above mentioned boundaries.</p> | ||
| 80 | <p>Note - in this case, the commands would generally be flying about in human time frames. Humans will be driving these commands, so they wont be coming down the channel in bulk at high speed. There's only so quick a human can drag their mouse ...</p> | ||
| 81 | <p>On the other hand, since the assets are all on a web server, there is nothing stopping people from using standard web methods of changing content. CMS, FTP uploads, webDav, shell access to the web server contents, what ever works now for managing and editing web content can still work.</p> | ||
| 82 | <p> </p> | ||
| 83 | <h4> Script changing something in sim. </h4> | ||
| 84 | <p>... On the other hand, scripts can drive this exact same command channel to do their work on scripted objects. The exact same methods as used for users changing stuff should be used if it's being done by scripts. No code duplication, just pump it into the same channel with the same methods. In this case, the commands COULD be coming through in bulk and at high speed. There would be multiple sources of commands, being distributed to multiple avatars.</p> | ||
| 85 | <p>The commands in both cases would need to be used by the sim to change the otherwise static data on it's web server, so that new avatars arriving will see the objects in their new state. Much fun will be had getting this part right.</p> | ||
| 86 | <p> </p> | ||
| 87 | <h4> Whatever the hell I forgot. lol </h4> | ||
| 88 | <p>I'm sure I did. I'm only human. B-)</p> | ||
| 89 | <p>Two things I forgot are in world text chatter and sounds. Yes, they are mentioned elsewhere as completely separate entities, but the thing I forgot was their positional nature. Local chat uses three "volume" settings, that are just treated like ranges. Whisper, say and shouted text is only "heard" by people that are close enough to the avatar or object doing the chatting. There is also LLRegionSay(), plus object chat channels. Sound clips played by objects, as well as voice from avatars, is attenuated by how far you are listening from them. Both could be treated as similar things, where the distance from one to the other is important. Though as usual, LL has been inconstant. Sounds depend on where your camera is, text on where your avatar is.</p> | ||
| 90 | <p>The point is that they do need this position information from the sim server, to be able to sort out who or what can see / hear which utterances. Later more sophisticated systems might take the surroundings into account to provide muffling by walls, echos, and other various affects on the sound. Even going as far as partially muting text by fading it into obscurity, or even "echoing" it in extreme cases.</p> | ||
| 91 | <p> </p> | ||
| 92 | <h3> physics </h3> | ||
| 93 | <p>Physics is a whole other ball game, it does need access to the in world asset data though. Keep it in the simulator? Hand it out to clients? Kitto is way more experienced in this stuff than me, and I think he is working on something in that field. He did not like my "crutch" concept when it applied to OpenSim though, even though he thought it was OK for client software. Certainly the physics engine should get it's data from the sim server the same way clients do, and change things back on the server the same way to. Physics engines should be able to deal with just a portion of the data on a sim. That way we can carve up the work amongst a few physics engines, maybe even send some of it to clients.</p> | ||
| 94 | <p> </p> | ||
| 95 | <h3> scripts </h3> | ||
| 96 | <p>Just in case you missed it - with this web based system, ANY web backend programming language can be used instead of LSL. Sure there will need to be reasonably efficient libraries for the various LL functions in LSL so that all those programming languages can do the same things LSL can. You could look at it the other way, this pushes LSL onto the web server, running as just another web scripting language. I'd love to write a Lua implementation of LSL, I'm sure Alice would want to write a Scheme one.</p> | ||
| 97 | <p>There would still be need of a really efficient script engine though. Simply coz there are sooo many LSL scripts that would be running on any given sim. This should be a later step, not included in the first small step mentioned in the in world asset server section above. I've been thinking of trying out Lua as a backend for LSL, and trying some micro threading style experiments.</p> | ||
| 98 | <p> </p> | ||
| 99 | <h2> other services </h2> | ||
| 100 | <p>Other services in virtual worlds are generally stand alone, with only minimal ties into the in world stuff. Some of this could be handled by jabber. Note that there is a good argument for having these all as plugins to the client, and even as separate servers.</p> | ||
| 101 | <p> </p> | ||
| 102 | <h3> login, presence, IM, and more </h3> | ||
| 103 | <p>I've always thought that jabber could be used for login, presence, friends lists, IM, group chat, ad hoc multi user chats, and even local chat. It's already a well understood, proven, open standard. It scales well, google uses it for their IM system. It has the concept of out of band data, and is extensible in other ways.</p> | ||
| 104 | <p>On the other hand, it IS XML, though that's mostly forgivable as it's only running at human interface speeds, and works as a single XML stream rather than individual XML files per utterance. So the XML overhead is not so bad. Recently I've had my qualms about it's stability. We are using it for the various chat rooms, and they seem to be a bit unreliable at times. The dreaded recurring history spam, people dropping out for odd reasons, etc. It might just be lousy implementations. I don't want to give up on it just yet, so some research is in order.</p> | ||
| 105 | <p>The already open jabber stream could be a wrapper around the command channel I have mentioned above. Possibly using out of band data if the command language is binary. It's a good match, though I'm not sure about extra latency.</p> | ||
| 106 | <p> </p> | ||
| 107 | <h3> groups </h3> | ||
| 108 | <p>Group chat can use jabber rooms as mentioned above. It should be noted that OpenSim actually uses IRC protocol for that internally. I don't like that idea, IRC is not good at keeping nicks exclusively for an individual. Net splits are common enough to throw doubts on IRC's scalability. If the users are already logging onto a jabber server for the reasons mentioned above, then jabber chat rooms for groups comes for free.</p> | ||
| 109 | <p>The other aspects of groups might be doable with jabber as well, it's got a lot of the pieces in a nicely flexible way.</p> | ||
| 110 | <p> </p> | ||
| 111 | <h3> in world chat </h3> | ||
| 112 | <p>In world chat could use a system similar to what mumble uses, with an extension to jabber. The users position can be included in the jabber stream, or the jabber server could be modified to grab that data from the sim server. Then the jabber server relays any local chat only to those that are near enough.</p> | ||
| 113 | <p> </p> | ||
| 114 | <h3> voice </h3> | ||
| 115 | <p>Use mumble, don't think much more need be said about that. Look it up.</p> | ||
| 116 | <p> </p> | ||
| 117 | <h3> web browser </h3> | ||
| 118 | <p>Webkit seems to be the general king of the heap for embedded web browsers at the moment. Impy already moved to use it, thus meta-impy has it. It's use could be generalised. I'd like to see web based admin stuff that works well from the built in web browser. Then it's way easy to go beyond the the clients existing god tools, most of which are not implemented in OpenSim anyway. This also opens up the admin tools market, some basic protocols to get to the tools, and to get in world info to the tools, but the tools can be anything developers dream up. Could do the same for some user stuff to. Trouble ticket systems built into the world via the web, not built into the client. Combined with web an a prim, user interfaces for HUDs and stuff could be better. Not sure if that sort of thing worked well in SL, but I'd like to "do it right".</p> | ||
| 119 | <p>Now usually I'm against virtual world clients built into web browsers, but a lot of this design makes that much easier to do. Mostly the reason why people want it is rather wanky, they want every damn thing in the browser, even if they don't want to use actual open standards, and tend to make them Windows only. There is not really any good sort of match between the web browsing experience and the virtual world using experience. This design however opens up one very good use case - Open Cobalt style TP portals built on web standards. Now THAT's sexy. B-)</p> | ||
| 120 | <p>On the other hand, I still think a lot of web stuff is bloated. That's why I started to write my matrix-RAD system 15 years ago. No one was interested in small, fast, and flexible; plus Java fell out of favour for general web work. Java moved to enterprise, where bigger is better; and to mobile phones, where apparently no one is really interested in small, fast, and flexible. So I abandoned it years ago. I'd love to rewrite it in C (or maybe lua), and add a scriptable, network transparent, GUI system to virtual worlds. It would also be a good basis for the command language mentioned above. That's just me though. B-)</p> | ||
| 121 | <p> </p> | ||
| 122 | <h3> media </h3> | ||
| 123 | <p>Media is actually reasonably well taken care of already at the design level, even if there are current growing pains with Imprudence changing things around. There are some ideas I'd like to throw out there though.</p> | ||
| 124 | <p>Using mumble for voice means you get in world voices that fade out over distance, like they should, and just like the LL voice does. With an open voice system though, we can generalise that, by attaching a mumble sound source to a prim. Ghetto blasters anyone? Atmospheric sound sources that are not limited to 10 second pre recorded sound clips? Not having to slice up your land for different radio stations? DJs not having to buy streams, but being able to pump music directly into the sim?</p> | ||
| 125 | <p>A popular thing to do is have a big TV that shows YouTube videos. The big problem with that is that it bypasses YouTubes advert revenue stream, so YouTube try to discourage that, and often YouTube clips wont work on that sort of setup. Generalised web on a prim could take care of that.</p> | ||
| 126 | <p> </p> | ||
| 127 | <h2> random notes from my old Web 3.0 document </h2> | ||
| 128 | <p>People can run their own copy of a site, and invite others, to take the load off the server. Still talking to the server for server resident objects. These can be private, similar to layers and dimensions in other virtual worlds.</p> | ||
| 129 | <p>There is a way for some 3D tools to send updates in real time to other tools, we should definitely support that.</p> | ||
| 130 | <p>People could have a little movable sim of their own running from their computer. Like the insides of a car or boat, moving around other peoples sims.</p> | ||
| 131 | <p>Touch mode - click on something to touch it, left button for touching with left hand, right button for right hand, dail up the strength of the touch with the mouse wheel. A mouse drag will naturally drag, push, or pull something, with force set by the mouse wheel, and at the speed that the user drags the mouse. Extend this so that any input device can be used to control any limb, digit, or other joint. Professional puppeteers may have open protocols for this sort of thing.</p> | ||
| 132 | <p><br /> This work is licensed under a <a href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-ShareAlike 3.0 Unported License</a>.</p> | ||
| 133 | </body> | ||
| 134 | </html> | ||