Volumes of Reading
Here’s an interesting chain of progression from yesterday.
I read yet another TechCrunch article on virtual worlds (dying a little inside, given the wacky coverage). In this instance, Erick Schonfeld interviews Philip Rosedale at a conference of smart people over the coming age of "browser-based" virtual worlds, which PR says are not a threat to Second Life, and to which Schonfeld asks/implies (off-camera) that Rosedale is in denial.
For the record, I agree with Philip on this one — as long as "browser-based" worlds don’t offer the deep user-created-content that SL life does, SL will have that niche all to itself. How big that is is another question. And how soon it will be until one of the "3D chat" clients pushes into that territory is yet another.
But here’s the reason for the apparent disconnect between Rosedale and Schonfeld: "Browser-based" is a term of art that Schonfeld repeatedly mis-uses, IMO. Philip knows that the term implies that an app is hosted in the browser. Schonfeld seems to think it means that an app’s window simply appears in a web page. There’s a big difference.
Second Life could, today (i.e., without too much work), be set up to run in a small window inside any web page. It’s mainly a matter of where the output window is housed. The compiled code, including all OpenGL rednering, would essentially be the same, and a new ActiveX shell would be the main difference.
This is why Google Earth can run in a browser window today* but still use Intrinsic Alchemy under the hood for its 3D rendering, as it did since 2000. Running in the browser, on the other hand, fundamentally means using the browser’s own resources, Javascript, 3D canvases, AJAX fetch, etc.. in a cross-platform and zero-download way to do all the work.
"Browser-based" in Schonfeld’s usage confuses these two concepts — And if there was no end-user difference, I wouldn’t complain. But there is.
As to whether those PC apps like Lively and Vivaty that appear in a browser window are a threat to SL — well, it will be a function of their features over time. They still require platform-native plugins and therefore downloads, small as they may be, which limits adoption as a full PC app does. And they still suffer from other in-browser-window issues, like what happens if I hit the back button or refresh the page, or simply scroll the window down so I don’t see my nice virtual world anymore. Or worse yet, what happens to my mouse wheel, for which, for example, the GE plugin steals control. Philip is right that it’s simply not as immersive as a full-screen stand-alone client, and web integration of 3D worlds is a much more complex issue than just placing windows on pages.
Anyway, slogging through the comments (most of them quite intelligent this time), I found Adam Frisby’s blog. He’s doing some interesting work that would let a SL/Lively client run right in the browser, using an obscure Microsoft API called XBAP, which I’m going to need to learn more about…
Sliverlight is, IMPO, a direct analog to Flash for making rich media browser-based apps. XBAP is more of a sandbox that allows you to run a general PC app in a browser window, but in a way that’s more acceptable, perhaps, (certainly more secure) than ActiveX. It is cross-browser at least, but would require more Mono support than exists on the Mac and Linux right now. Silverlight might be preferable in some ways, but its 3D support, as with Flash to date, is lacking. XBAP might have more potential.
Clicking through Adam’s blog, I then found this page, in which the other people working on a more open version of Second Life lament the terms of use for LLVolume.cpp, which I coincidentally wrote back in 2001. It’s open source lately, but apparently not open enough for their needs.
Now, LLVolume is interesting because it’s the code that creates all 3D objects (excluding avatars and terrain). Philip wanted spheres, cones, cubes, torii, etc.. to be his virtual legos, simple and small. They originally expected to write some code for each kind of prim. I felt it was much simpler to write a common block code to create all primitives at all levels of detail, including the newer flex prims that they added after I left. And indeed, it only took about two weeks and 200 lines of code to alpha-test all the prims they wanted. [The only one that's unique, in fact, is the sculpty-prim, which is basically a texture-lookup (height map) deformation on a sphere, and I'd argue that this should be a surface feature of all prims, just as bump-mapping would be.]
The problem these open source devs found was that LLVolume is not well documented and/or is strange to people used to traditional geometry in OpenGL. So I’ll make this offer: if Adam or his folks need more information on the core LLVolume concepts, I’ll pitch in. I’d be happy to write a "How Second Life Primitives Really Work" post sometime, if there’s sufficient interest, and it’s clearly open source at this point. The main issue is making all of the images to go along with the discussion. But I can swing it in the next month or two, I think. Just let me know.
I do have one big caution though: the thrust of this open sim work seems to be to promote SL as an Open Standard. I certainly hope SL prims don’t become standard in their current form. Even the original code I wrote back in 2001 could do much more than spheres and cubes, and was mainly limited by the SL protcol considerations.
If anything is going to be standardized, I’d much rather see the broader language of procedural geometry become more widely used, rather than SL’s very shallow cross-section of that field.
The benefit would be that complex objects could be represented in a very concise form, and the goals Adam and others have regarding "fingerprinting" and preserving author-credit would become much, much easier to realize. That’s a much longer discussion, but one I hope to take to the streets in the coming months.
____________
* in this case, the GE team seems to have done more than just recompile the GE app as an activeX control. They stripped out the UI, added the Javascript hooks for nearly everything, and most importantly, made some core functionality (probably streaming and caching) live outside the plug-in. That makes it possible to run 4 instances and start up very quickly after the first instance is run. And that partly solves the "hitting the back button" problem, though not entirely.