After my long rant last night about the weaknesses of SL and Opensim’s streaming media model, I must admit I felt like I had only said about third of what needed to be said. It never feels right to just to complain about the failings of a particular solution without offering a better one. Fortunately, in this case there may be a better one to offer. In this post I’ll talk about the general principle behind this better solution, the next post will outline my specific solution, down to the technical nitty-gritty.
We need a method of streaming textures (especially basic ones) quickly and efficiently. The current way we do this is sort of like sending fully baked cakes through the mail. It takes a while for the goods to get there, it’s expensive to ship them, and sometimes the shipping process damages them horribly. The more efficient way to do this is to mail a recipe. As long as the sender knows that the recipient has all the tools/skills/resources needed to make the baked goods, they don’t need to keep sending cakes off into mail-system oblivion.
We can use this recipe strategy for a lot of textures too. Rather than sending the whole texture image pixel-by-pixel, we can simply send a recipe that tells the viewer to write some text, draw some basic shapes, or even generate more complex patterns. When the viewer is done drawing the recipe, it slaps it onto the objects in world that it belongs on, and presto! Textures without horribly long download times.
Clearly, this method will only work for certain types of textures. Things like photographs, paintings should use cakes-by-mail system because that’s the kind of data that system was built to send. By shifting all the textures which can be made by recipes to recipes, it clears up the mail system so that the cakes that have to be mailed can get there much more quickly.
But how do we make sure all the recipients know how to bake the same recipes? And what about the technology to draw all these pieces onto a texture? Surely these things must be huge undertaking that would require years of work. Happily, I don’t think that’s the case, and I’ll explain why in the next post.
One of the powerful things about the SL/Opensim system is the fact that it makes few assumptions about how the system should be used. Personally, I’d prefer a system which makes even fewer assumptions, but that’s a rant for another day. In order to accommodate this flexibility, the system stores very few bits of content locally (just the avatar mesh and some basic textures, I believe). Everything else is fetched from the servers at the point when the user enters within visual range of the media. By doing things this way, anyone with an idea and access to the tools can extend the world and create new content. There’s a lot which is really great about this model, but some things which are really horrible about it too.
Take this sign for example. The entire front of the sign is a texture, a image file that’s been uploaded to the server and applied to the front face of the sign object. The majority of information the sign is trying to communicate isn’t complex at all, just some text on a flat-colored background. That information is the kind of thing you generally don’t want to have your users waiting around to load. But alas, because the information is baked into a image file, we have to wait for the image file to load in order to read it’s message.
This is really, REALLY bad user experience. Most new users don’t understand why everything looks so blurry and blank, and many don’t have the patience to wait for every texture to load just so they can read some basic text. This is not the technology conforming to the needs of the user, it’s the other way around.
Streaming media has an immense amount of potential, but it has to be used right. If Opensim(and SL, but I highly doubt they’ll ever change) don’t figure out a way around problems like these, the platform will forever be limited to those with the patience to wait for simple text to emerge from the murk, and the devout faith that what that text says will be worth it.